Dipl.-Inform. Carsten Eilers

Das man Passwörter nicht als Klartext in der Datenbank (oder sonstwo auf dem Server) speichern darf ist allgemein bekannt, also werden sie als (natürlich gesalzener) Hash-Wert gespeichert.

Bei der Authentifizierung werden Benutzername und Klartext-Passwort (natürlich über eine verschlüsselte Verbindung) an den Server übertragen. Der Server erzeugt den Hash (ggf. unter Verwendung des zum Benutzernamen gehörenden Salt-Werts) und vergleicht ihm mit dem gespeicherten Wert. Stimmen beide Werte überein, ist die Authentifizierung erfolgreich.

So weit, so gut. Und was passiert, wenn ein Angreifer sich zum Beispiel über eine SQL-Injection-Schwachstelle die gespeicherten Zugangsdaten beschafft? Dann kennt er die Benutzernamen und den Hash-Wert der zugehörigen Passwörter, kann sich damit aber nicht einloggen, da dafür Benutzername und Klartext-Passwort benötigt werden. Der einzig mögliche Angriff sollte nun das Brechen des Passwort-Hashes sein, was durch das Salzen erschwert wird. So weit die Theorie. In der Praxis sieht es leider manchmal anders aus.

Beispiel 3: Der Hashwert ist genau so gut wie der Klartext-Passwort

Sumit Siddharth und Richard Dean wählten als Beispiel für einen Logikfehler in der Authentifizierung ColdFusion aus. Darin wurden 2010 mehrere Directory-Traversal-Schwachstellen entdeckt (CVE-2010-2861). Ein Angreifer konnte darüber zum Beispiel die Datei mit dem Administrator-Passwort herunterladen:

http://server.example/CFIDE/administrator/enter.cfm?locale=../../../../../ColdFusion8/lib/ password.properties%00en

Ein Exploit zum Ausnutzen der Schwachstelle wurde bereits kurz nach Veröffentlichung des Updates durch Adobe veröffentlicht, evtl. mittels Reverse-Engineering aus dem Patch entwickelt, da die Entdecker bis dahin keine Details veröffentlicht hatten.

Aber weiter zum Logikfehler. Hatte der Administrator alles richtig gemacht, enthielt diese Datei nur den SHA-1-Hash des Passworts. War er schlampig, war das Passwort als Klartext gespeichert und der Angreifer sicher gerne bereit, dem Admin bei der Verwaltung der Webanwendung zu helfen.

Dummerweise war der Admin aber auch dann nicht auf der sicheren Seite, wenn er selbst alles richtig gemacht und das Passwort verschlüsselt gespeichert hatte. Denn zum Einloggen musste der Angreifer nicht das Passwort kennen, sondern nur dessen Hash-Wert:

JavaScript-Code auf der Login-Seite wandelte das eingegebene Klartext-Passwort automatisch in einen SHA-1-Hash um, aus dem zusammen mit einem Salt-Wert ein HMAC (Hash-based Message Authentication Code) berechnet wurde. Danach wurden HMAC und Salt-Wert an den Server gesendet.

Der Server berechnete seinerseits aus dem gespeicherten Hash-Wert und dem vom Client verwendeten Salt-Wert den HMAC und verglich ihn mit dem vom Client gelieferten Wert. Stimmten beide überein, war die Authentifizierung erfolgreich.

Der Angreifer konnte einfach den ihm bekannten SHA-1-Wert des Passworts als Parameter für die HMAC-Berechnung verwenden und dadurch die Authentifizierung von ColdFusion umgehen. Dass er danach ein eigenes Skript hoch laden konnte, dass dann unter Windows mit SYSTEM-Rechten ausgeführt wurde, war nur noch das berühmte Tüpfelchen auf dem i und keine Schwachstelle, sondern ein Feature - es soll ja durchaus öfter vorkommen, dass ein Administrator eine Datei auf seinen Server hoch lädt. Darüber, ob die unbedingt mit SYSTEM-Rechten ausgeführt werden muss, lässt sich sicher streiten. Eigentlich macht man so etwas nicht, aber einen Kommentar verkneife ich mir mal, hier geht es um Grundlagen und nicht um Standpunkte.

Ein klarer Logikfehler. Anscheinend war den Entwicklern nicht klar, wieso man Hash-Werte salzt, und beim Versuch, ihre Software super sicher zu machen, wurde sie super unsicher. Eigentlich sollte diese Schwachstelle ja wohl inzwischen behoben worden sein. Zumindest in der CVE-Datenbank habe ich aber keinen passenden Eintrag gefunden. Hoffen wir mal, dass die Schwachstelle behoben und nur nicht korrekt gemeldet wurde.

Beispiel 4: Der Benutzer admin ist Administrator, basta!

Einen weiteres schönes Beispiel für einen Logikfehler in der Authentifizierung hat Marcus Pinto beschrieben.

Die E-Mail-Adresse, die ein Benutzer bei der Registrierung angibt, wird für die Bildung des Benutzernamens verwendet. Zuerst wird geprüft, ob sie wohlgeformt ist, im Erfolgsfall wird aus den alphanumerischen Teilen der Benutzername gebildet. So würde zum Beispiel aus

fragen@ceilers-it.de

der Benutzername

fragenceilersitde

So ein Name ist nicht besonders praktisch, aber hier geht es ja um Logikfehler und nicht um Benutzerfreundlichkeit. Was passiert wohl, wenn sich jemand mit der E-Mail-Adresse

ad@m.in

registriert? Das ergibt den Benutzernamen

admin

und der sollte ja wohl bereits reserviert sein. War er im Beispiel von Marcus Pinto aber nicht, stattdessen wurde anstandslos ein Benutzer mit entsprechendem Benutzernamen angelegt. Das wäre noch nicht schlimm, wenn der Benutzer keine besonderen Rechte hätte. Beim Einloggen stellte sich aber heraus, dass genau das der Fall ist: Es wurde ein neuer Benutzer mit Administratorrechten angelegt, der auf alle Administrations-Menüs zugreifen konnte. Schuld war folgendes Stück Code:

if ($_SESSION[‘user']=‘admin’) {
...
}

Es geht aber noch weiter: Beim Aktualisieren des Passworts des Benutzers admin wurde das Passwort des eigentlichen Administrators aktualisiert.

Außerdem war nicht nur der Administrator betroffen, sondern jeder Benutzer. Ein Angreifer, der sich zum Beispiel mit der E-Mail-Adresse

frage@nceilers-it.de

registriert, bekäme den nun nicht mehr eindeutigen Benutzernamen

fragenceilersitde

und kann so die Kontrolle über das Konto des zuvor damit angelegten Benutzers übernehmen. Ein böser Fehler.

In der nächsten Folge geht es weiter um Logikfehler in Webanwendungen.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Websecurity - XSS-Angriffe über XML

Websecurity - Angriffe über Logikfehler

Websecurity - Angriffe über Logikfehler, Teil 2

Websecurity - Logikfehler in der Authentifizierung

Websecurity - Logikfehler in der Authentifizierung und auf der Flucht

Websecurity - Logikfehler finden

Websecurity - Logikfehler vermeiden