Freitag, 19. August 2011


Topthema

Donnerstag, 19. November 2009 | Topthema

About Security #231: Schwachstellen-Suche: Authentifizierung - Implementierungsfehler (2)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/052388)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Außer den in About Security #230 beschriebenen Implementierungsfehlern in mehrstufigen Authentifizierungssystemen gibt es weitere.

Falsche Frage

Um einmal z.B. über Phishing ausgespähte Zugangsdaten für den Angreifer wertlos zu machen, erfordern manche mehrstufigen Authentifizierungssysteme nach der Eingabe von Benutzername und Passwort z.B. die Beantwortung einer von mehreren geheimen Fragen oder die Eingabe bestimmter Zeichen einer geheimen Zeichenfolge. Ein Angreifer mit ausgespähten Zugangsdaten scheitert dann am zweiten Schritt, da er nur eine von mehreren möglichen Eingaben kennt. Was grundsätzlich funktioniert, kann durch Implementierungsfehler unwirksam werden:

  • Die Webanwendung könnte die möglichen geheimen Fragen statt auf dem Server in versteckten Feldern des HTML-Formulars für den zweiten Schritt speichern und über einen weiteren Parameter, z.B. einen Indexwert, auswählen. Der Angreifer könnte diesen Parameter dann so manipulieren, dass ihm die zuvor ausgespähte Frage gestellt wird.
  • Die Webanwendung könnte die möglichen geheimen Fragen auf dem Server speichern und bei jedem Authentifizierungsversuch eine davon zufällig auswählen, aber im Fall einer falschen Antwort nicht speichern, welche Frage gestellt wurde. Der Angreifer könnte sich dann solange anzumelden versuchen, bis die richtige Frage gestellt wird.

Das gleiche gilt entsprechend, wenn bestimmte Zeichen einer geheimen Zeichenfolge abgefragt werden.

In manchen Authentifizierungssystemen, in denen eine zufällige Auswahl verwendet wird, werden alle Eingaben auf einer Seite gesammelt. Diese enthält dann außer Formularfeldern für Benutzername und Passwort noch eine Abfrage samt Eingabefeld für die geheime Frage, die bei jedem Aufruf der Seite zufällig aus den auf dem Server gespeicherten Vorgaben ausgewählt wird. In diesem Fall kann der Angreifer die Anmeldeseite solange immer wieder neu aufrufen, bis die ihm bekannte Frage erscheint. Da die Zugangsdaten erst abgeschickt werden, wenn die bekannte Frage erscheint, gibt es keine fehlgeschlagenen Authentifizierungsversuche.

Der Versuch, durch den Einsatz eines persistenten Cookies sicher zu stellen, dass immer die gleiche geheime Frage gestellt wird, bis sie korrekt beantwortet wurde, ist zum Scheitern verurteilt, da der Angreifer diesen Cookie manipulieren kann. Es ist in diesem Fall auch nicht möglich, diese Information auf dem Server zu speichern, da der Client nur anhand der IP-Adresse erkannt werden kann (Benutzername und Passwort werden ja erst an die Webanwendung gesendet, wenn die dem Angreifer bekannte geheime Frage erscheint), und diese auch einen Proxy-Server gehören kann und außerdem vom Angreifer i.A. nach Belieben gewechselt werden kann - er muss nur seine Internetverbindung beenden und neu aufbauen oder einen anderen Proxy-Server verwenden.

Schwachstellen suchen

Verwendet eine der Stufen eines mehrstufigen Authentifizierungssystems eine zufällig ausgewählte Frage, muss geprüft werden, ob Frage und Antwort gemeinsam übertragen werden. Ist das der Fall, muss geprüft werden, was passiert, wenn sie durch eine andere Frage ausgetauscht und zusammen mit der dafür richtigen Antwort an die Webanwendung geschickt wird. Ist die Authentifizierung weiterhin möglich?

Kann die Frage nicht manipuliert werden, wird der Authentifizierungsvorgang mit immer dem gleichen Benutzerkonto mehrmals bis zum Erscheinen der geheimen Frage durchgeführt. Ändert sich die Frage dabei, kann ein Angreifer sich wie oben im zweiten Fall beschrieben die richtige Frage stellen lassen.

Unsichere Speicherung von Zugangsdaten
About Security: Die komplette Serie

Werden die Zugangsdaten von der Webanwendung unsicher gespeichert, ist das Authentifizierungssystem angreifbar, ohne selbst eine Schwachstelle enthalten zu müssen. Oft werden Zugangsdaten als Klartext oder einfacher Hash-Wert in einer Datenbank gespeichert, wo sie durch eine andere Schwachstelle, z.B. SQL-Injection, ausgespäht oder manipuliert werden können.

Fail-Open-Mechanismen

Je komplexer ein Mechanismus, desto anfälliger ist er für Logikfehler, die am Ende zum genau falschen Ergebnis führen: Statt bei einem auftretenden Fehler die Authentifizierung abzubrechen und den Benutzer nicht zu authentifizieren, wird ihm der Zugriff gewährt, evtl. in einer unvollständig initialisierten Session oder mit anderen Einschränkungen, aber doch so, dass er sensitive Daten erlangen oder sonstwie Schaden anrichten kann. Das kann z.B. durch einen nicht aufgefangenen oder falsch ausgewerteten Fehler passieren, durch den Prüfungen übersprungen oder fälschlich als korrekt bestanden betrachtet werden.

Um solche Schwachstellen zu finden, wird die Authentifizierung einmal vollständig durchlaufen und dabei alle übertragenen Daten aufgezeichnet. Danach wird der Authentifizierungsprozess mehrmals mit jeweils auf evtl. unerwartete Weise manipulierten Daten durchlaufen, z.B. indem leere Strings übertragen oder Parameter ausgelassen werden, Strings statt Zahlen bzw. Zahlen statt Strings oder sehr lange oder sehr kurze Werte übertragen werden. Dabei werden die Reaktionen der Webanwendung beobachtet und Abweichungen vom erwarteten Verhalten auf Möglichkeiten zu einem Angriff untersucht.

Soviel zum Thema "Schwachstellensuche in der Authentifizierung". Ab der nächsten Folge wird der Spieß umgedreht: Es gibt Hinweise zur sicheren Implementierung der Authentifizierungsfunktionen, um die beschriebenen Schwachstellen zu vermeiden und die Angriffe abzuwehren.

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