Ein semi-offizielles Statement der Partyguide-Jünger auf die kürzlich entdeckte Sicherheitslücke findet sich in deren Forum (danke Francine, dass du dieses Thema erwähnst):

Ihr braucht euch natürlich keine Sorgen zu machen! Wir haben lediglich den Sicherheitsstandard grobfahrlässiger Passwörter nach oben korrigiert! Dies betraf folgende Passwörter welche aus nicht mindestens 8 Zeichen sowie Zahl und Buchstabe bestanden. Zum Teil gab es Accounts mit fahrlässigen Passwörtern, wie Nickname oder Geb. Datum um nur einige Beispiele zu nennen. Diese sind jetzt aber aus der Welt geschafft. Neu ist es auch nicht mehr möglich, ein unsicheres Passwort überhaupt erst zu erstellen. Daher ein Dankeschön an unsere Entwickler, welche dank Technik nun auch die Schwäche des Menschen sicher machen. Dieser Satz kommt ja nicht von ungefähr, Ihr wisst es ja alle! Maschinen lassen sich nicht Täuschen nur die Menschen, welche Sie Bedienen! Und jetzt kann man Sie ja nicht mehr falsch Bedienen…. ;-)

Quelle: Passwort ändern

Ach, was seid ihr nicht für liebe Menschen … Komisch nur, dass ich gestern Abend einen Account mit dem Passwort 123456 erstellen konnte?

Insbesondere „Daher ein Dankeschön an unsere Entwickler, welche dank Technik nun auch die Schwäche des Menschen sicher machen.“ finde ich unpassend – gerade diese Pfeifen haben euch Usern den Schlammassel in der Tat eingebrockt …

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.

In der letzten Woche standen 13’787 Accounts auf www.partyguide.ch offen.

Durch einen extrem peinlichen Fehler (für Partyguide nicht das erste Mal) war es jedermann (!) möglich, dank einer manipulierten Anfrage an das AJAX-Benutzer-Such-Script beliebige Felder der MySQL-Tabelle abzufragen, die alle Benutzerdaten enthielt. Neben Vornamen, Nachnamen, Geburtstdatum stand auch das Passwort-Feld jeglichen Anfragen offen.

Dank einer relativ simplen Dictionary-Attack war es mir innert weniger Tage möglich, Passwörter von über 13’000 Accounts freizulegen:

pg-search.mad4you.homeip.net

Deshalb erneut die Warnung an alle leichtgläubigen Surfer: Partyguide.ch nimmt es mit dem Datenschutz überhaupt nicht ernst. Besprecht persönliche und private Anliegen NIE über diese kohärent unsichere Plattform. Sie verdient euer Vertrauen nicht, weil sie von einem unfähigen PHP-Programmier entwickelt wurde, der grundlegende Sicherheitsaspekte nicht berücksichtigt hat. Ihm scheint es egal zu sein, wenn unberechtigte Benutzer auf fremde Konten zugreifen können.

Immerhin scheint der Sysadmin meine gesteigerten Anfragen auf das AJAX-Script bemerkt zu haben. Gestern Donnerstag oder heute Freitag lud er dann selbst das .csv-File von meiner Site herunter, änderte das Passwort aller kompromittierter Benutzer und teilte ihnen dies auch mit:

Hallo <username>

Dein Passwort auf PartyGuide.ch wurde aus Sicherheitsgründen geändert
und lautet neu:

JasonIsTheBest

Bitte beachte die Gross- und Kleinschreibung. Du kannst es jederzeit
ändern unter myPage -> mySettings [ändern?!], bitte achte aber auf die
Passwort-Richtlinien. Dein Passwort sollte mindestens 8 Zeichen lang
sein und sowohl Buchstaben als auch Zahlen enthalten. Benutze niemals
deinen Namen, Geburtsdatum oder dergleichen als Passwort.

Besten Dank & liebe Grüsse
PartyGuide.ch Team

Dank dem .csv-File scheint es versierten Nutzern ein leichtes zu sein, zu überprüfen, ob die fahrlässigen Benutzer in Bälde ihr Passwort wieder auf den Standard-Wert zurücksetzen (als ich heute versucht habe, einen Account mit dem Passwort ‚123456‘ zu erstellen, hat dies ohne Komplikationen geklappt. Jungs von PG, ihr seid einfach *irre*!).

Natürlich schweigt man sich auf den plötzlichen Wechsel des Passwortes aus. Nein, man informiert die Nutzer nicht, dass ihr gewähltes Passwort, das evtl. auch für den E-Mail-Account verwendet wird, gefährdet ist. Typisch Partyguide. Hauptsache, niemand bekommt vor der konkreten Tragweite etwas mit.

Übrigens: Auch (jetzt unerwähnt gelassene) Konkurrenten schienen bis auf meinen Hinweis („Hey, wieviele User haben bei euch das Passwort 123456“) völlig hemmungslos erlaubt zu haben, unsichere Passwörter zu verwenden. Pfui. Immerhin haben sie vorsorglich reagiert.