hacktricks/pentesting-web/oauth-to-account-takeover.md

# OAuth zur Übernahme von Konten

<details>

<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Andere Möglichkeiten, HackTricks zu unterstützen:

* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.

</details>

<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}


## Grundlegende Informationen <a href="#d4a8" id="d4a8"></a>

OAuth bietet verschiedene Versionen, mit grundlegenden Einblicken unter [OAuth 2.0-Dokumentation](https://oauth.net/2/). 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 ein **Autorisierungsframework bereitstellt, das einer Anwendung ermöglicht, auf das Konto eines Benutzers in einer anderen Anwendung zuzugreifen oder Aktionen durchzuführen** (der Autorisierungsserver).

Betrachten Sie eine hypothetische Website _**https://example.com**_, die dazu dient, **alle Ihre Social-Media-Beiträge** anzuzeigen, einschließlich privater Beiträge. Um dies zu erreichen, wird OAuth 2.0 eingesetzt. _https://example.com_ wird um Ihre Erlaubnis bitten, **auf Ihre Social-Media-Beiträge zuzugreifen**. Daraufhin erscheint ein Zustimmungsbildschirm auf _https://socialmedia.com_, der die **angeforderten Berechtigungen und den Antrag stellenden Entwickler** auflistet. 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 im OAuth 2.0-Framework zu verstehen:

- **Ressourcenbesitzer**: Sie als **Benutzer/Entität** autorisieren den Zugriff auf Ihre Ressource, wie z.B. Ihre Social-Media-Konto-Beiträge.
- **Ressourcenserver**: Der **Server, der authentifizierte Anfragen verwaltet**, nachdem die Anwendung im Namen des `Ressourcenbesitzers` ein `Zugriffstoken` erhalten hat, z.B. **https://socialmedia.com**.
- **Client-Anwendung**: Die **Anwendung, die die Autorisierung anfordert** vom `Ressourcenbesitzer`, wie z.B. **https://example.com**.
- **Autorisierungsserver**: Der **Server, der `Zugriffstoken` ausstellt** an die `Client-Anwendung` nach erfolgreicher Authentifizierung des `Ressourcenbesitzers` und Sicherung der Autorisierung, z.B. **https://socialmedia.com**.
- **client\_id**: Ein öffentlicher, eindeutiger Bezeichner für die Anwendung.
- **client\_secret:** Ein vertraulicher Schlüssel, der nur der Anwendung und dem Autorisierungsserver bekannt ist und zur Generierung von `Zugriffstoken` verwendet wird.
- **response\_type**: Ein Wert, der den **Typ des angeforderten Tokens** angibt, wie z.B. `code`.
- **scope**: Das **Zugriffsniveau**, das die `Client-Anwendung` vom `Ressourcenbesitzer` 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 zum **Aufrechterhalten von Daten während der Umleitung des Benutzers zum und vom Autorisierungsserver**. Seine Einzigartigkeit ist entscheidend, um als **CSRF-Schutzmechanismus** zu dienen.
- **grant\_type**: Ein Parameter, der **den Grant-Typ und den Typ des zurückzugebenden Tokens** angibt.
- **code**: Der Autorisierungscode vom `Autorisierungsserver`, der zusammen mit `client_id` und `client_secret` von der Client-Anwendung verwendet wird, um ein `Zugriffstoken` zu erhalten.
- **access\_token**: Das **Token, das die Client-Anwendung für API-Anfragen** im Namen des `Ressourcenbesitzers` verwendet.
- **refresh\_token**: Ermöglicht es der Anwendung, **ein neues `Zugriffstoken` zu erhalten, ohne den Benutzer erneut zur Eingabe aufzufordern**.

### Ablauf

Der **tatsächliche OAuth-Ablauf** erfolgt 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), um Ihre Autorisierung zu erhalten, damit die Anwendung von https://example.com auf Ihre Beiträge zugreifen kann. Die Anfrage ist strukturiert als:
```
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3. Sie werden dann mit einer Zustimmungsseite präsentiert.

4. Nach Ihrer Zustimmung 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 verwendet diesen `code` zusammen mit seiner `client_id` und `client_secret`, um eine serverseitige Anfrage zu stellen und im Auftrag von Ihnen ein `access_token` zu erhalten, das den Zugriff auf die von Ihnen zugestimmten Berechtigungen ermöglicht:
```
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://beispiel.com Ihren `access_token` verwendet, um einen API-Aufruf an Social Media zu tätigen, um Zugriff zu erhalten.

