Identification and authentication failures

Identifikations- und Authentifizierungsfehler

20. Januar 2025 Celia Catalán

Identifikation, Authentifizierung oder Autorisierung?

Zuerst müssen wir den Unterschied zwischen Identifikation und Authentifizierung verstehen:

AUSWEIS: Es ist der Prozess, bei dem eine Identität bereitgestellt wird; ein Benutzer oder System gibt an, wer er ist.
Authentifizierung: Es ist der Prozess, eine Identität zu überprüfen. Wenn ein Benutzer oder System sich identifiziert, gibt es an, wer es ist; wenn es sich authentifiziert, wird überprüft, ob es derjenige ist, der es vorgibt zu sein.

Obwohl die meisten der bekanntesten Fehler bei der Authentifizierung auftreten, da dort die Sicherheitskontrollen zur Überprüfung der Identität der Benutzer durchgeführt werden, gibt es auch Fehler im Identifikationsprozess, die die Informationssicherheit beeinträchtigen können. Einige Beispiele sind:

Falsche oder nicht erkannte Identifikation: Wenn ein Benutzer einen Benutzernamen oder eine ID eingibt, die im System nicht registriert ist, schlägt der Identifikationsprozess fehl, da keine Identität mit diesem Eingabewert verknüpft ist.

Doppelte Identität: In einigen Systemen kann es zwei Konten mit ähnlichen Benutzernamen oder sehr ähnlichen IDs geben, was Verwirrung verursacht, wenn man versucht zuzuordnen, auf welchen Benutzer sich die Identifizierung bezieht.

Andererseits ist es entscheidend, den Unterschied zwischen Authentifizierung und Autorisierung zu verstehen, die, obwohl sie ähnlich klingen, unterschiedliche Prozesse sind. Während die Authentifizierung, wie wir erklärt haben, die Identität eines Benutzers oder Systems überprüft, bestimmt die Autorisierung, ob dieser Benutzer oder dieses System die Erlaubnis hat, eine bestimmte Aktion oder Ressource auszuführen oder darauf zuzugreifen.

Authentifizierungsfaktoren

Es gibt drei Haupttypen von Authentifizierungsfaktoren, die auf einfachen Prinzipien basieren: etwas, das der Benutzer weiß, etwas, das der Benutzer hat, und etwas, das der Benutzer ist.

Etwas, das der Benutzer weiß: zum Beispiel ein Passwort oder die Antwort auf eine Sicherheitsfrage.

Etwas, das der Benutzer hat: wie ein physisches Objekt oder ein Sicherheitstoken.

Etwas, das der Benutzer ist: wie ein biometrisches Datum (Fingerabdruck) oder Verhaltensmuster.

Obwohl Passwörter nach wie vor das häufigste Authentifizierungsmechanismus sind, kann jedes System unterschiedliche Arten von Faktoren erfordern, um die Identität des Benutzers zu überprüfen. Heutzutage gibt es mehrere Mechanismen: von solchen, die ausschließlich auf biometrischen Daten basieren (wie das Entsperren von Smartphones), bis hin zu denen, die spezielle Hardware verwenden (wie tragbare Geräte). Darüber hinaus wird die Verwendung von multifaktorieller Authentifizierung immer häufiger, indem beispielsweise Passwörter mit Sicherheitstoken kombiniert werden.

Dieses vielfältige Panorama von Authentifizierungsmechanismen bietet größere Flexibilität und verbessert die allgemeine Sicherheit der Systeme. Es bringt jedoch auch neue Komplexitäten und potenzielle Schwachstellen mit sich, die Angreifer ausnutzen könnten.

Im Folgenden werden wir die verschiedenen Arten von Schwachstellen im Zusammenhang mit dem Authentifizierungsprozess analysieren und sie nach dem betroffenen Mechanismus gruppieren. Wir werden uns auf diese Schwachstellen konzentrieren, da sie die Mehrheit der Sicherheitsfehler in diesem Bereich darstellen.

Passwortbasierte Authentifizierung

