Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

243 lines
20 KiB
Markdown
Raw Blame History

# OAuth na rekening oorname
{% hint style="success" %}
Leer & oefen AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Leer & oefen GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Ondersteun HackTricks</summary>
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
{% endhint %}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## Basiese Inligting <a href="#d4a8" id="d4a8"></a>
OAuth bied verskeie weergawes, met fundamentele insigte beskikbaar by [OAuth 2.0 dokumentasie](https://oauth.net/2/). Hierdie bespreking fokus hoofsaaklik op die algemeen gebruikte [OAuth 2.0 magtigingskode toekennings tipe](https://oauth.net/2/grant-types/authorization-code/), wat 'n **magtigingsraamwerk bied wat 'n toepassing in staat stel om toegang te verkry of aksies op 'n gebruiker se rekening in 'n ander toepassing uit te voer** (die magtigingsbediener).
Dink aan 'n hipotetiese webwerf _**https://example.com**_, ontwerp om **al jou sosiale media plasings te vertoon**, insluitend privaat ones. Om dit te bereik, word OAuth 2.0 gebruik. _https://example.com_ sal jou toestemming vra om **toegang tot jou sosiale media plasings** te verkry. Gevolglik sal 'n toestemmingskerm op _https://socialmedia.com_ verskyn, wat die **toestemmings wat aangevra word en die ontwikkelaar wat die versoek doen** uiteensit. Na jou magtiging, verkry _https://example.com_ die vermoë om **jou plasings namens jou te benader**.
Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0 raamwerk te verstaan:
* **hulpbron eienaar**: Jy, as die **gebruiker/entiteit**, magtig toegang tot jou hulpbron, soos jou sosiale media rekening plasings.
* **hulpbron bediener**: Die **bediener wat geverifieerde versoeke bestuur** nadat die toepassing 'n `access token` namens die `hulpbron eienaar` verkry het, bv. **https://socialmedia.com**.
* **klient toepassing**: Die **toepassing wat magtiging soek** van die `hulpbron eienaar`, soos **https://example.com**.
* **magtigingsbediener**: Die **bediener wat `access tokens` uitreik** aan die `klient toepassing` na die suksesvolle verifikasie van die `hulpbron eienaar` en die verkryging van magtiging, bv. **https://socialmedia.com**.
* **client\_id**: 'n Publieke, unieke identifiseerder vir die toepassing.
* **client\_secret:** 'n Vertroulike sleutel, bekend slegs aan die toepassing en die magtigingsbediener, wat gebruik word om `access_tokens` te genereer.
* **response\_type**: 'n Waarde wat **die tipe token wat aangevra word** spesifiseer, soos `code`.
* **scope**: Die **vlak van toegang** wat die `klient toepassing` van die `hulpbron eienaar` aan vra.
* **redirect\_uri**: Die **URL waarnatoe die gebruiker herlei word na magtiging**. Dit moet gewoonlik ooreenstem met die vooraf geregistreerde herlei URL.
* **state**: 'n parameter om **data te handhaaf oor die gebruiker se herleiding na en van die magtigingsbediener**. Die uniekheid daarvan is krities om as 'n **CSRF beskermingsmeganisme** te dien.
* **grant\_type**: 'n parameter wat **die toekennings tipe en die tipe token wat teruggegee moet word** aandui.
* **code**: Die magtigingskode van die `magtigingsbediener`, wat saam met `client_id` en `client_secret` deur die klient toepassing gebruik word om 'n `access_token` te verkry.
* **access\_token**: Die **token wat die klient toepassing gebruik vir API versoeke** namens die `hulpbron eienaar`.
* **refresh\_token**: Stel die toepassing in staat om **'n nuwe `access_token` te verkry sonder om die gebruiker weer te vra**.
### Stroom
Die **werklike OAuth stroom** verloop soos volg:
1. Jy navigeer na [https://example.com](https://example.com) en kies die “Integreer met Sosiale Media” knoppie.
2. Die webwerf stuur dan 'n versoek na [https://socialmedia.com](https://socialmedia.com) om jou magtiging te vra om https://example.com se toepassing toegang tot jou plasings te gee. Die versoek is gestruktureer as:
```
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3. Jy word dan met 'n toestemmingbladsy voorgestel.
4. Na jou goedkeuring, stuur Sosiale Media 'n antwoord na die `redirect_uri` met die `code` en `state` parameters:
```
https://example.com?code=uniqueCode123&state=randomString123
```
5. https://example.com gebruik hierdie `code`, saam met sy `client_id` en `client_secret`, om 'n bediener-kant versoek te maak om 'n `access_token` namens jou te verkry, wat toegang tot die toestemmings wat jy goedgekeur het, moontlik maak:
```
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. Laastens sluit die proses af wanneer https://example.com jou `access_token` gebruik om 'n API-oproep na Sosiale Media te maak om toegang te verkry
## Kw vulnerabilities <a href="#id-323a" id="id-323a"></a>
### Open redirect\_uri <a href="#cc36" id="cc36"></a>
Die `redirect_uri` is van kardinale belang vir sekuriteit in OAuth en OpenID implementasies, aangesien dit aandui waar sensitiewe data, soos magtigingskode, gestuur word na magtiging. As dit verkeerd geconfigureer is, kan dit aanvallers toelaat om hierdie versoeke na kwaadwillige bedieners te herlei, wat rekening oorname moontlik maak.
Eksploitasiemetodes verskil op grond van die magtigingsbediener se valideringslogika. Dit kan wissel van streng pad ooreenstemming tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Algemene eksploitasiemetodes sluit open redirects, pad traversering, die benutting van swak regexes, en HTML-inspuiting vir token-diefstal in.
Benewens `redirect_uri`, is ander OAuth en OpenID parameters soos `client_uri`, `policy_uri`, `tos_uri`, en `initiate_login_uri` ook kwesbaar vir herleidingaanvalle. Hierdie parameters is opsioneel en hul ondersteuning verskil oor bedieners.
Vir diegene wat 'n OpenID-bediener teiken, lys die ontdekking eindpunt (`**.well-known/openid-configuration**`) dikwels waardevolle konfigurasiedetails soos `registration_endpoint`, `request_uri_parameter_supported`, en "`require_request_uri_registration`. Hierdie besonderhede kan help om die registrasie-eindpunt en ander konfigurasiespesifieke van die bediener te identifiseer.
### XSS in redirect implementering <a href="#bda5" id="bda5"></a>
Soos genoem in hierdie bug bounty verslag [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) mag dit moontlik wees dat die redirect **URL in die antwoord** van die bediener weerkaats word nadat die gebruiker geverifieer is, wat **kwesbaar is vir XSS**. Moglike payload om te toets:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Onbehoorlike hantering van die staat parameter <a href="#bda5" id="bda5"></a>
In OAuth implementasies kan die misbruik of omissie van die **`state` parameter** die risiko van **Cross-Site Request Forgery (CSRF)** aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die `state` parameter **nie gebruik word, as 'n statiese waarde gebruik word, of nie behoorlik geverifieer word nie**, wat dit aanvallers moontlik maak om CSRF beskermings te omseil.
Aanvallers kan dit benut deur die magtiging proses te onderskep om hul rekening met 'n slagoffer se rekening te koppel, wat kan lei tot potensiële **rekening oorname**. Dit is veral krities in toepassings waar OAuth gebruik word vir **authentikasie doeleindes**.
Werklike voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie **CTF uitdagings** en **hacking platforms**, wat die praktiese implikasies daarvan uitlig. Die probleem strek ook tot integrasies met derdeparty dienste soos **Slack**, **Stripe**, en **PayPal**, waar aanvallers kennisgewings of betalings na hul rekeninge kan herlei.
Behoorlike hantering en verifikasie van die **`state` parameter** is van kardinale belang om teen CSRF te beskerm en die OAuth vloei te beveilig.
### Voor Rekening Oorname <a href="#ebe4" id="ebe4"></a>
1. **Sonder E-pos Verifikasie by Rekening Skep**: Aanvallers kan proaktief 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdeparty diens vir aanmelding gebruik, kan die toepassing per ongeluk hierdie derdeparty rekening aan die aanvaller se vooraf geskepte rekening koppel, wat lei tot ongemagtigde toegang.
2. **Misbruik van Los OAuth E-pos Verifikasie**: Aanvallers mag OAuth dienste misbruik wat nie e-posse verifieer nie deur met hul diens te registreer en dan die rekening e-pos na die slagoffer s'n te verander. Hierdie metode hou soortgelyke risiko's van ongemagtigde rekening toegang in, soortgelyk aan die eerste scenario, maar deur 'n ander aanvalsvector.
### Onthulling van Geheime <a href="#e177" id="e177"></a>
Identifisering en beskerming van geheime OAuth parameters is van kardinale belang. Terwyl die **`client_id`** veilig onthul kan word, hou die onthulling van die **`client_secret`** aansienlike risiko's in. As die `client_secret` gecompromitteer word, kan aanvallers die identiteit en vertroue van die toepassing benut om **gebruikers `access_tokens`** en private inligting te **steel**.
'n Algemene kwesbaarheid ontstaan wanneer toepassings per ongeluk die uitruil van die magtiging `code` vir 'n `access_token` aan die kliënt-kant hanteer eerder as die bediener-kant. Hierdie fout lei tot die blootstelling van die `client_secret`, wat dit aanvallers moontlik maak om `access_tokens` onder die dekmantel van die toepassing te genereer. Boonop, deur sosiale ingenieurswese, kan aanvallers voorregte verhoog deur addisionele skope by die OAuth magtiging te voeg, wat die toepassing se vertroude status verder benut.
### Kliënt Geheim Bruteforce
Jy kan probeer om die **client\_secret** van 'n diensverskaffer met die identiteitsverskaffer te **bruteforce** om te probeer om rekeninge te steel.\
Die versoek om BF mag soos volg lyk:
```
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 leaking Code + State
Sodra die kliënt die **code en state** het, as dit **binne die Referer-header weerspieël word** wanneer hy na 'n ander bladsy blaai, dan is dit kwesbaar.
### Access Token Stored in Browser History
Gaan na die **blaaier geskiedenis en kyk of die toegangstoken daarin gestoor is**.
### Everlasting Authorization Code
Die **autoriseringkode moet net vir 'n kort tydjie bestaan om die tydsvenster te beperk waarbinne 'n aanvaller dit kan steel en gebruik**.
### Authorization/Refresh Token not bound to client
As jy die **autoriseringkode kan kry en dit met 'n ander kliënt kan gebruik, kan jy ander rekeninge oorneem**.
### Happy Paths, XSS, Iframes & Post Messages to leak code & state values
[**Check this post**](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 hierdie foutbounty verslag: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) kan jy sien dat die **token** wat **AWS Cognito** aan die gebruiker teruggee, **voldoende toestemmings kan hê om die gebruikersdata te oorskryf**. Daarom, as jy die **gebruikers e-pos vir 'n ander gebruikers e-pos kan verander**, mag jy in staat wees om **ander** rekeninge **oor te neem**.
```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"
}
]
}
```
For more detailed info about how to abuse AWS cognito check:
{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}
### Abusing other Apps tokens <a href="#bda5" id="bda5"></a>
Soos [**genoem in hierdie skrywe**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth vloei wat verwag om die **token** (en nie 'n kode nie) te ontvang, kan kwesbaar wees as hulle nie nagaan dat die token aan die app behoort nie.
Dit is omdat 'n **aanvaller** 'n **aansoek kan skep wat OAuth ondersteun en met Facebook kan aanmeld** (byvoorbeeld) in sy eie aansoek. Dan, sodra 'n slagoffer met Facebook in die **aanvaller se aansoek** aanmeld, kan die aanvaller die **OAuth token van die gebruiker wat aan sy aansoek gegee is, verkry en dit gebruik om in die slagoffer se OAuth aansoek aan te meld met die slagoffer se gebruiker token**.
{% hint style="danger" %}
Daarom, as die aanvaller daarin slaag om die gebruiker toegang te gee tot sy eie OAuth aansoek, sal hy in staat wees om die slagoffer se rekening in aansoeke wat 'n token verwag en nie nagaan of die token aan hul app ID toegeken is nie, oor te neem.
{% endhint %}
### Two links & cookie <a href="#bda5" id="bda5"></a>
Volgens [**hierdie skrywe**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), was dit moontlik om 'n slagoffer 'n bladsy te laat oopmaak met 'n **returnUrl** wat na die aanvaller se gasheer wys. Hierdie inligting sou **in 'n koekie (RU)** gestoor word en in 'n **latere stap** sal die **prompt** die **gebruiker** vra of hy toegang wil gee tot daardie aanvaller se gasheer.
Om hierdie prompt te omseil, was dit moontlik om 'n tab te open om die **Oauth vloei** te begin wat hierdie RU koekie met die **returnUrl** sou stel, die tab te sluit voordat die prompt vertoon word, en 'n nuwe tab te open sonder daardie waarde. Dan, die **prompt sal nie oor die aanvaller se gasheer inligting gee nie**, maar die koekie sou daartoe gestel word, sodat die **token na die aanvaller se gasheer gestuur sal word** in die herleiding.
### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
Soos verduidelik in [**hierdie video**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), laat sommige OAuth implementasies toe om die **`prompt`** GET parameter as None (**`&prompt=none`**) aan te dui om **te voorkom dat gebruikers gevra word om die gegewe toegang in 'n prompt op die web te bevestig as hulle reeds in die platform aangemeld is**.
### response\_mode
Soos [**verduidelik in hierdie video**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), mag dit moontlik wees om die parameter **`response_mode`** aan te dui om aan te dui waar jy wil hê die kode in die finale URL verskaf moet word:
* `response_mode=query` -> Die kode word binne 'n GET parameter verskaf: `?code=2397rf3gu93f`
* `response_mode=fragment` -> Die kode word binne die URL fragment parameter verskaf `#code=2397rf3gu93f`
* `response_mode=form_post` -> Die kode word binne 'n POST vorm met 'n invoer genaamd `code` en die waarde verskaf
* `response_mode=web_message` -> Die kode word in 'n pos boodskap gestuur: `window.opener.postMessage({"code": "asdasdasd...`
### SSRFs parameters <a href="#bda5" id="bda5"></a>
[**Kyk na hierdie navorsing**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Vir verdere besonderhede van hierdie tegniek.**
Dinamiese Kliënt Registrasie in OAuth dien as 'n minder voor die hand liggende maar kritieke vektor vir sekuriteits kwesbaarhede, spesifiek vir **Server-Side Request Forgery (SSRF)** aanvalle. Hierdie eindpunt laat OAuth bedieners toe om besonderhede oor kliënt aansoeke te ontvang, insluitend sensitiewe URL's wat uitgebuit kan word.
**Belangrike Punten:**
* **Dinamiese Kliënt Registrasie** word dikwels aan `/register` gekoppel en aanvaar besonderhede soos `client_name`, `client_secret`, `redirect_uris`, en URL's vir logo's of JSON Web Key Sets (JWKs) via POST versoeke.
* Hierdie funksie voldoen aan spesifikasies uiteengesit in **RFC7591** en **OpenID Connect Registrasie 1.0**, wat parameters insluit wat moontlik kwesbaar is vir SSRF.
* Die registrasie proses kan per ongeluk bedieners aan SSRF blootstel op verskeie maniere:
* **`logo_uri`**: 'n URL vir die kliënt aansoek se logo wat deur die bediener verkry kan word, wat SSRF kan ontketen of kan lei tot XSS as die URL verkeerd hanteer word.
* **`jwks_uri`**: 'n URL na die kliënt se JWK dokument, wat, as dit kwaadwillig saamgestel is, kan veroorsaak dat die bediener uitgaande versoeke na 'n aanvaller-beheerde bediener maak.
* **`sector_identifier_uri`**: Verwys na 'n JSON-array van `redirect_uris`, wat die bediener mag verkry, wat 'n SSRF geleentheid skep.
* **`request_uris`**: Lys toegelate versoek URI's vir die kliënt, wat uitgebuit kan word as die bediener hierdie URI's aan die begin van die outorisering proses verkry.
**Eksploitasiestategie:**
* SSRF kan ontketen word deur 'n nuwe kliënt met kwaadwillige URL's in parameters soos `logo_uri`, `jwks_uri`, of `sector_identifier_uri` te registreer.
* Terwyl direkte eksploitatie via `request_uris` moontlik beperk kan word deur witlysbeheer, kan die verskaffing van 'n vooraf geregistreerde, aanvaller-beheerde `request_uri` SSRF gedurende die outorisering fase fasiliteer.
## OAuth providers Race Conditions
As die platform wat jy toets 'n OAuth verskaffer is [**lees dit om vir moontlike Race Conditions te toets**](race-condition.md).
## References
* [**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="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{% hint style="success" %}
Leer & oefen AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Leer & oefen GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
{% endhint %}
Reference in a new issue View git blame Copy permalink