## Schwachstellen <a href="#323a" id="323a"></a>

### Offene redirect\_uri <a href="#cc36" id="cc36"></a>

Die `redirect_uri` ist für die Sicherheit bei OAuth- und OpenID-Implementierungen entscheidend, da sie angibt, wohin sensible Daten wie Autorisierungscodes nach der Autorisierung gesendet werden. Wenn sie falsch konfiguriert ist, könnten Angreifer diese Anfragen auf bösartige Server umleiten und so Account-Übernahmen ermöglichen.

Die Ausbeutungstechniken variieren je nach Validierungslogik des Autorisierungsservers. Sie reichen von streichenden Pfadübereinstimmungen bis zur Akzeptanz jeder URL innerhalb der angegebenen Domäne oder Unterverzeichnisses. Häufige Ausbeutungsmethoden umfassen offene Weiterleitungen, Pfadtraversierung, Ausnutzung schwacher Regexes und HTML-Injektionen 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 Weiterleitungsangriffe. Diese Parameter sind optional und ihre Unterstützung variiert je nach Server.

Für diejenigen, die einen OpenID-Server ins Visier nehmen, 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 dabei helfen, den Registrierungsendpunkt und andere Konfigurationsdetails des Servers zu identifizieren.

### XSS in Redirect-Implementierung <a href="#bda5" id="bda5"></a>

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 Redirect-**URL in der Antwort** des Servers nach der Authentifizierung des Benutzers **reflektiert wird und anfällig für XSS ist**. Möglicher Payload zum Testen:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Unzureichende Behandlung des Zustandsparameters <a href="#bda5" id="bda5"></a>

Bei OAuth-Implementierungen kann der Missbrauch oder das Weglassen 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 wird, als statischer Wert verwendet wird oder nicht ordnungsgemäß validiert wird**, was es Angreifern ermöglicht, CSRF-Schutzmechanismen 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 **Account-Übernahmen** führt. Dies ist besonders kritisch in Anwendungen, in denen OAuth für **Authentifizierungszwecke** verwendet wird.

Beispiele für diese Schwachstelle wurden in verschiedenen **CTF-Herausforderungen** und **Hacking-Plattformen** dokumentiert, was ihre praktischen Auswirkungen verdeutlicht. Das Problem erstreckt sich auch auf Integrationen mit Drittanbieterdiensten wie **Slack**, **Stripe** und **PayPal**, wo Angreifer Benachrichtigungen oder Zahlungen auf ihre Konten umleiten können.

Eine ordnungsgemäße Behandlung und Validierung des **`state`-Parameters** sind entscheidend, um sich gegen CSRF zu schützen und den OAuth-Fluss abzusichern.

### Vor der Account-Übernahme <a href="#ebe4" id="ebe4"></a>

1. **Ohne E-Mail-Verifizierung bei der Kontenerstellung**: Angreifer können vorsorglich 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 Drittanbieterkonto mit dem vorab erstellten Konto des Angreifers verknüpfen, was zu unbefugtem Zugriff führt.

2. **Ausnutzen der laxen OAuth-E-Mail-Verifizierung**: Angreifer können OAuth-Dienste ausnutzen, die keine E-Mail-Verifizierung durchführen, indem sie sich bei ihrem Dienst registrieren und dann die Kontoe-Mail in die des Opfers ändern. Diese Methode birgt ähnlich wie das erste Szenario ein Risiko für unbefugten Kontozugriff, jedoch über einen anderen Angriffsvektor.

### Offenlegung von Geheimnissen <a href="#e177" id="e177"></a>

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 ist, können Angreifer die Identität und das Vertrauen der Anwendung ausnutzen, um **Benutzerzugriffstoken** und private Informationen zu stehlen.

Eine häufige Schwachstelle entsteht, wenn Anwendungen fälschlicherweise den Austausch des Autorisierungscodes für ein Zugriffstoken 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` unter dem Deckmantel der Anwendung zu generieren. Darüber hinaus könnten Angreifer durch Social Engineering Privilegien eskalieren, indem sie zusätzliche Berechtigungen zur OAuth-Autorisierung hinzufügen und so den vertrauenswürdigen Status der Anwendung weiter ausnutzen.

### Bruteforce des Client Secrets

Sie können versuchen, das **Client-Secret bruteforcen** eines Dienstanbieters mit dem Identitätsanbieter, um Konten zu stehlen.\
Die Anfrage an BF könnte ähnlich aussehen:
```
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 + State

Sobald der Client den **Code und den Status** hat, ist es anfällig, wenn es **im Referer-Header erscheint**, wenn er zu einer anderen Seite navigiert.