Die Systeme, die ausschließlich Benutzername und Passwort als Authentifizierungsmethode verwenden, vertrauen vollständig auf das Passwort als Identitätsnachweis des Benutzers. Dies bedeutet, dass ein Angreifer, der die Anmeldeinformationen eines Benutzers erlangt, den Authentifizierungsprozess vollständig kompromittieren könnte. Es gibt verschiedene Arten von Angriffen, um diesen Mechanismus zu gefährden:

Rohe Gewalt

Brute-Force-Angriffe sind ein Prozess des Ausprobierens, bei dem der Angreifer ständig verschiedene Anmeldeinformationen eingibt – zufällig, nach bestimmten Regeln oder unter Verwendung von Wörterbüchern – um die Anmeldeinformationen eines legitimen Benutzers zu entdecken.

Bevor man versucht, das Passwort zu entdecken, ist es notwendig, eine Benutzerenumeration durchzuführen, wenn kein Benutzername bekannt ist. Es gibt verschiedene Methoden, um gültige Benutzernamen in einer Webanwendung zu identifizieren.

Der erste basiert auf der Antwort des Servers. Wenn wir einen registrierten Benutzer in die Anwendung eingeben, erhalten wir eine andere Antwort als bei der Eingabe eines nicht existierenden Benutzers. Um diesen Prozess zu automatisieren, können wir Tools wie den Intruder von BurpSuite verwenden, der es ermöglicht, Brute-Force-Angriffe auf Parameter in einer Webanfrage durchzuführen, indem Wörterbücher oder Regeln verwendet werden, um Zeichen- und Zahlenfolgen zu generieren. Im folgenden Beispiel sehen wir, dass eines der eingegebenen Wörter eine Antwort mit einer anderen Größe als die anderen zurückgibt:

Wir haben in der Antwort auf diese Anfrage festgestellt, dass die Plattform angibt, dass das Passwort ungültig ist, im Gegensatz zu den anderen Antworten, die darauf hinweisen, dass der eingegebene Benutzer ungültig ist:

Nicht immer ist es so offensichtlich; manchmal müssen wir auf subtile Fehler im Programm selbst achten. Im folgenden Fall beobachten wir eine ähnliche Situation. Obwohl alle Antworten unterschiedliche Größen haben und anzeigen, dass der Benutzer oder das Passwort ungültig sind, gibt es einen kleinen Rechtschreibfehler in der Programmierung der Antwort. Dieser Fehler führt dazu, dass bei der Eingabe eines bestehenden Benutzers eine leichte Abweichung in der Antwort auftritt:

Richtige Antwort:

Falsche Antwort:

Eine andere Methode, wenn die Antwort immer die gleiche ist, besteht darin, die Antwortzeit als Indikator zu verwenden. Wenn wir ein sehr langes Passwort eingeben und der Server es nur verarbeitet, wenn der Benutzer richtig ist, kann es länger dauern, eine so lange Zeichenkette zu verarbeiten. In diesem Beispiel testen wir mit verschiedenen Benutzern und verwenden dabei immer ein sehr langes Passwort:

Es gibt viele weitere Techniken zur Aufzählung von Benutzern. Wenn du daran interessiert bist, sie kennenzulernen, kannst du unseren Beitrag über die "Insecure Design"-Schwachstelle von OWASP besuchen.

IP-Blockumgehung

Es ist möglich, dass wir auf Anmeldebeschränkungen stoßen. Die häufigste Sperre ist die IP-Sperre, bei der der Server vorübergehend Anmeldeversuche von einer bestimmten IP-Adresse blockiert. Es gibt jedoch Methoden, um diese Sperre zu umgehen. Zum Beispiel die Verwendung von Headern wie X-Forwarded-For, die, wenn sie vom Server verarbeitet werden, zu einer Umgehung der IP-Sperre führen können.

In anderen Fällen kann die Sperrung nach einer bestimmten Anzahl von Versuchen auftreten, wird jedoch zurückgesetzt, sobald die Anmeldung erfolgreich ist. Wenn wir beispielsweise feststellen, dass die IP nach 3 Versuchen gesperrt wird, können wir ein Wörterbuch mit Anmeldeinformationen verwenden und die Anmeldeinformationen eines legitimen Benutzers (wir müssen über Anmeldeinformationen eines Benutzers verfügen) alle 2 Einträge des Wörterbuchs einfügen. Mit dieser Methode können wir die Sperrung vermeiden und alle Einträge unseres Wörterbuchs testen.

