mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
83a25742dc
commit
b938f06e4f
@ -2,16 +2,14 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Jetzt, da wir die Liste der Vermögenswerte unseres Umfangs erstellt haben, ist es an der Zeit, nach einigen OSINT-Niedrighängenden Früchten zu suchen.
|
||||
|
||||
### Plattformen, die bereits nach Leaks gesucht haben
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Api-Schlüssel-Leaks in Github
|
||||
### Tools zum Finden von Geheimnissen in Git-Repos und Dateisystemen
|
||||
|
||||
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
|
||||
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
|
||||
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
|
||||
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
|
||||
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
|
||||
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
|
||||
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
|
||||
|
||||
@ -1,27 +1,27 @@
|
||||
# OAuth zu Accountübernahme
|
||||
# OAuth zu Kontoübernahme
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Grundlegende Informationen <a href="#d4a8" id="d4a8"></a>
|
||||
|
||||
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 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.
|
||||
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 durchzuführen** (dem Autorisierungsserver).
|
||||
|
||||
Betrachten Sie eine hypothetische Website _**https://example.com**_, die **alle Ihre Social-Media-Beiträge**, einschließlich privater, **anzeigen** soll. 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 wird ein Zustimmungsbildschirm auf _https://socialmedia.com_ erscheinen, 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**.
|
||||
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 Genehmigung erhält _https://example.com_ die Fähigkeit, **in Ihrem Namen auf Ihre Beiträge zuzugreifen**.
|
||||
|
||||
Es ist wichtig, die folgenden Komponenten innerhalb des OAuth 2.0-Frameworks zu verstehen:
|
||||
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-Konten.
|
||||
- **resource owner**: Sie, als der **Benutzer/Entität**, autorisieren den Zugriff auf Ihre Ressource, wie Ihre Social-Media-Kontenbeiträ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 die Autorisierung** vom `resource owner` anfordert, wie **https://example.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, verwendet zur Generierung von `access_tokens`.
|
||||
- **response_type**: Ein Wert, der **den angeforderten Token-Typ** angibt, wie `code`.
|
||||
- **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.
|
||||
- **state**: Ein Parameter, um **Daten während der Umleitung des Benutzers zum und vom Autorisierungsserver aufrechtzuerhalten**. 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**.
|
||||
|
||||
@ -30,7 +30,7 @@ Es ist wichtig, die folgenden Komponenten innerhalb des OAuth 2.0-Frameworks zu
|
||||
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:
|
||||
2. Die Website sendet dann eine Anfrage an [https://socialmedia.com](https://socialmedia.com), in der um Ihre Genehmigung 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
|
||||
@ -44,7 +44,7 @@ https://socialmedia.com/auth
|
||||
```
|
||||
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:
|
||||
5. 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:
|
||||
```
|
||||
POST /oauth/access_token
|
||||
Host: socialmedia.com
|
||||
@ -58,11 +58,11 @@ Host: socialmedia.com
|
||||
|
||||
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 Ausbeitungsmethoden gehören offene Umleitungen, Pfadtraversierung, das Ausnutzen schwacher Regex und HTML-Injection zum Diebstahl von Tokens.
|
||||
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 Ausbeitungsmethoden gehören offene Umleitungen, Pfadtraversierung, das Ausnutzen schwacher Regex und HTML-Injektion 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 Entdeckungsendpunkt (`**.well-known/openid-configuration**`) oft wertvolle Konfigurationsdetails wie `registration_endpoint`, `request_uri_parameter_supported` und "`require_request_uri_registration` auf. Diese Details können helfen, den Registrierungsendpunkt und andere Konfigurationsspezifika des Servers zu identifizieren.
|
||||
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 <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -72,18 +72,18 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
|
||||
```
|
||||
### CSRF - Unsachgemäße Handhabung des Statusparameters <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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 entsteht, 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.
|
||||
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 entsteht, wenn der `state`-Parameter entweder **nicht verwendet, als statischer Wert verwendet oder nicht ordnungsgemäß validiert oder mit der Benutzersitzung verknüpft** wird, während man sich anmeldet, 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.
|
||||
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ührt, indem ein Benutzer sich mit einem fast abgeschlossenen OAuth-Flow anmeldet, der dem Angreifer gehört. 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.
|
||||
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**, wo 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.
|
||||
Eine ordnungsgemäße Handhabung und Validierung des **`state`-Parameters** ist entscheidend, um sich gegen CSRF zu schützen und den OAuth-Flow abzusichern.
|
||||
|
||||
### Vor der Kontoübernahme <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
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 ebenfalls das Risiko eines unbefugten Zugriffs auf das Konto, ähnlich wie im ersten Szenario, jedoch über einen anderen Angriffsvektor.
|
||||
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 <a href="#e177" id="e177"></a>
|
||||
|
||||
@ -104,9 +104,9 @@ 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
|
||||
### Referer-Header leckt Code + State
|
||||
|
||||
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.
|
||||
Sobald der Client den **Code und State** hat, wenn er **im Referer-Header reflektiert wird**, während er zu einer anderen Seite navigiert, ist er anfällig.
|
||||
|
||||
### Zugriffstoken im Browserverlauf gespeichert
|
||||
|
||||
@ -120,7 +120,7 @@ Der **Autorisierungscode sollte nur für eine gewisse Zeit gültig sein, um das
|
||||
|
||||
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
|
||||
### Glückliche Pfade, XSS, Iframes & Post-Nachrichten zum Lecken von Code- & State-Werten
|
||||
|
||||
[**Ü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)
|
||||
|
||||
@ -166,29 +166,29 @@ Um diese Eingabeaufforderung zu umgehen, war es möglich, einen Tab zu öffnen,
|
||||
|
||||
### Eingabeaufforderung Interaktionsumgehung <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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 möchten, wenn sie bereits in der Plattform angemeldet sind.
|
||||
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 finalen 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 bereitgestellt `#code=2397rf3gu93f`
|
||||
- `response_mode=form_post` -> Der Code wird in einem POST-Formular mit einem Eingabefeld namens `code` und dem Wert bereitgestellt
|
||||
- `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...`
|
||||
|
||||
### OAuth ROPC-Flow - 2 FA-Umgehung <a href="#b440" id="b440"></a>
|
||||
|
||||
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.
|
||||
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 **Benutzername** und **Passwort** bei 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 <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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-Web) mit einem 30X-Code, der die Website des Angreifers im Referrer beibehält.
|
||||
4. Die **Website des Opfers löst die offene Umleitung basierend auf dem Referrer aus**, indem sie den Benutzer des Opfers zur Website 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 Website des Opfers zu übernehmen.
|
||||
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 der Webseite des Angreifers**.
|
||||
3. Im Opener, nachdem der Anbieter das Opfer autorisiert hat, sendet er sie zurück zum Wert des `redirect_uri`-Parameters (Opfer-Web) mit einem 30X-Code, der die Webseite des Angreifers weiterhin im Referrer behä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 **`respose_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 <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -200,10 +200,10 @@ Die dynamische Client-Registrierung in OAuth dient als weniger offensichtlicher,
|
||||
|
||||
- **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:
|
||||
- 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 sie bösartig gestaltet ist, den Server dazu bringen kann, ausgehende Anfragen an einen vom Angreifer kontrollierten Server zu stellen.
|
||||
- **`sector_identifier_uri`**: Verweist auf ein JSON-Array von `redirect_uris`, das der Server abrufen könnte und somit eine SSRF-Möglichkeit schafft.
|
||||
- **`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 stellen.
|
||||
- **`sector_identifier_uri`**: Verweist auf ein JSON-Array von `redirect_uris`, die 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.
|
||||
|
||||
**Ausbeutungsstrategie:**
|
||||
@ -215,9 +215,31 @@ Die dynamische Client-Registrierung in OAuth dient als weniger offensichtlicher,
|
||||
|
||||
Wenn die Plattform, die Sie testen, ein OAuth-Anbieter ist, [**lesen Sie dies, um mögliche Race Conditions zu testen**](race-condition.md).
|
||||
|
||||
## Mutable Claims Attack
|
||||
|
||||
In OAuth identifiziert das Sub-Feld eindeutig einen Benutzer, aber sein Format variiert je nach Autorisierungsserver. Um die Benutzeridentifikation zu standardisieren, verwenden einige Clients E-Mails oder Benutzerhandles. Dies ist jedoch riskant, da:
|
||||
|
||||
- Einige Autorisierungsserver nicht sicherstellen, dass diese Eigenschaften (wie E-Mail) unveränderlich bleiben.
|
||||
- In bestimmten Implementierungen – wie **"Anmelden mit Microsoft"** – verlässt sich der Client auf das E-Mail-Feld, das **vom Benutzer in Entra ID kontrolliert wird** und nicht verifiziert ist.
|
||||
- Ein Angreifer kann dies ausnutzen, indem er seine eigene Azure AD-Organisation (z. B. doyensectestorg) erstellt und sie verwendet, um sich bei Microsoft anzumelden.
|
||||
- Obwohl die Objekt-ID (die in sub gespeichert ist) unveränderlich und sicher ist, kann die Abhängigkeit von einem veränderlichen E-Mail-Feld eine Kontoübernahme ermöglichen (zum Beispiel, indem ein Konto wie victim@gmail.com übernommen wird).
|
||||
|
||||
## Client Confusion Attack
|
||||
|
||||
In einem **Client Confusion Attack** versäumt es eine Anwendung, die den OAuth Implicit Flow verwendet, zu überprüfen, ob das endgültige Zugriffstoken speziell für ihre eigene Client-ID generiert wurde. Ein Angreifer richtet eine öffentliche Website ein, die den OAuth Implicit Flow von Google verwendet, und trickst Tausende von Benutzern aus, sich anzumelden und dadurch Zugriffstoken zu sammeln, die für die Website des Angreifers bestimmt sind. Wenn diese Benutzer auch Konten auf einer anderen anfälligen Website haben, die die Client-ID des Tokens nicht validiert, kann der Angreifer die gesammelten Tokens wiederverwenden, um die Opfer zu impersonieren und deren Konten zu übernehmen.
|
||||
|
||||
## Scope Upgrade Attack
|
||||
|
||||
Der **Authorization Code Grant**-Typ umfasst sichere serverseitige Kommunikation zur Übertragung von Benutzerdaten. Wenn der **Authorization Server** jedoch einen Scope-Parameter in der Access Token-Anfrage implizit vertraut (ein Parameter, der in der RFC nicht definiert ist), könnte eine bösartige Anwendung die Berechtigungen eines Autorisierungscodes erhöhen, indem sie einen höheren Scope anfordert. Nachdem das **Access Token** generiert wurde, muss der **Resource Server** es überprüfen: Bei JWT-Token umfasst dies die Überprüfung der JWT-Signatur und das Extrahieren von Daten wie client_id und scope, während der Server bei zufälligen String-Token den Authorization Server abfragen muss, um die Details des Tokens abzurufen.
|
||||
|
||||
## Redirect Scheme Hijacking
|
||||
|
||||
In mobilen OAuth-Implementierungen verwenden Apps **benutzerdefinierte URI-Schemata**, um Redirects mit Autorisierungscodes zu empfangen. Da jedoch mehrere Apps dasselbe Schema auf einem Gerät registrieren können, wird die Annahme, dass nur der legitime Client die Redirect-URI kontrolliert, verletzt. Auf Android beispielsweise wird eine Intent-URI wie `com.example.app://` oauth basierend auf dem Schema und optionalen Filtern, die in einem Intent-Filter der App definiert sind, erfasst. Da die Intent-Auflösung von Android breit gefächert sein kann – insbesondere wenn nur das Schema angegeben ist – kann ein Angreifer eine bösartige App mit einem sorgfältig gestalteten Intent-Filter registrieren, um den Autorisierungscode zu hijacken. Dies kann **eine Kontoübernahme ermöglichen**, entweder durch Benutzerinteraktion (wenn mehrere Apps berechtigt sind, die Absicht zu behandeln) oder durch Umgehungstechniken, die übermäßig spezifische Filter ausnutzen, wie im Bewertungsflussdiagramm von Ostorlab beschrieben.
|
||||
|
||||
## 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)
|
||||
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -10,7 +10,7 @@ Je nachdem, wie das Backend/Frontend reagiert, wenn es **seltsame Unicode-Zeiche
|
||||
|
||||
Die Unicode-Normalisierung erfolgt, wenn **Unicode-Zeichen in ASCII-Zeichen normalisiert werden**.
|
||||
|
||||
Ein häufiges Szenario dieser Art von Anfälligkeit tritt auf, wenn das System die **Eingabe** des Benutzers **nach der Überprüfung** irgendwie **modifiziert**. Zum Beispiel könnte in einigen Sprachen ein einfacher Aufruf, um die **Eingabe in Groß- oder Kleinbuchstaben** zu konvertieren, die gegebene Eingabe normalisieren und die **Unicode wird in ASCII umgewandelt**, wodurch neue Zeichen entstehen.\
|
||||
Ein häufiges Szenario dieser Art von Anfälligkeit tritt auf, wenn das System die **Eingabe** des Benutzers **nach der Überprüfung** auf irgendeine Weise **modifiziert**. Zum Beispiel könnte in einigen Sprachen ein einfacher Aufruf, um die **Eingabe in Groß- oder Kleinbuchstaben** zu ändern, die gegebene Eingabe normalisieren und die **Unicode wird in ASCII umgewandelt**, wodurch neue Zeichen entstehen.\
|
||||
Für weitere Informationen siehe:
|
||||
|
||||
{{#ref}}
|
||||
@ -27,9 +27,9 @@ Diese Anfälligkeit stammt tatsächlich von einer Schwachstelle, die ein Forsche
|
||||
|
||||
## Emoji-Injektion
|
||||
|
||||
Backends verhalten sich manchmal seltsam, wenn sie **Emojis empfangen**. Das ist, was in [**diesem Bericht**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) passiert ist, wo der Forscher es geschafft hat, ein XSS mit einer Nutzlast wie: `💋img src=x onerror=alert(document.domain)//💛` zu erreichen.
|
||||
Backends verhalten sich manchmal seltsam, wenn sie **Emojis empfangen**. Das ist, was in [**diesem Bericht**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) passiert ist, wo der Forscher es geschafft hat, ein XSS mit einem Payload wie: `💋img src=x onerror=alert(document.domain)//💛` zu erreichen.
|
||||
|
||||
In diesem Fall war der Fehler, dass der Server nach dem Entfernen der bösartigen Zeichen die **UTF-8-Zeichenkette von Windows-1252 nach UTF-8 konvertierte** (grundsätzlich stimmte die Eingabecodierung und die Umwandlung von der Codierung nicht überein). Dadurch wird kein richtiges < erzeugt, sondern nur ein seltsames Unicode-Zeichen: `‹`\
|
||||
In diesem Fall war der Fehler, dass der Server nach dem Entfernen der bösartigen Zeichen die **UTF-8-Zeichenkette von Windows-1252 nach UTF-8 umwandelte** (grundsätzlich stimmte die Eingabecodierung und die Umwandlung der Codierung nicht überein). Dadurch wird kein richtiges < erzeugt, sondern nur ein seltsames Unicode-Zeichen: `‹`\
|
||||
``Also nahmen sie diese Ausgabe und **konvertierten sie erneut von UTF-8 nach ASCII**. Dies **normalisierte** das `‹` zu `<`, so konnte der Exploit auf diesem System funktionieren.\
|
||||
Das ist, was passiert ist:
|
||||
```php
|
||||
@ -47,4 +47,18 @@ Emoji-Listen:
|
||||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||||
|
||||
## Windows Best-Fit/Worst-fit
|
||||
|
||||
Wie in **[diesem großartigen Beitrag](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)** erklärt, hat Windows eine Funktion namens **Best-Fit**, die **Unicode-Zeichen** ersetzt, die im ASCII-Modus nicht angezeigt werden können, durch ein ähnliches. Dies kann zu **unerwartetem Verhalten** führen, wenn das Backend **ein bestimmtes Zeichen** erwartet, aber ein anderes erhält.
|
||||
|
||||
Es ist möglich, Best-Fit-Zeichen in **[https://worst.fit/mapping/](https://worst.fit/mapping/)** zu finden.
|
||||
|
||||
Da Windows normalerweise Unicode-Zeichenfolgen in ASCII-Zeichenfolgen als einen der letzten Teile der Ausführung konvertiert (normalerweise von einer "W"-Suffix-API zu einer "A"-Suffix-API wie `GetEnvironmentVariableA` und `GetEnvironmentVariableW`), würde dies Angreifern ermöglichen, Schutzmaßnahmen zu umgehen, indem sie Unicode-Zeichen senden, die zuletzt in ASCII-Zeichen konvertiert werden, die unerwartete Aktionen ausführen würden.
|
||||
|
||||
Im Blogbeitrag werden Methoden vorgeschlagen, um Schwachstellen zu umgehen, die mit einer **Blacklist von Zeichen** behoben wurden, **Path Traversals** auszunutzen, indem [Zeichen, die auf “/“ (0x2F) abgebildet sind](https://worst.fit/mapping/#to%3A0x2f), und [Zeichen, die auf “\“ (0x5C) abgebildet sind](https://worst.fit/mapping/#to%3A0x5c), oder sogar Shell-Escape-Schutzmaßnahmen wie PHPs `escapeshellarg` oder Pythons `subprocess.run` zu umgehen, indem eine Liste verwendet wird. Dies wurde beispielsweise mit **Vollbreiten-Doppel-Anführungszeichen (U+FF02)** anstelle von Doppel-Anführungszeichen durchgeführt, sodass am Ende das, was wie 1 Argument aussah, in 2 Argumente umgewandelt wurde.
|
||||
|
||||
**Beachten Sie, dass eine App anfällig sein muss, um "W" Windows-APIs zu verwenden, aber eine "A" Windows-API aufzurufen, damit das "Best-Fit" der Unicode-Zeichenfolge erstellt wird.**
|
||||
|
||||
**Mehrere entdeckte Schwachstellen werden nicht behoben, da die Leute sich nicht einig sind, wer dieses Problem beheben sollte.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user