Freitag, 22. Oktober 2010


Topthema

Donnerstag, 13. August 2009 | Topthema

About Security #217: Schwachstellen-Suche: Authentifizierung - Ein Angriff

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

In About Security #216 wurde u.a. beschrieben, wie ein Angreifer an eine Liste gültiger Benutzernamen gelangt. Auf diese Namen kann dann ein Brute-Force-Angriff zum Ermitteln der zugehörigen Passwörter durchgeführt werden.

Letzte Vorbereitungen

Bevor der Brute-Force-Angriff gestartet wird, muss noch ein Unterschied zwischen einem fehlgeschlagenen und einem erfolgreichen Login-Versuch ermittelt werden, anhand dessen danach beim automatisierten Angriff Erfolg und Misserfolg unterschieden werden können.

Danach benötigt der Angreifer eine Liste möglicher Passwörter. Dabei helfen die ermittelten Informationen über die vorhandenen oder nicht vorhandenen Passwortregeln bei der Auswahl der vielversprechendsten Werte. Sind keine gültigen Benutzername bekannt, wird auch eine Liste möglicher, d.h. den geltenden Regeln entsprechender, Benutzernamen benötigt.

Benutzernamen-Liste, Passwörter-Liste - los gehts

Anhand der Listen mit gültigen oder möglichen Benutzernamen und möglicher Passwörter kann ein fertiges Tool wie z.B. Burp Intruder oder THC-Hydra (das auch im Schwachstellenscanner Nessus enthalten ist) oder ein selbst geschriebenes Skript eine Folge von Login-Requests mit allen möglichen Permutationen der Benutzernamen und Passwörter erzeugen. Wurde eine gültige Benutzername-Passwort-Kombination gefunden, wird das an der entsprechenden Antwort der Webanwendung erkannt. Meist reicht dem Angreifer ein erfolgreich erratenes Passwort, und der Angriff wird nach dem ersten Erfolg beendet. Ansonsten wird er danach mit dem nächsten Benutzernamen fortgeführt.

Fehlermeldungen beachten

So, wie eine ungeschickte Fehlermeldung beim Erkennen gültiger Benutzernamen helfen kann (siehe About Security #215), kann sie auch beim Brute-Force-Angriff helfen. Und zwar dann, wenn es beim Wirksamwerden der 'Account Lockout Policy' eine entsprechende Fehlermeldung gibt. Wenn der Angreifer erkennt, dass die Anmelde-Sperre aktiviert wurde, wird er den Angriff für den betroffenen Benutzernamen einstellen, da er einen eigentlich erfolgreichen Anmeldeversuch nicht mehr erkennen würde, und es mit einem anderen Benutzernamen probieren. Solange der Angreifer nur zwischen "Anmeldung fehlgeschlagen" und "Anmeldung erfolgreich" unterscheiden kann, wird er beim Aktivwerden der Anmeldesperre seinen Angriff mit dem nun gesperrten Benutzernamen fort führen. Geht man davon aus, das es nur sichere Passwörter gibt, wäre der Unterschied egal. Solange man aber mit schwachen Passwörtern rechnen muss, ist es besser, der Angreifer probiert seine Passwortlisten an einem inzwischen gesperrten Benutzerkonto aus, statt zu einem anderen zu wechseln und dabei zufällig eines mit einem schwachen Passwort zu finden.

Varianten des Angriffs
About Security: Die komplette Serie

Der Angriff kann im wesentlichen in zwei Varianten durchgeführt werden: Entweder wird der Reihe nach für jeden Benutzernamen die gesamte Liste möglicher Passwörter durchgegangen, oder es wird der Reihe nach jedes mögliche Passwort für alle Benutzernamen ausprobiert. Auf den ersten Blick sehen beide Varianten gleich aus, aber wenn wirklich mehrere Benutzernamen angegriffen werden, ist es für den Angreifer meist günstiger, von der Passwortliste auszugehen und jedes Passwort nacheinander mit jedem Benutzernamen auszuprobieren. Zum einen werden dadurch Benutzerkonten mit einfachen Passwörtern früher erkannt, zum anderen liegt zwischen den verschiedenen Anmeldeversuchen für einen Benutzernamen eine gewisse Wartezeit, wodurch eine vorhandene 'Account Lockout Policy' evtl. unterlaufen wird.

Gegenmaßnahmen

Mögliche Maßnahmen zur Abwehr von Brute-Force-Angriffen wurden bereits in About Security #215 beschrieben. Alle beruhen darauf, einem Brute-Force-Angreifer "den Spaß zu verderben": Statt einige hundert oder tausend Benutzername-Passwort-Kombinationen in kürzester Zeit durchprobieren zu können, wird er so weit ausgebremst, dass er entweder aufgibt oder sich ein anderes Ziel sucht. Einen Faktor sollte man dabei aber beachten: Ein Angreifer, der es nicht eilig hat, kann sich bei seinem Angriff einfach Zeit lassen und nach jedem fehlgeschlagenen Anmeldeversuch so lange warten, dass die Schutzfunktionen nicht zum Zuge kommen. Man sollte daher fehlgeschlagene Anmeldeversuche protokollieren und beim Auswerten der Logfiles auch auf derartige Versuche achten.

Ungeschützt übertragene Zugangsdaten

Werden die Zugangsdaten über eine ungeschützte HTTP-Verbindung übertragen, können sie dabei u.U. von einem Angreifer gelesen werden. Je nachdem, wo sich der Benutzer und die Webanwendung befindet, gibt es unterschiedliche Möglichkeiten für eine Beobachtung der Daten:

  • im lokalen Netz des Benutzers
  • in der IT-Abteilung des lokalen Netzes des Benutzers
  • beim ISP des Benutzers
  • während der Übertragung über das Internet (bzw. auf dem Internet-Backbone)
  • beim ISP der Webanwendung
  • in der IT-Abteilung des lokalen Netzes der Webanwendung
  • im lokalen Netz der Webanwendung

Wie ein Angreifer dabei auf die Zugangsdaten zugreifen kann, wird in der nächsten Folge beschrieben.

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