# OAuth zu Accountübernahme {{#include ../banners/hacktricks-training.md}} ## Grundlegende Informationen OAuth bietet verschiedene Versionen, mit grundlegenden Einblicken, die in der [OAuth 2.0-Dokumentation](https://oauth.net/2/) verfügbar sind. Diese Diskussion konzentriert sich hauptsächlich auf den weit verbreiteten [OAuth 2.0-Autorisierungscode-Grant-Typ](https://oauth.net/2/grant-types/authorization-code/), der einen **Autorisierungsrahmen bietet, der es einer Anwendung ermöglicht, auf das Konto eines Benutzers in einer anderen Anwendung zuzugreifen oder Aktionen auszuführen** (dem Autorisierungsserver). Betrachten Sie eine hypothetische Website _**https://example.com**_, die **alle Ihre Social-Media-Beiträge** anzeigen soll, einschließlich privater. Um dies zu erreichen, wird OAuth 2.0 verwendet. _https://example.com_ wird um Ihre Erlaubnis bitten, **auf Ihre Social-Media-Beiträge zuzugreifen**. Folglich erscheint ein Zustimmungsbildschirm auf _https://socialmedia.com_, der die **angeforderten Berechtigungen und den Entwickler, der die Anfrage stellt, umreißt**. Nach Ihrer Autorisierung erhält _https://example.com_ die Möglichkeit, **in Ihrem Namen auf Ihre Beiträge zuzugreifen**. Es ist wichtig, die folgenden Komponenten innerhalb des OAuth 2.0-Rahmens zu verstehen: - **resource owner**: Sie, als der **Benutzer/Entität**, autorisieren den Zugriff auf Ihre Ressource, wie Ihre Social-Media-Konto-Beiträge. - **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 vorab registrierten 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 erhalten. - **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**. ### Ablauf Der **tatsächliche OAuth-Ablauf** verläuft wie folgt: 1. Sie navigieren zu [https://example.com](https://example.com) und wählen die Schaltfläche „Mit Social Media integrieren“. 2. Die Website sendet dann eine Anfrage an [https://socialmedia.com](https://socialmedia.com), in der um Ihre Autorisierung gebeten wird, damit die Anwendung von https://example.com auf Ihre Beiträge zugreifen kann. Die Anfrage ist wie folgt strukturiert: ``` https://socialmedia.com/auth ?response_type=code &client_id=example_clientId &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback &scope=readPosts &state=randomString123 ``` 3. Ihnen wird dann eine Zustimmungsseite angezeigt. 4. Nach Ihrer Genehmigung sendet Social Media eine Antwort an die `redirect_uri` mit den Parametern `code` und `state`: ``` https://example.com?code=uniqueCode123&state=randomString123 ``` 5. https://example.com nutzt 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: ``` POST /oauth/access_token Host: socialmedia.com ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ``` 6. 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 ## Schwachstellen ### Offene redirect_uri 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-Übernahme ermöglicht. Die Ausbeutungstechniken 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 Ausbeutungstechniken 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 je nach Server. Für diejenigen, die einen OpenID-Server anvisieren, listet der Entdeckungsendpunkt (`**.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. ### XSS in der Umleitungsimplementierung Wie in diesem Bug-Bounty-Bericht erwähnt [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), könnte es möglich sein, dass die Umleitungs-**URL in der Antwort** des Servers nach der Authentifizierung des Benutzers **reflektiert wird und anfällig für XSS ist**. Mögliche Payload zum Testen: ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - Unsachgemäße Handhabung des Statusparameters In OAuth-Implementierungen kann der Missbrauch oder das Fehlen 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. ### Vor der Kontoübernahme 1. **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. 2. **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. ### Offenlegung von Geheimnissen 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 entsteht, 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 so den vertrauenswürdigen Status der Anwendung weiter ausnutzen. ### Client Secret Bruteforce 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: ``` POST /token HTTP/1.1 content-type: application/x-www-form-urlencoded host: 10.10.10.10:3000 content-length: 135 Connection: close code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce] ``` ### Referer-Header leckt Code + Status Sobald der Client den **Code und Status** hat, wenn er **im Referer-Header reflektiert wird**, während er zu einer anderen Seite navigiert, ist er anfällig. ### Zugriffstoken im Browserverlauf gespeichert Gehe zum **Browserverlauf und überprüfe, ob das Zugriffstoken dort gespeichert ist**. ### Dauerhafter Autorisierungscode 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**. ### Autorisierungs-/Aktualisierungstoken nicht an den Client gebunden Wenn du den **Autorisierungscode erhalten und ihn mit einem anderen Client verwenden kannst, kannst du andere Konten übernehmen**. ### Glückliche Pfade, XSS, Iframes & Post-Nachrichten zum Lecken von Code- & Statuswerten [**Überprüfe diesen Beitrag**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url) ### AWS Cognito In diesem Bug-Bounty-Bericht: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](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**. ```bash # Read info of the user aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...] # Change email address aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com { "CodeDeliveryDetailsList": [ { "Destination": "i***@f***.com", "DeliveryMedium": "EMAIL", "AttributeName": "email" } ] } ``` Für detailliertere Informationen darüber, wie man AWS Cognito missbrauchen kann, siehe: {{#ref}} https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum {{#endref}} ### Missbrauch anderer App-Token Wie [**in diesem Bericht erwähnt**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), 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, die OAuth unterstützt und sich mit Facebook anmeldet** (zum Beispiel), in seiner eigenen Anwendung erstellen könnte. Sobald ein Opfer sich 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**. > [!CAUTION] > 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. ### Zwei Links & Cookie Laut [**diesem Bericht**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f) war es möglich, ein Opfer dazu zu bringen, 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 die **Eingabeaufforderung** den **Benutzer** fragen, ob er den Zugriff auf den Host des Angreifers gewähren möchte. Um diese Eingabeaufforderung zu umgehen, war es möglich, einen Tab zu öffnen, um den **Oauth-Flow** zu initiieren, der dieses RU-Cookie mit der **returnUrl** setzen würde, den Tab zu schließen, bevor die Eingabeaufforderung angezeigt wird, und einen neuen Tab ohne diesen Wert zu öffnen. Dann wird die **Eingabeaufforderung nicht über den Host des Angreifers informieren**, aber das Cookie würde auf ihn gesetzt, sodass das **Token an den Host des Angreifers** in der Umleitung gesendet wird. ### Eingabeaufforderungs-Interaktionsumgehung Wie in [**diesem Video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q) 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 einer Eingabeaufforderung im Web bestätigen, wenn sie bereits in der Plattform angemeldet sind. ### response_mode Wie [**in diesem Video erklärt**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), könnte es möglich sein, den Parameter **`response_mode`** anzugeben, um zu bestimmen, wo der Code in der endgültigen URL bereitgestellt werden soll: - `response_mode=query` -> Der Code wird in einem GET-Parameter bereitgestellt: `?code=2397rf3gu93f` - `response_mode=fragment` -> Der Code wird im URL-Fragmentparameter `#code=2397rf3gu93f` bereitgestellt - `response_mode=form_post` -> Der Code wird in einem POST-Formular 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...` ### OAuth ROPC-Flow - 2 FA-Umgehung Laut [**diesem Blogbeitrag**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96) 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. ### ATO auf Webseitenumleitung basierend auf offener Umleitung zum Referrer Dieser [**Blogbeitrag**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) beschreibt, wie es möglich war, eine **offene Umleitung** zum Wert des **Referrers** zu missbrauchen, um OAuth für ATO zu missbrauchen. Der Angriff war: 1. Das Opfer greift auf die Webseite des Angreifers zu 2. 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 **Referrer-Website des Angreifers**. 3. Im Opener, nachdem der Anbieter das Opfer autorisiert hat, sendet er es zurück zum Wert des `redirect_uri`-Parameters (Opfer-Webseite) mit einem 30X-Code, der die Webseite des Angreifers im Referrer beibehält. 4. Die **Webseite des Opfers löst die offene Umleitung basierend auf dem Referrer aus**, indem sie 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. ### SSRFs-Parameter [**Überprüfen Sie diese Forschung**](https://portswigger.net/research/hidden-oauth-attack-vectors) **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 Weisen 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 und somit 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. **Ausbeutungsstrategie:** - 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 Ausbeutung ü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. ## OAuth-Anbieter-Race Conditions Wenn die Plattform, die Sie testen, ein OAuth-Anbieter ist, [**lesen Sie dies, um mögliche Race Conditions zu testen**](race-condition.md). ## Referenzen - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors) {{#include ../banners/hacktricks-training.md}}