Freitag, 19. August 2011


Topthema

Donnerstag, 8. Oktober 2009 | Topthema

About Security #225: Schwachstellen-Suche: Authentifizierung - "User Impersonation"

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

Manche Webanwendungen stellen privilegierten Benutzern eine "User Impersonation"-Funktion zur Verfügung, mit der sie die Identität eines anderen Benutzers annehmen können, um dann Aktionen in dessen Benutzerkontext auszuführen. Das kann z.B beim Nachvollziehen der Benutzeraktionen durch den Helpdesk oder bei der Untersuchung aufgetretener Probleme durch den Administrator hilfreich sein, kann aber, wenn die Funktion ungeschickt implementiert ist oder Schwachstellen enthält, auch einem Angreifer nützen.

Designfehler und -schwachstellen

Für die "User Impersonation"-Funktion, ebenso wie für viele andere eigentlich nur privilegierten Benutzern zugängliche Personen, gibt es eine Reihe typischer Designfehler und Schwachstellen, die einem Angreifer in die Hände spielen.

Oft werden solche Funktionen nur versteckt, statt sie mit einer richtigen Zugriffskontrolle vor unbefugten Zugriffen zu schützen. Z.B. könnte der Zugriff auf /admin/admin.php mit einem Passwortschutz versehen sein, auf den sich die davon aufgerufenen Skripte wie /admin/userimpersonate.php verlassen. Jeder, der den Pfad zum Skript und dessen Namen kennt oder errät, kann es dann direkt aufrufen und dadurch die Identität eines anderen Benutzers annehmen. Das gleich gilt dann natürlich auch für alle anderen Funktionen des Administrationsbereichs, die von eigenen Skripten bereit gestellt werden, wie z.B. Passwortänderungen, das Anlegen neuer Benutzer, Datenbankbackups usw. usf. Der schlimmste Fall ist dann eine Funktion, die das Heraufladen von Skripten oder Programmen oder die Änderung von Skripten erlaubt, so dass ein Angreifer darüber eigenen Code einschleusen kann.

Manche Webanwendungen vertrauen vom Benutzer manipulierbaren Daten, wenn sie prüfen, ob ein Benutzer die "User Impersonation"-Funktion nutzt und welche Benutzeridentität er inne hat. Das kann z.B. zusätzlich zu einem gültigen Session-Token ein Cookie sein, das bestimmt, mit welchem Benutzerkonto die Session genutzt wird. Ein Angreifer, der ein Benutzerkonto kontrolliert und dadurch nach der Authentifizierung ein gültiges Session-Token besitzt, kann das ausnutzen, und durch Setzen dieses Cookies auf andere Benutzerkonten zuzugreifen.

Die "User Impersonation"-Funktion könnte auch durch ein spezielles Passwort realisiert werden, über das sich ein privilegierter Benutzer (dessen Privilegien womöglich nur dadurch bewiesen wurden, das er das Passwort kennt) über die normale Authentifizierungsfunktion mit jedem beliebigen Benutzernamen anmelden kann. Dass das ein sehr unsicherer Lösungsansatz ist, dürfte klar sein. Gelangt ein Angreifer an dieses Passwort, hat er danach Zugriff auf jedes beliebige Benutzerkonto. Unter Umständen gelingt das schon bei einem einfachen Brute-Force-Angriff. Dazu muss nur bei 2 Benutzerkonten das "Generalschlüssel-Passwort" vor dem eigentlichen Passwort ausprobiert werden, so dass der Angreifer mit dem gleichen Passwort auf zwei verschiedene Konten zugreifen kann. Das könnte zwar Zufall sein, aber so etwas wird einen Angreifer immer neugierig machen, und schon nach kurzer Zeit wird er feststellen, dass das gefundene Passwort bei jedem Benutzerkonto funktioniert. Noch verdächtiger ist ein Benutzerkonto, auf das mit zwei Passwörtern zugegriffen werden kann. Sofern der Angreifer den Brute-Force-Angriff nicht nach dem ersten gefundenen Passwort abbricht (was allerdings meistens der Fall ist, da das Ziel ja erreicht wurde), wird ihn ein Konto mit zwei Passwörtern stutzig machen und dadurch das "Generalschlüssel-Passwort" verraten.

Wenn privilegierte Benutzer die Identität anderer Benutzer annehmen können, könnte eine Schwachstelle in der "User Impersonation"-Funktion dazu führen, dass normale Benutzer die Identität eines privilegierten Benutzers annehmen und dadurch die Kontrolle über die Webanwendung erlangen. Im Fall der Erkennung des Benutzerkontos anhand eines Cookies könnte es z.B. möglich sein, durch das Setzen des Cookies auf den Benutzernamen eines privilegierten Benutzers, z.B. admin, Zugriff auf dessen Konto zu erlangen.

Schwachstellen suchen
Zuerst muss die "User Impersonation"-Funktion gefunden werden. Meist wird sie nicht von den allgemein zugänglichen Seiten erreichbar sein, sondern nur aus einem Administrationsbereich heraus. Ein Angreifer kann dann nur raten, wo sie zu finden sein könnte, so dass die Verwendung eines zufälligen Skriptnamens wie dferqcvv.php statt userimpersonate.php auf den ersten Blick einen gewissen Schutz bietet. Aber wie allgemein bekannt ist, ist 'security through obscurity' zwecklos, z.B. taucht auch dieser URL in Logfiles auf.

About Security: Die komplette Serie

Nachdem ein Angreifer die Funktion gefunden hat, wird er sie zuerst direkt ausprobieren. Beim Test der eigenen Anwendung muss dabei darauf geachtet werden, dass man nicht zufällig gerade als Admin angemeldet ist. Die entscheidende Frage lautet ja "Kann ein normaler Benutzer die Funktion nutzen, indem er das Skript direkt aufruft".

Im nächsten Schritt werden alle vom Benutzer manipulierbaren Daten, die an die Funktion übergeben werden, untersucht. Kann durch eine Änderung daran auf andere Benutzerkonten zugegriffen werden? Besonders verdächtig sind dabei Parameter, die den eigenen Benutzernamen enthalten, aber nicht zum Login oder einer anderen Funktion, die ihn offensichtlich benötigen, gehören.

Kann die Funktion ausgenutzt werden, um auf andere Benutzerkonten zuzugreifen, ist die nächste Frage, ob das auch für privilegierte Benutzerkonten gilt. Kann man durch die Eingabe eines Administrator-Benutzernamens dessen Rechte erlangen?

Ein "Generalschlüssel-Passwort" sollte bei der eigenen Webanwendung durch eine bessere Lösung ersetzt werden, eine Untersuchung erübrigt sich. Ein Angreifer sucht es, indem er die bei einem Brute-Force-Angriff gesammelten Daten auswertet und versucht, sich mit gefundenen Passwörtern als ein anderer als der zugehöriger Benutzer anzumelden.

Auch in der nächsten Folge geht es weiter um Schwachstellen in der Authentifizierung, dann u.a. um ungenügende Passwortprüfungen.

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