Freitag, 22. Oktober 2010


Topthema

Donnerstag, 22. Oktober 2009 | Topthema

About Security #227: Schwachstellen-Suche: Authentifizierung - "Doppelte Benutzer"

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/051993)

Wie jedem klar sein dürfte und es auch schon in About Security #226 beschrieben wurde, können mehrfach vergebene Benutzernamen zu unerwarteten Reaktionen der Webanwendung führen. Darum müssen Webanwendungen (sowie alle anderen Programme und Systeme, die Benutzernamen verwenden) bei der Registrierung gewählte Benutzernamen daraufhin prüfen, ob sie schon vorhanden sind oder nicht. Außer dem Fall der absichtlich oder auf Grund eines Programmierfehlers nicht durchgeführten Prüfung können "Missverständnisse" dazu führen, dass Benutzernamen doppelt vergeben werden.

NULL oder Nichts?

Ein Problem bei Webanwendungen, die auf verschiedenen Betriebssystemen laufen und/oder verschiedene Technologien verwenden, ist die Behandlung von Sonderzeichen, in diesem Fall insbesondere des NULL-Bytes. Das kann das Ende eines Strings kennzeichnen, ignoriert oder als normales Zeichen betrachtet werden. Solange sich alle Beteiligten in der Interpretation einig sind, ist das kein Problem. Wird das NULL-Byte aber von beteiligten Komponenten unterschiedlich interpretiert, wird es ein Problem und oft sogar eine Schwachstelle.

Exkurs: NULL-Byte-Schwachstelle in SSL-Implementierungen

Eine entsprechende Schwachstelle wurde von Moxie Marlinspike in verschiedenen SSL-Implementierungen entdeckt und auf der "Black Hat"-Konferenz vorgestellt (Vortrag, Paper als PDF): Ein NULL-Byte im Namensfeld (CN, Common Name) des SSL-Zertifikats führt in manchen Implementierungen dazu, dass alles Folgende ignoriert wird. Beantragt ein Krimineller, dem die Domain boeser-server.example gehört, z.B. ein Zertifikat für

www.bank.example\00.boeser-server.example

prüfen die Zertifizierungsstellen (CA, Certification Authority) i.A. nur die im Common Name eingetragene Domain, ignorieren die Subdomain und stellen das Zertifikat aus. Von der Schwachstelle betroffene SSL-Implementierungen dagegen prüfen den Common Name nur bis zum ersten NULL-Byte, erkennen daher ein gültiges Zertifikat für www.bank.example und ermöglichen dadurch z.B. Phishing und Man-in-the-Middle-Angriffe.

Ähnliches könnte auch einer Webanwendung passieren, wenn z.B. die Registrierung der neuen Benutzernamen und deren spätere Verwendung auf unterschiedlichen Systemen erfolgen, so dass sich Namen bei der Prüfung unterscheiden, bei der späteren Verarbeitung aber übereinstimmen.

Mögliche Angriffe

Ob und was für Angriffe möglich sind, ist von mehreren Faktoren abhängig: Wie reagiert die Webanwendung beim Login, wie auf eine Registrierung mit einer bereits vorhandenen Benutzername-Passwort-Kombination, wie auf eine Passwortänderung, die zu einer bereits vorhandenen Benutzername-Passwort-Kombination führt? Ein Angreifer könnte sich z.B. so lange mit einem bereits vergebenen Benutzernamen und unterschiedlichen Passwörtern neu registrieren bzw. nach der Registrierung das Passwort ändern, bis er das des zuvor vorhandenen Benutzers gefunden und damit Zugriff auf dessen Benutzerkonto hat. Sehr wahrscheinlich wird er dabei nicht von einem Schutz vor Brute-Force-Angriffen ausgebremst, evtl. aber durch ein CAPTCHA, das automatisierte Benutzerregistrierungen verhindern soll. Aber ein CAPTCHA lässt sich, teilweise sehr einfach, umgehen.

Nebenwirkungen

Verhindert eine Webanwendung, bei der sich der Benutzer selbst registrieren kann, die doppelte Vergabe von Benutzernamen, führt das zu einem weiteren Problem: Die notwendigerweise ausgegebene Fehlermeldung verrät einem Angreifer, dass ein Benutzername bereits vorhanden, also gültig ist. Er kann also versuchen, eine Liste typischer Benutzernamen zu registrieren und anhand der Fehlermeldung erkennen, welche davon vorhanden sind. Das Problem lässt sich auch nicht beseitigen, denn selbst wenn der Benutzer bei einer fehlgeschlagene Registrierung nicht über deren Ursache informiert wird, ist es meist sehr wahrscheinlich, das ein bereits vorhandener Benutzername der Grund ist. Vor allem, wenn eine Registrierung mit ansonsten identischen Daten, aber anderen Benutzernamen, gelingt.

Schwachstellen suchen
About Security: Die komplette Serie

Voraussetzung für das Vorhandensein einer Schwachstelle ist die Möglichkeit für die Benutzer, sich selbst bei der Webanwendung zu registrieren und den Benutzernamen wählen zu können. Sind beide Bedingungen erfüllt, wird zuerst versucht, den gleichen Benutzernamen mit unterschiedlichen Passwörtern zu registrieren. Schlägt die Registrierung im zweiten Versuch fehl, kann wie oben beschrieben zumindest eine Liste gültiger Benutzernamen erstellt werden.

Ist die doppelte Registrierung eines Benutzernamens möglich, muss das Verhalten der Webanwendung in verschiedenen Situationen geprüft werden:

  • Was passiert bei der Anmeldung? Auf welches Benutzerkonto erlangt man mit welchem Passwort Zugriff?
  • Was passiert, wenn bei der Registrierung nicht nur der Benutzername, sondern auch das Passwort überein stimmen? Gibt es eine Fehlermeldung, kann darüber evtl. das Passwort eines schon vorhandenen Benutzers mit einem Brute-Force-Angriff ermittelt werden. Wenn es keine Fehlermeldung gibt, muss geprüft werden, was beim Einloggen passiert, d.h. auf welches Benutzerkonto man Zugriff erhält.

Evtl. müssen die Versuche mit mehreren identischen Benutzernamen, aber unterschiedlichen sonstigen Informationen wiederholt werden, um Unterschiede zu erkennen.

Des weiteren muss geprüft werden, was bei einem NULL-Byte im Benutzernamen passiert, indem z.B. die Benutzernamen test, testuser und test\00user registriert werden. Je nachdem, ob und welche Fehlermeldung es gibt, muss dann ggf. geprüft werden, ob nach der Registrierung eines Benutzernamens nach dem Muster

[vorhandener Benutzername]\00[irgendwas]

ein Zugriff auf das bereits vorhandene Benutzerkonto möglich ist.

Soviel zum doch etwas abstrakten Problem der doppelt vergebenen Benutzernamen. In der nächsten Folge geht es um ein konkreteres Problem: Vorhersagbare Benutzernamen und Passwörter.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren