Im Nachgang zu dem gestern veröffentlichten Artikel über den dritten Partyguide-Hack möchte ich hier – nach wissenschaftlicher Manier – noch einige „Findings“ veröffentlichen. Auf prägnante Art und Weise, damit Entscheider ähnlicher Community-Sites ihre eigenen getroffenen Massnahmen mit meinen Empfehlungen vergleichen können:
- Datenbank: Passwörter sollten von den Benutzerdaten getrennt in einer anderen Tabelle gespeichert werden. In diesem Falle hätte ich auch mit meiner „soften“ SQL Injection kein Zugriff auf dieses Feld gehabt. Zudem sollten sie nicht im Klartext abgelegt werden (MD5-Hash oder ähnliches Verfahren). Der Vorteil eines Hashes ist ausserdem, dass die Gross-/Kleinschreibung beachtet wird. Gemäss dem im letzten Artikel publizierten Mail scheint auf Partyguide endlich auch ein Hash zum Einsatz zu kommen:
„Bitte beachte die Gross- und Kleinschreibung“
Nachteil: Vergisst ein User sein Passwort, kann er sich dieses nicht zusenden lassen.
- Statistiken: Obwohl bei solchen grossen Communities riesige access.log-Dateien anfallen, sollten diese zwingend im Auge behalten werden. Es hätte den Verantwortlichen viel früher auffallen sollen, dass ein Script im Vergleich zu den Vorwochen deutlich häufiger aufgerufen wird (und das auch noch in der späten Nacht). Die Log-Dateien sind gross, doch es müssten auf dem Markt Produkte existieren, die nichtssagende Informationen aus Log-Dateien ausfiltern können und Alarm schlagen, sobald sich verdächtige Ereignisse – wie deutlich gesteigerte Zugriffe auf bestimmte URLs – häufen.
- Passwörter: Ein Programmierer, der es erlaubt, dass Benutzer seines Produkts als Passwort den Benutzernamen verwenden, gehört geteert und gefedert. Bei Partyguide konnte ich über 500 solcher Accounts dingfest machen, bei denen Usernamen und Passwort übereinstimmten.
Weiter war es möglich, dass man ein Passwort bestehend aus einem Zeichen setzen konnte. Zwar wurde man beim Login (?) darauf hingewiesen, dass das Passwort unsicher sei und mindestens 6 Zeichen und eine Zahl enthalten sollte, doch Konsequenzen folgten keine.
Ausserdem sollte eine Blacklist an verbotenen Passwörtern beigezogen werden (s. unten). -
Programmierung: All diese Sicherheitsmassnahmen nützen nichts, wenn es den Programmiern eklatant an Sicherheitsbewusstsein mangelt. Nie, nie, nie sollte man GET/POST-Daten blind trauen. In diesem Fall war es so, dass der Programmierer von der irrigen Annahme davon ausging, das alles, was über GET/POST hereinkam, „clean“ war. Gerade das Gegenteil sollte aber angenommen werden: Böse Jungs wird es immer geben. Anstelle also die GET-Variablen mit einer foreach()-Schleife durchzuspulen und blindlings in ein SQL-Query einzubauen (Ironie des Schicksals: immerhin mysql_escape_string scheint man zu benutzen), definiert der Programmierer und nicht der HTTP Request, was in die SQL Query hinenkommt und was nicht. Inklusive einer Plausibilitätsprüfung.
Weiter finde ich es auch nicht sinnvoll, SQL-Fehler an den Endbenutzer auszugeben. Dies half mir sehr, die Funktionsweise des Scripts zu verstehen:
SELECT m.member_id,m.login,m.anrede,m.land,m.ort,m.kanton,m.land, m.geburtsdatum_sichtbar, FLOOR((TO_DAYS(NOW()) - TO_DAYS(CONCAT(geburtsdatum_jahr, - , LPAD(geburtsdatum_monat, 2, 0 ), - , LPAD(geburtsdatum_tag, 2, 0 )))) / 365) as member_alter, p.nr as hat_foto FROM members AS m LEFT JOIN members_pictures_upload AS p ON m.member_id = p.member_id AND p.nr = 1 WHERE m.search = Array ORDER BY login LIMIT 0,500
Nebenbei: Kennt man bei Partyguide den Feldtyp DATE nicht? Oder wieso speichert man Geburtsjahr, -monat und -tag in ein separates Feld?
Häufigste Passwörter …
… oder was Kennwörter über die durchschnittliche Intelligenz des Benutzers aussagen:
- 123456 (427)
- hallo (76)
- LAKERS (73)
- passwort (53)
- 123456789 (53)
- 12345 (51)
- 1234 (51)
- italia (44)
- hallo1 (43)
- arschloch (43)
Dictionary Attack
Im Netz gibt es eine Menge an Security-Sites, die sich zum Ziel gemacht haben, möglichst viele Passwortdateien bereitzustellen, mit denen Dictionary Attacks ausgeführt werden können. Für Partyguide musste ich natürlich lokale Gegebenheiten adaptieren. Ich stelle die Passwort-Dateien unter folgender URL zur freien Verfügung:
16 Passwort-Listen für Dictionary-Attack
Ob ein Richter hier schon von krimineller Energie sprechen wird? Ich weiss es nicht. Einige Kommentatoren vermuten ja schon, dass die Polizei in Bälde vor meiner Tür steht. Mal schauen.
Links
Nützliche Links:
- Passwörter – Dictionary Attack
- Wortlisten
- Statistiken über das Telefonbuch der Schweiz
- Die beliebtesten Vornamen des Jahres (Wichtig: Nicht die Namen von 2006 wählen, sondern diejenigen, die den Jahrgängen der Benutzer entsprechen)
- Packet Storm – Wordlists
- Die Post – PLZ-Verzeichnis
PS: Ich warte immer noch auf eine offizielle Stellungnahme der Betreiber der Web-Site.