### Zugriffstoken im Browserverlauf gespeichert

Gehen Sie zum **Browserverlauf und überprüfen Sie, ob das Zugriffstoken dort gespeichert ist**.

### Dauerhafter Autorisierungscode

Der **Autorisierungscode sollte nur für kurze Zeit gültig sein, um das Zeitfenster zu begrenzen, in dem ein Angreifer ihn stehlen und verwenden kann**.

### Autorisierungs-/Auffrischungstoken nicht an den Client gebunden

Wenn Sie den **Autorisierungscode erhalten und mit einem anderen Client verwenden können, können Sie andere Konten übernehmen**.

### Erfolgreiche Pfade, XSS, Iframes & Post-Nachrichten zum Lecken von Code- & Statuswerten

**[Überprüfen Sie 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 <a href="#bda5" id="bda5"></a>

In diesem Bug-Bounty-Bericht: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) können Sie sehen, dass das **Token**, das **AWS Cognito** dem Benutzer zurückgibt, möglicherweise **ausreichende Berechtigungen hat, um die Benutzerdaten zu überschreiben**. Daher, wenn Sie die **Benutzer-E-Mail-Adresse in eine andere Benutzer-E-Mail-Adresse ändern können**, könnten Sie 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 weitere detaillierte Informationen darüber, wie man AWS Cognito missbrauchen kann, siehe:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

### Missbrauch von Tokens anderer Apps <a href="#bda5" id="bda5"></a>

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, den **Token** (und nicht einen Code) zu erhalten, verwundbar sein, wenn sie nicht überprüfen, ob der Token zur App gehört.

Dies 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. Dann, sobald ein Opfer sich mit Facebook in der **Anwendung des Angreifers anmeldet**, könnte der Angreifer den **OAuth-Token des Benutzers, der seiner Anwendung gegeben wurde, erhalten und verwenden, um sich in der OAuth-Anwendung des Opfers mit dem Token des Opfers anzumelden**.

{% hint style="danger" %}
Daher, wenn es dem Angreifer gelingt, den Benutzer dazu zu bringen, seine eigene OAuth-Anwendung zu nutzen, wird er in der Lage sein, das Konto des Opfers in Anwendungen zu übernehmen, die einen Token erwarten und nicht überprüfen, ob der Token an ihre App-ID vergeben wurde.
{% endhint %}

### Zwei Links & Cookie <a href="#bda5" id="bda5"></a>

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 einer **returnUrl** zu öffnen, die auf den Host des Angreifers zeigt. Diese Information würde in einem Cookie (RU) gespeichert und in einem **späteren Schritt** würde der **Prompt** den **Benutzer fragen**, ob er Zugriff auf diesen Host des Angreifers geben möchte.

Um diesen Prompt 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 der Prompt angezeigt wird, und einen neuen Tab ohne diesen Wert zu öffnen. Dann wird der **Prompt nicht über den Host des Angreifers informieren**, aber das Cookie würde darauf gesetzt sein, so dass der **Token an den Host des Angreifers gesendet wird** in der Weiterleitung.

### SSRF-Parameter <a href="#bda5" id="bda5"></a>

**[Ü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 ein weniger offensichtlicher, aber kritischer Vektor für Sicherheitslücken, insbesondere für **Server-seitige Anfragefälschungen (SSRF)**-Angriffe. Dieser Endpunkt ermöglicht es OAuth-Servern, Details über Client-Anwendungen zu erhalten, einschließlich sensibler URLs, die ausgenutzt werden könnten.

**Hauptpunkte:**

- Die **dynamische Client-Registrierung** ist 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 Server unbeabsichtigt verschiedenen SSRF-Risiken aussetzen:
- **`logo_uri`**: Eine URL für das Logo der Client-Anwendung, das vom Server abgerufen werden könnte, um SSRF auszulösen oder zu XSS zu führen, wenn die URL falsch behandelt wird.
- **`jwks_uri`**: Eine URL zum JWK-Dokument des Clients, das bei bösartiger Gestaltung 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 Anforderungs-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 Ausnutzung über `request_uris` durch Whitelist-Steuerungen gemildert werden kann, kann die Bereitstellung eines vorregistrierten, vom Angreifer kontrollierten `request_uri` SSRF während der Autorisierungsphase erleichtern.

## Race Conditions bei OAuth-Anbietern

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)


<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

<details>

<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Andere Möglichkeiten, HackTricks zu unterstützen:

* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.

</details>