OAuth to Account takeover
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
OAuth bietet verschiedene Versionen, mit grundlegenden Informationen, die in der OAuth 2.0-Dokumentation verfügbar sind. Diese Diskussion konzentriert sich hauptsächlich auf den weit verbreiteten OAuth 2.0 Autorisierungscode-Grant-Typ, der ein Autorisierungsframework bereitstellt, das einer Anwendung den Zugriff auf oder die Durchführung von Aktionen im Konto eines Benutzers in einer anderen Anwendung (dem Autorisierungsserver) ermöglicht.
Betrachten wir eine hypothetische Website https://example.com, die alle deine Social-Media-Beiträge, einschließlich privater, anzeigen soll. Um dies zu erreichen, wird OAuth 2.0 verwendet. https://example.com wird um deine Erlaubnis bitten, auf deine Social-Media-Beiträge zuzugreifen. Folglich wird ein Zustimmungsbildschirm auf https://socialmedia.com erscheinen, der die angeforderten Berechtigungen und den Entwickler, der die Anfrage stellt, umreißt. Nach deiner Genehmigung erhält https://example.com die Fähigkeit, in deinem Namen auf deine Beiträge zuzugreifen.
Es ist wichtig, die folgenden Komponenten innerhalb des OAuth 2.0-Frameworks zu verstehen:
resource owner: Du, als der Benutzer/Entität, autorisierst den Zugriff auf deine Ressource, wie deine Social-Media-Konten.
resource server: Der Server, der authentifizierte Anfragen verwaltet, nachdem die Anwendung ein access token im Namen des resource owner gesichert hat, z.B. https://socialmedia.com.
client application: Die Anwendung, die Autorisierung vom resource owner anfordert, wie https://example.com.
authorization server: Der Server, der access tokens an die client application nach erfolgreicher Authentifizierung des resource owner und Sicherstellung der Autorisierung ausgibt, z.B. https://socialmedia.com.
client_id: Ein öffentlicher, eindeutiger Identifikator für die Anwendung.
client_secret: Ein vertraulicher Schlüssel, der nur der Anwendung und dem Autorisierungsserver bekannt ist, der zur Generierung von access_tokens verwendet wird.
response_type: Ein Wert, der den angeforderten Token-Typ angibt, wie code.
scope: Der Zugriffslevel, den die client application vom resource owner anfordert.
redirect_uri: Die URL, zu der der Benutzer nach der Autorisierung umgeleitet wird. Diese muss in der Regel mit der vorregistrierten Umleitungs-URL übereinstimmen.
state: Ein Parameter, um Daten während der Umleitung des Benutzers zum und vom Autorisierungsserver zu erhalten. Seine Einzigartigkeit ist entscheidend, um als CSRF-Schutzmechanismus zu dienen.
grant_type: Ein Parameter, der den Grant-Typ und den zurückzugebenden Token-Typ angibt.
code: Der Autorisierungscode vom authorization server, der zusammen mit client_id und client_secret von der Client-Anwendung verwendet wird, um ein access_token zu erwerben.
access_token: Der Token, den die Client-Anwendung für API-Anfragen im Namen des resource owner verwendet.
refresh_token: Ermöglicht der Anwendung, ein neues access_token zu erhalten, ohne den Benutzer erneut zu fragen.
Der tatsächliche OAuth-Ablauf verläuft wie folgt:
Du navigierst zu https://example.com und wählst die Schaltfläche „Mit Social Media integrieren“.
Die Seite sendet dann eine Anfrage an https://socialmedia.com und bittet um deine Genehmigung, damit die Anwendung von https://example.com auf deine Beiträge zugreifen kann. Die Anfrage ist wie folgt strukturiert:
Ihnen wird dann eine Zustimmungsseite angezeigt.
Nach Ihrer Genehmigung sendet Social Media eine Antwort an die redirect_uri mit den Parametern code und state:
https://example.com verwendet diesen code, zusammen mit seiner client_id und client_secret, um eine serverseitige Anfrage zu stellen, um ein access_token in Ihrem Namen zu erhalten, das den Zugriff auf die Berechtigungen ermöglicht, denen Sie zugestimmt haben:
Schließlich endet der Prozess, wenn https://example.com Ihr access_token verwendet, um einen API-Aufruf an Social Media zu tätigen, um auf
Die redirect_uri ist entscheidend für die Sicherheit in OAuth- und OpenID-Implementierungen, da sie angibt, wohin sensible Daten, wie Autorisierungscodes, nach der Autorisierung gesendet werden. Wenn sie falsch konfiguriert ist, könnte dies Angreifern ermöglichen, diese Anfragen an bösartige Server umzuleiten, was einen Account Takeover ermöglicht.
Die Ausnutzungstechniken variieren je nach Validierungslogik des Autorisierungsservers. Sie können von striktem Pfadabgleich bis hin zur Akzeptanz beliebiger URLs innerhalb der angegebenen Domain oder Unterverzeichnisse reichen. Zu den gängigen Ausnutzungsmethoden gehören offene Umleitungen, Pfadtraversierung, das Ausnutzen schwacher Regex und HTML-Injection zum Diebstahl von Tokens.
Neben redirect_uri sind auch andere OAuth- und OpenID-Parameter wie client_uri, policy_uri, tos_uri und initiate_login_uri anfällig für Umleitungsangriffe. Diese Parameter sind optional und ihre Unterstützung variiert zwischen den Servern.
Für diejenigen, die einen OpenID-Server anvisieren, listet der Discovery-Endpunkt (**.well-known/openid-configuration**) oft wertvolle Konfigurationsdetails wie registration_endpoint, request_uri_parameter_supported und "require_request_uri_registration. Diese Details können helfen, den Registrierungsendpunkt und andere Konfigurationsspezifika des Servers zu identifizieren.
Wie in diesem Bug-Bounty-Bericht erwähnt https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html könnte es möglich sein, dass die Redirect URL in der Antwort des Servers nach der Authentifizierung des Benutzers reflektiert wird und somit anfällig für XSS ist. Mögliche Payload zum Testen:
In OAuth-Implementierungen kann der Missbrauch oder das Versäumnis des state-Parameters das Risiko von Cross-Site Request Forgery (CSRF)-Angriffen erheblich erhöhen. Diese Schwachstelle tritt auf, wenn der state-Parameter entweder nicht verwendet, als statischer Wert verwendet oder nicht ordnungsgemäß validiert wird, was Angreifern ermöglicht, CSRF-Schutzmaßnahmen zu umgehen.
Angreifer können dies ausnutzen, indem sie den Autorisierungsprozess abfangen, um ihr Konto mit dem Konto eines Opfers zu verknüpfen, was zu potenziellen Kontoübernahmen führen kann. Dies ist besonders kritisch in Anwendungen, in denen OAuth für Authentifizierungszwecke verwendet wird.
Echte Beispiele für diese Schwachstelle wurden in verschiedenen CTF-Herausforderungen und Hacking-Plattformen dokumentiert, die ihre praktischen Auswirkungen hervorheben. Das Problem erstreckt sich auch auf Integrationen mit Drittanbieterdiensten wie Slack, Stripe und PayPal, bei denen Angreifer Benachrichtigungen oder Zahlungen auf ihre Konten umleiten können.
Eine ordnungsgemäße Handhabung und Validierung des state-Parameters ist entscheidend, um sich gegen CSRF zu schützen und den OAuth-Fluss abzusichern.
Ohne E-Mail-Verifizierung bei der Kontoerstellung: Angreifer können proaktiv ein Konto mit der E-Mail des Opfers erstellen. Wenn das Opfer später einen Drittanbieterdienst für die Anmeldung verwendet, könnte die Anwendung versehentlich dieses Drittanbieter-Konto mit dem vom Angreifer erstellten Konto verknüpfen, was zu unbefugtem Zugriff führt.
Ausnutzung laxen OAuth-E-Mail-Verifizierung: Angreifer können OAuth-Dienste ausnutzen, die E-Mails nicht verifizieren, indem sie sich bei ihrem Dienst registrieren und dann die Kontoe-Mail auf die des Opfers ändern. Diese Methode birgt ähnlich das Risiko eines unbefugten Zugriffs auf das Konto, ähnlich dem ersten Szenario, jedoch über einen anderen Angriffsvektor.
Die Identifizierung und der Schutz geheimer OAuth-Parameter sind entscheidend. Während die client_id sicher offengelegt werden kann, birgt die Offenlegung des client_secret erhebliche Risiken. Wenn das client_secret kompromittiert wird, können Angreifer die Identität und das Vertrauen der Anwendung ausnutzen, um Benutzer-access_tokens und private Informationen zu stehlen.
Eine häufige Schwachstelle tritt auf, wenn Anwendungen fälschlicherweise den Austausch des Autorisierungscodes gegen ein access_token auf der Client-Seite anstelle der Server-Seite behandeln. Dieser Fehler führt zur Offenlegung des client_secret, was es Angreifern ermöglicht, access_tokens im Namen der Anwendung zu generieren. Darüber hinaus könnten Angreifer durch Social Engineering Privilegien erhöhen, indem sie zusätzliche Scopes zur OAuth-Autorisierung hinzufügen und den vertrauenswürdigen Status der Anwendung weiter ausnutzen.
Sie können versuchen, das client_secret eines Dienstanbieters mit dem Identitätsanbieter zu bruteforcen, um zu versuchen, Konten zu stehlen. Die Anfrage zum BF könnte ähnlich aussehen wie:
Sobald der Client den Code und State hat, wenn er im Referer-Header reflektiert wird, während er zu einer anderen Seite browsed, ist er anfällig.
Gehe zum Browserverlauf und überprüfe, ob das Zugriffstoken dort gespeichert ist.
Der Autorisierungscode sollte nur für eine gewisse Zeit gültig sein, um das Zeitfenster zu begrenzen, in dem ein Angreifer ihn stehlen und verwenden kann.
Wenn du den Autorisierungscode erhalten und ihn mit einem anderen Client verwenden kannst, kannst du andere Konten übernehmen.
In diesem Bug-Bounty-Bericht: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kannst du sehen, dass das Token, das AWS Cognito dem Benutzer zurückgibt, ausreichende Berechtigungen haben könnte, um die Benutzerdaten zu überschreiben. Daher, wenn du die Benutzer-E-Mail für eine andere Benutzer-E-Mail ändern kannst, könntest du in der Lage sein, andere Konten zu übernehmen.
For more detailed info about how to abuse AWS cognito check:
Wie in diesem Bericht erwähnt, könnten OAuth-Flows, die erwarten, das Token (und nicht einen Code) zu erhalten, anfällig sein, wenn sie nicht überprüfen, ob das Token zur App gehört.
Das liegt daran, dass ein Angreifer eine Anwendung erstellen könnte, die OAuth unterstützt und sich mit Facebook anmeldet (zum Beispiel) in seiner eigenen Anwendung. Sobald ein Opfer sich dann mit Facebook in der Anwendung des Angreifers anmeldet, könnte der Angreifer das OAuth-Token des Benutzers, das seiner Anwendung gegeben wurde, erhalten und es verwenden, um sich in der OAuth-Anwendung des Opfers mit dem Benutzer-Token des Opfers anzumelden.
Daher, wenn es dem Angreifer gelingt, dass der Benutzer auf seine eigene OAuth-Anwendung zugreift, wird er in der Lage sein, das Konto des Opfers in Anwendungen zu übernehmen, die ein Token erwarten und nicht überprüfen, ob das Token ihrer App-ID zugewiesen wurde.
Laut diesem Bericht war es möglich, ein Opfer eine Seite mit einem returnUrl zu öffnen, die auf den Host des Angreifers zeigt. Diese Informationen würden in einem Cookie (RU) gespeichert und in einem späteren Schritt wird das Prompt den Benutzer fragen, ob er Zugriff auf den Host des Angreifers gewähren möchte.
Um dieses Prompt zu umgehen, war es möglich, einen Tab zu öffnen, um den Oauth-Flow zu initiieren, der dieses RU-Cookie mit dem returnUrl setzen würde, den Tab zu schließen, bevor das Prompt angezeigt wird, und einen neuen Tab ohne diesen Wert zu öffnen. Dann wird das Prompt nicht über den Host des Angreifers informieren, aber das Cookie würde darauf gesetzt, sodass das Token an den Host des Angreifers in der Umleitung gesendet wird.
Wie in diesem Video erklärt, erlauben einige OAuth-Implementierungen, den prompt GET-Parameter als None (&prompt=none) anzugeben, um zu verhindern, dass Benutzer gefragt werden, ob sie den gegebenen Zugriff in einem Prompt im Web bestätigen möchten, wenn sie bereits in der Plattform angemeldet sind.
Wie in diesem Video erklärt, könnte es möglich sein, den Parameter response_mode anzugeben, um zu bestimmen, wo der Code in der finalen URL bereitgestellt werden soll:
response_mode=query -> Der Code wird innerhalb eines GET-Parameters bereitgestellt: ?code=2397rf3gu93f
response_mode=fragment -> Der Code wird innerhalb des URL-Fragmentparameters #code=2397rf3gu93f bereitgestellt
response_mode=form_post -> Der Code wird innerhalb eines POST-Formulars mit einem Eingabefeld namens code und dem Wert bereitgestellt
response_mode=web_message -> Der Code wird in einer Post-Nachricht gesendet: window.opener.postMessage({"code": "asdasdasd...
Laut diesem Blogbeitrag handelt es sich um einen OAuth-Flow, der es ermöglicht, sich über Benutzernamen und Passwort in OAuth anzumelden. Wenn während dieses einfachen Flows ein Token zurückgegeben wird, das Zugriff auf alle Aktionen hat, die der Benutzer ausführen kann, ist es möglich, 2FA mit diesem Token zu umgehen.
Dieser Blogbeitrag beschreibt, wie es möglich war, einen offenen Redirect zum Wert des Referrers auszunutzen, um OAuth für ATO zu missbrauchen. Der Angriff war:
Das Opfer greift auf die Webseite des Angreifers zu
Das Opfer öffnet den bösartigen Link und ein Opener startet den Google OAuth-Flow mit response_type=id_token,code&prompt=none als zusätzliche Parameter unter Verwendung der Webseite des Angreifers als Referrer.
Im Opener, nachdem der Anbieter das Opfer autorisiert hat, sendet er es zurück zum Wert des redirect_uri-Parameters (Opfer-Web) mit einem 30X-Code, der die Webseite des Angreifers im Referer beibehält.
Die Webseite des Opfers löst den offenen Redirect basierend auf dem Referrer aus, der den Benutzer des Opfers zur Webseite des Angreifers umleitet. Da der response_type id_token,code war, wird der Code im Fragment der URL an den Angreifer zurückgesendet, was ihm ermöglicht, das Konto des Benutzers über Google auf der Webseite des Opfers zu übernehmen.
Überprüfen Sie diese Forschung Für weitere Details zu dieser Technik.
Die dynamische Client-Registrierung in OAuth dient als weniger offensichtlicher, aber kritischer Vektor für Sicherheitsanfälligkeiten, insbesondere für Server-Side Request Forgery (SSRF)-Angriffe. Dieser Endpunkt ermöglicht es OAuth-Servern, Details über Client-Anwendungen zu erhalten, einschließlich sensibler URLs, die ausgenutzt werden könnten.
Wichtige Punkte:
Dynamische Client-Registrierung wird oft auf /register abgebildet und akzeptiert Details wie client_name, client_secret, redirect_uris und URLs für Logos oder JSON Web Key Sets (JWKs) über POST-Anfragen.
Diese Funktion entspricht den in RFC7591 und OpenID Connect Registration 1.0 festgelegten Spezifikationen, die Parameter enthalten, die potenziell anfällig für SSRF sind.
Der Registrierungsprozess kann unbeabsichtigt Server in mehreren Wegen SSRF aussetzen:
logo_uri: Eine URL für das Logo der Client-Anwendung, die möglicherweise vom Server abgerufen wird, was SSRF auslösen oder zu XSS führen kann, wenn die URL falsch behandelt wird.
jwks_uri: Eine URL zum JWK-Dokument des Clients, die, wenn bösartig erstellt, den Server dazu bringen kann, ausgehende Anfragen an einen vom Angreifer kontrollierten Server zu senden.
sector_identifier_uri: Verweist auf ein JSON-Array von redirect_uris, das der Server abrufen könnte, was eine SSRF-Möglichkeit schafft.
request_uris: Listet erlaubte Anfrage-URIs für den Client auf, die ausgenutzt werden können, wenn der Server diese URIs zu Beginn des Autorisierungsprozesses abruft.
Exploits-Strategie:
SSRF kann ausgelöst werden, indem ein neuer Client mit bösartigen URLs in Parametern wie logo_uri, jwks_uri oder sector_identifier_uri registriert wird.
Während eine direkte Ausnutzung über request_uris möglicherweise durch Whitelist-Kontrollen gemildert wird, kann die Bereitstellung einer vorregistrierten, vom Angreifer kontrollierten request_uri während der Autorisierungsphase SSRF erleichtern.
Wenn die Plattform, die Sie testen, ein OAuth-Anbieter ist, lesen Sie dies, um mögliche Race Conditions zu testen.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