Es gibt auch Fälle, in denen die Aufzählung oder Umgehung des Authentifizierungsschemas mit einer einzigen HTTP-Anfrage durchgeführt werden kann, wodurch jegliche Sperrung durch wiederholte Anmeldeversuche umgangen wird. Zum Beispiel, wenn wir ein JSON zum Anmelden senden, könnte der Server dieses JSON korrekt verarbeiten und uns erlauben, uns anzumelden, ohne die richtigen Benutzeranmeldeinformationen zu kennen, wenn wir ein Array von Passwörtern anstelle eines einzelnen Wertes senden.

Umgehung der Kontosperrung

Die Kontosperrung ist ein weiteres Sicherheitsmechanismus. Im Gegensatz zur IP-Sperrung blockiert diese Methode das Konto nach mehreren fehlgeschlagenen Anmeldeversuchen. Wenn das System jedoch nur bestehende Konten sperrt, kann dies unbeabsichtigt zu einer Benutzerenumeration führen. Zum Beispiel, wenn wir wiederholt versuchen, uns mit verschiedenen Benutzernamen anzumelden, stellen wir fest, dass ein bestimmtes Konto nach dem fünften fehlgeschlagenen Versuch gesperrt wird:

Auf diese Weise erreichen wir eine Benutzerauflistung im Anmeldebereich der Webanwendung.

Basiszugriffsauthentifizierung

Obwohl diese Methode sehr alt ist, ist es immer noch möglich, Server zu finden, die dieses anfällige System verwenden. Dieser Authentifizierungsmechanismus besteht darin, den Benutzernamen und das Passwort zu verketten, sie in Base64 zu kodieren und sie in den Authorization-Header jeder Anfrage einzufügen:

Diese Methode ist besonders gefährlich. Es sei denn, die Webseite implementiert HSTS, könnte ein Angreifer, der einen Man-in-the-Middle-Angriff durchführt, diesen Header abfangen. Durch einfaches Dekodieren würde er die Anmeldedaten des Benutzers erhalten.

Mehrfaktor-Authentifizierung

Die ausschließlich auf Passwörtern basierenden Authentifizierungsmethoden legen die gesamte Sicherheit auf einen einzigen Parameter: etwas, das der Benutzer weiß.

Im Gegensatz dazu führt die multifaktorielle Authentifizierung mindestens einen zusätzlichen Faktor ein. Ein häufiges Beispiel ist die Zwei-Faktor-Authentifizierung (2FA), die etwas, das der Benutzer weiß (ein Passwort) und etwas, das er hat (wie einen einmaligen Code, der per E-Mail gesendet wird), erfordert. Es gibt jedoch auch andere Kombinationen, wie die Verwendung von Fingerabdrücken — etwas, das der Benutzer ist — oder Authentifizierungsanwendungen wie Microsoft Authenticator, eine mobile App, die den per E-Mail gesendeten Code ersetzt.

Umgehung der Zwei-Faktor-Authentifizierung

Der einfachste Fall tritt auf, wenn das System den Benutzer als authentifiziert betrachtet, nachdem er nur den ersten Faktor eingegeben hat, obwohl ein zweiter angefordert wird. Zum Beispiel, wenn wir das Passwort eines Benutzers kennen und Informationen über Verzeichnisse oder Ressourcen haben, die für authentifizierte Benutzer reserviert sind, könnten wir direkt darauf zugreifen, ohne das angeforderte Sicherheitstoken bereitzustellen. Dies zeigt eine mangelhafte Implementierung des zweiten Authentifizierungsfaktors, da das System nur die Benutzer als authentifiziert betrachten sollte, die den gesamten Prozess abgeschlossen haben.

Seitliche Bewegung aufgrund von Implementierungsfehler

Ähnlich wie im vorherigen Fall beobachten wir hier ein Problem bei der Überprüfung, ob alle Schritte des Prozesses von dem Benutzer, der versucht, auf die Daten zuzugreifen, durchgeführt wurden. Obwohl es verwirrend erscheinen mag, veranschaulicht das folgende Beispiel dies deutlich.

