Freitag, 3. September 2010 |
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.
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.
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.
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.
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.
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:
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!