Mitternachtshacking

Es gibt mehrere Möglichkeiten, einen Benutzer einer Webseite zu authentisieren. Die klassischen beiden Methoden sind:

• HTTP Basic/Digest Authentication
• Form-based Authentication mit Cookies

Die meisten Webseiten verwenden heute formularbasierte Authentisierung, d.h. irgendwo in der Webseite ein Eingabeformular für Login und Passwort, das an ein Programm auf dem Webserver geschickt wird der die Eingabe überprüft und bei korrekter Anmeldung ein Session-Cookie zurückgibt, das als Nachweis der erfolgreichen Anmeldung fungiert. Praktisch alle Seiten die ich kenne und auch alle Freemailer, egal ob z.B. web.de, GMX, Hotmail, etc. und alle Banken arbeiten so. Das hat mehrere Gründe:

1. Das Formular lässt sich beliebig im Design der Webseite unterbringen während das HTTP Authentication Popup durch den Browser dargestellt wird und sich nicht im Corporate Design darstellen lässt.
2. Die formularbasierte Authentisierung wird von einem serverseitigen Programm angenommen, das die Benutzer z.B. gegen eine SQL-Datenbank verifizieren lässt. Eine große Anzahl von Benutzern lässt sich so einfach verwalten.
3. Die formularbasierte Authentisierung unterstützt problemlos auch Einmalpasswörter, Token (z.B. RSA SecurID) und Zertifikate. Die HTTP Basic/Digest Authentisierung wird meistens direkt vom Webserver durchgeführt und verwendet einfache Passwort-Dateien (ja, es gibt z.B. für den Apache Module die starke Authentisierung ermöglichen aber dann wird es schnell beliebig kompliziert).
4. Das HTTP Basic/Digest Authentication Passwort wird vom Browser ohne eine Lebenszeit gespeichert während sich einem Cookie trivial eine Lebenszeit und damit eine Gültigkeitsdauer mitgeben lässt.

Wenn auf einer Webseite dann doch noch HTTP Basic/Digest Authentisierung verwendet wird ist das folglich ein Grund, einmal genauer nachzuschauen. Als Beispiel verwende ich hier eine Seite des CCC, das Paper Submission System für den 24C3 Kongress auf Pentabarf.org, viele andere Seiten leiden aber unter dem gleichen Problem.

Die Anmeldung auf der Seite nach Anlegen eines Benutzers und eines Passworts erfolgt über das Popup-Fenster des Webbrowsers: „Geben Sie Benutzernamen und Passwort für Pentabarf ein“. Das Fenster selbst wird durch den Browser erzeugt, hier wird offensichtlich HTTP Basic/Digest Authentisierung verwendet:

Firefox bietet mir hier an, das Passwort im Passwort-Manager zu speichern aber das will ich normalerweise lieber nicht haben. Nach der Anmeldung kann man dann seinen Vortrag für den 24C3 eintragen.

Ich will ja eigentlich schon seit geraumer Zeit mal was erzählen aber bisher habe ich weder ein ausreichend spannendes Thema noch genug Zeit gefunden, einen ansprechenden Vortrag vorzubereiten. Naja, vielleicht 2008 😉

Die Seite bietet in der linken Spalte einen Menüpunkt „Logout“. Das ist interessant, weil es keine triviale Methode gibt, das im Browser gespeicherte Passwort zu löschen. Mal sehen, was passiert:

Hier fangen die Probleme an. Da es keine einfache Möglichkeit gibt, den Browser das Passwort vergessen zu lassen, versucht die Seite hier einen etwas unsauberen Trick. Die einzige Möglichkeit, einen Browser das Passwort einer Domain vergessen zu lassen ist, den Browser für die gleiche Domain eine neue Login/Passwort-Kombination speichern zu lassen. Dafür richtet man üblicherweise eine spezielle Seite ein, für die z.B. die Kombination logout/<kein Passwort> gültig ist. Der Nutzer klickt auf den Logout-Link, das alte Passwort ist ungültig und wenn der Nutzer bestätigt, wird die gespeicherte Login/Passwort-Kombination im Browser überschrieben.

Leider kann man dabei ein paar Sachen falsch machen:

Wenn der Anwender oben auf „nein“ bzw. „cancel“ klickt, übernimmt der Browser die neuen Anmeldedaten nicht, das alte Login/Passwort bleibt weiterhin gültig.

Die Logout-URL verwendet „logout@cccv.pentabarf.org“, Benutzername in einer URL wird jedoch vom Internet Explorer seit dem kumulativen Sicherheitsupdate für den Internet Explorer (832894) vom 2. Februar 2004 nicht mehr unterstützt. Da gab es leider zu viele Phishing-Versuche und ahnungslose Nutzer sind reihenweise auf URLs wie www.postbank.de@xyz.hk reingefallen und haben ihre PINs und TANs eingegeben. Das Verfahren funktioniert mit dem Internet Explorer so folglich gar nicht.

Mein Firefox (2.0.0.9) ist davon auch nicht beeindruckt, er scheint sich das alte Passwort und das neue Passwort auch gleich zu merken. Jedenfalls komme ich mit der „Back“-Taste oder einem Relogin ohne Eingabe des Passworts wieder auf die Inhalte:

In meinem Firefox kann ich via Extras -> Private Daten löschen (Strg+Umschalt+Entf) alle gespeicherten Daten löschen, dann sind die Passwörter auch weg. Auf meinem Arbeitsplatzrechner ist mir das eigentlich auch egal, da kommt niemand außer mir hin. Im Internet Café muss man leider dran denken, die Passwörter niemals in den Passwort-Manager zu übernehmen und den Browser nach dem Zugriff auf so eine Seite immer schließen, damit die gespeicherten Daten verloren gehen.

Das ist jetzt sicher keine gefährliche Lücke aber mit den aufkommenden Cross Site Request Forgeries (CSRF) sollte man auf solche Probleme vermehrt achten. Ach ja, ich schätze die Schwachstelle nicht so kritisch ein, dass ich sie vorher hätte melden müssen.