Betrachten wir eine Website mit Zwei-Faktor-Authentifizierung (2FA). Nach der Eingabe von Benutzername und Passwort fordert die Anwendung einen Sicherheitstoken an, um die Identität zu bestätigen. Es wird eine GET-Anfrage an /login2 gesendet, damit der Server den Token an die E-Mail des Benutzers sendet. Der Server sendet diesen Token an den in der Cookie-Header der Anfrage angegebenen Benutzer:

Auf diese Weise, wenn wir unseren Benutzernamen durch den der Opfer ersetzen, wird der Server das Zugriffstoken an die E-Mail-Adresse des Opfers senden:

Sobald dieses Token die E-Mail des Opfers erreicht, kann der Angreifer mit seinen eigenen Benutzeranmeldeinformationen den Anmeldevorgang beginnen und zum Prozess der Eingabe des Tokens übergehen. Beim Eingeben des Tokens, wenn er erneut diesen Cookie-Header ändert, um den Benutzernamen des Opfers einzugeben und Brute-Force-Angriffe auf das Sicherheitstoken durchführt, kann er das Sicherheitstoken entdecken, das an die E-Mail gesendet wurde, und mit diesem auf das Benutzerkonto des Opfers zugreifen:

In diesem Fall überprüft der Server nur den zweiten Schritt des Authentifizierungsprozesses, nämlich das Sicherheitstoken. Wenn das Token gültig ist und mit dem übereinstimmt, das an den in der Cookie-Header angegebenen Benutzer gesendet wurde, gewährt der Server den Zugriff. Er validiert jedoch nicht, dass die im ersten Schritt der Authentifizierung bereitgestellten Anmeldeinformationen (wie Benutzername und Passwort) dem Benutzer entsprechen, auf den zugegriffen werden soll.

Schwachstellen in anderen Authentifizierungsmechanismen

Die mit dem Authentifizierungsprozess verbundenen Schwachstellen beschränken sich nicht nur auf den Anmeldevorgang. Sie können auch in anderen kritischen Verfahren auftreten, wie z.B. beim Ändern des Passworts, beim Aktualisieren der E-Mail-Adresse oder beim Verwalten der Sitzungsdauer, wie wir im Folgenden sehen werden.

Option „Mich authentifiziert halten“

Auf vielen Webseiten wird beim Anmelden die Option angeboten, die Sitzung aktiv zu halten, selbst wenn wir den Browser schließen und wieder öffnen. Diese Funktionalität wird durch ein persistentes Cookie implementiert, ähnlich einem Sitzungscookie, jedoch mit einer längeren Dauer (mindestens für einen bestimmten Zeitraum). Obwohl diese Praxis sehr verbreitet ist, kann die Sicherheit der Anwendung gefährdet sein, je nachdem, wie dieses Token entworfen und verwaltet wird.

Im folgenden Beispiel, wenn die Option "Sitzung aufrechterhalten" ausgewählt und die Anmeldung durchgeführt wird, beobachten wir das Vorhandensein der folgenden Cookies:

Das erste Cookie gehört zur aktiven Sitzung, während das zweite das zuvor erwähnte persistente Cookie ist. Dieses Token sollte nur für den Benutzer zugänglich sein, der sich angemeldet hat. Bei der Analyse haben wir jedoch festgestellt, dass es relativ vorhersehbar ist, da es in Base64 codiert ist und den Benutzernamen gefolgt vom MD5-Hash seines Passworts enthält:

Die Struktur des Tokens kennend, ist es möglich, einen Brute-Force-Angriff zu versuchen, um ein gültiges Token zu generieren und auf das Benutzerkonto zuzugreifen. Dazu werden wir Intruder von BurpSuite verwenden, um ein Fuzzing des entsprechenden Parameters für das persistente Cookie durchzuführen. Der erste Schritt wird sein, alle Passwörter in ihre jeweiligen MD5-Hashes umzuwandeln:

Sobald die MD5-Hashliste erstellt ist, verwenden wir sie als Wörterbuch für unseren Angriff. Bevor wir jedoch dazu kommen, ist es notwendig, eine Nachbearbeitung des Wörterbuchs durchzuführen: Wir fügen den Benutzernamen des Opfers gefolgt von : als Präfix hinzu und konvertieren dann die gesamte Zeichenkette in Base64. Anschließend führen wir den Angriff mit Intruder aus, was uns ermöglichen wird, eine erfolgreiche Antwort zu erhalten, indem wir auf das Profil des Opfers zugreifen, indem wir eines der generierten persistenten Cookies verwenden.

Cookie-Diebstahl durch XSS

Es ist möglich, dass der Server uns blockiert, wenn wir zu viele Anfragen stellen, um verschiedene Tokens zu testen, aber es gibt andere Methoden, um diese Einschränkung zu umgehen. Anstatt mehrere Cookies zu testen, könnten wir versuchen, das Session-Cookie eines Benutzers zu stehlen. Wenn das Token einem Schema wie benutzer:hash[passwort] folgt, wie im vorherigen Fall, können wir versuchen, den Hash durch Brute-Force mit Tools wie hashcat zu entschlüsseln. Aber wie können wir das Cookie eines Benutzers erhalten? Dies kann durch einen XSS-Angriff erreicht werden, wie im folgenden Beispiel beschrieben.

Der Kommentarbereich eines der Blogs ist anfällig für eine JavaScript-Code-Injection. Diese Seite ist für andere Benutzer zugänglich, sodass unsere Opfer durch das Injizieren von bösartigem Code auf den Kommentarbereich zugreifen und den JavaScript-Code unwissentlich ausführen könnten. Um das Sitzungscookie zu stehlen, richten wir zunächst einen Server ein, der darauf wartet, Anfragen zu empfangen, und injizieren dann den folgenden Code in die Kommentare:

Auf diese Weise wird das Opfer, wenn es versucht, dieses Objekt i zu laden, eine Anfrage an unseren Server stellen, indem es seine Sitzungscookies in diese Anfrage einfügt. Anschließend erhalten wir diese Informationen auf unserem Server, wie wir im folgenden Bild sehen:

Wir beobachten erneut, dass es sich um eine in Base64 codierte Zeichenkette im folgenden Format handelt:

"Da der Server uns beim Stellen vieler Anfragen blockiert, können wir versuchen, diesen Hash mit hashcat unter Verwendung eines Wörterbuchs wie rockyou.txt zu knacken:"

Wie wir im Bild sehen, konnten wir den Hash knacken und das Passwort des Opfers erhalten.

Fehler beim Ändern des Passworts

Es ist möglich, Fehler in der Logik des Passwortänderungsprozesses zu identifizieren, insbesondere wenn ein Benutzer sein Passwort vergisst und eine Änderung über die E-Mail anfordert. In diesem Fall wird ein Link an die mit dem Benutzer verbundene E-Mail-Adresse gesendet, der es ihm ermöglicht, es durch ein neues zu ändern. Die Anfrage, die beim Klicken auf den Link durchgeführt wird, enthält jedoch im Body die folgenden Parameter:

Wie wir sehen, gibt es einen Parameter, der den Benutzer angibt, und dieser ist vom Benutzer änderbar. Wenn wir anstelle unseres Benutzers den Benutzernamen des Opfers eingeben, können wir das Passwort des Opfers ändern, ohne sein aktuelles Passwort zu kennen:

Passwortänderungsphishing

Um diese Schwachstelle zu verstehen, ist es wichtig, zunächst den Ablauf des Passwortänderungsprozesses zu erklären. In der Regel, wenn ein Benutzer sein Passwort vergisst, sendet der Server einen Link an die zugehörige E-Mail-Adresse, der auf eine Seite zum Zurücksetzen des Passworts weiterleitet. Da der Benutzer keinen Zugriff auf sein Konto hat, kann er kein Sitzungstoken verwenden, um seine Identität zu überprüfen. Aus diesem Grund generiert der Server häufig ein Einmal-Token und bettet dieses Token in den Weiterleitungslink zur Passwortänderungsseite ein. Die Sicherheit dieses Tokens beruht darauf, dass nur der Benutzer, der Zugriff auf seine E-Mail hat, auf den Link und damit auf das Token zugreifen kann, und dass das Token, sobald es verwendet wurde, seine Gültigkeit verliert.

Dennoch gibt es eine Schwachstelle, die dieses System gefährden kann. Beim Erstellen des Links zum Zurücksetzen des Passworts muss der Server sowohl den Host als auch den Token-Parameter in die URL einfügen:

Der Host sollte immer derselbe sein, der der legitimen Webseite entspricht. In bestimmten Fällen bestimmt jedoch der Server den Host der URL basierend auf dem Wert des Host-Headers der Anfrage, die gesendet wird, wenn der Kunde auf "E-Mail senden" klickt, und dieser Header kann von einem Angreifer manipuliert werden. Auf diese Weise kann ein böswilliger Akteur den Server täuschen, um eine E-Mail mit einem bösartigen Link an das Opfer zu senden.

Um diesen Angriff durchzuführen, muss der Angreifer auf die Schaltfläche "Passwort vergessen" klicken und den Benutzernamen des Opfers anstelle des eigenen eingeben. Dann verwendet er ein Proxy-Tool wie BurpSuite, um die Anfrage abzufangen und den Host-Header zu ändern, indem er den Host des Servers durch die URL eines Servers ersetzt, der unter seiner Kontrolle steht:

Auf diese Weise wird der Server der E-Mail-Adresse des Opfers einen Link zum Ändern des Passworts senden, einschließlich eines temporären Tokens. Der Host dieses Links wird jedoch dem Angreifer gehören. Wenn das Opfer auf diesen Link klickt, wird eine Anfrage an den Server des Angreifers gesendet, der die Anfrage abfängt und das temporäre Token erfasst. Auf diese Weise kann der Angreifer das Passwort des Opfers ändern und sich dessen Benutzerkonto aneignen.

Es ist möglich, Server zu finden, die nicht standardisierte Header unterstützen, und in diesem Kontext könnte der Server anstelle des Host-Headers Header wie X-Forwarded-Host verwenden, um den Link zu generieren:

Wie man Authentifizierungsangriffe verhindert

Die Sicherung der Authentifizierungsmechanismen ist entscheidend, um Schwachstellen zu vermeiden, die eine Website und die Daten der Benutzer gefährden könnten. Im Folgenden werden die bedeutendsten Maßnahmen hervorgehoben:

Vorsicht mit den Anmeldedaten: Senden Sie niemals Anmeldedaten über unverschlüsselte Verbindungen. Implementieren Sie HTTPS und leiten Sie HTTP-Anfragen automatisch um. Überprüfen Sie die Website, um die Offenlegung von Benutzernamen oder E-Mail-Adressen zu vermeiden.
Keine Abhängigkeit von den Benutzern: Benutzer neigen dazu, strenge Sicherheitsrichtlinien zu vermeiden. Anstatt traditionelle Passwortrichtlinien anzuwenden, ist es effektiver, Passwortprüfer wie die Bibliothek zxcvbn zu verwenden, die in Echtzeit Feedback zur Stärke der Passwörter geben.
Benutzername-Enumeration verhindern: Vermeiden Sie es, Hinweise darauf zu geben, ob ein Benutzer im System existiert, indem Sie generische Fehlermeldungen mit identischen Antwortzeiten und HTTP-Codes verwenden.
Schutz gegen Brute-Force-Angriffe: Implementieren Sie Beschränkungen für die Anzahl der Anmeldeversuche pro IP-Adresse und verwenden Sie CAPTCHA nach mehreren fehlgeschlagenen Versuchen. Dies erschwert es Angreifern, Brute-Force-Angriffe effizient durchzuführen.
Logiküberprüfung: Die Authentifizierungslogik gründlich auditen, um sicherzustellen, dass es keine Fehler oder mögliche Umgehungen gibt, die ausgenutzt werden könnten.
Achtung auf zusätzliche Funktionen: Funktionen wie das Zurücksetzen von Passwörtern sind ebenfalls anfällig, weshalb sie so sicher sein müssen wie der Haupt-Login.
Multifaktor-Authentifizierung (2FA): Die Implementierung von 2FA mit dedizierten Anwendungen oder Geräten ist sicherer als Methoden wie das Versenden von Codes per SMS oder E-Mail. Überprüfen Sie die Logik der 2FA, um zu verhindern, dass sie umgangen wird.