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

232 lines
19 KiB
Markdown
Raw Blame History

# OAuth na Rekeningoorneming
<details>
<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Ander maniere om HackTricks te ondersteun:
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
</details>
<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 wyd gebruikte [OAuth 2.0-oorspronklike toestemmingstipe](https://oauth.net/2/grant-types/authorization-code/), wat 'n **toestemmingsraamwerk bied wat 'n aansoek in staat stel om toegang te verkry tot of aksies uit te voer op 'n gebruiker se rekening in 'n ander aansoek** (die toestemmingsdiens).
Beskou 'n hipotetiese webwerf _**https://voorbeeld.com**_, ontwerp om **al jou sosiale media plasings ten toon te stel**, insluitend privaat een. Om dit te bereik, word OAuth 2.0 gebruik. _https://voorbeeld.com_ sal jou toestemming vra om **toegang tot jou sosiale media plasings** te verkry. Gevolglik sal 'n toestemmingskerm op _https://sosialemedia.com_ verskyn wat die **toestemmings wat versoek word en die ontwikkelaar wat die versoek maak** uiteensit. Na jou toestemming kry _https://voorbeeld.com_ die vermoë om **namens jou toegang tot jou plasings te verkry**.
Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0-raamwerk te verstaan:
- **hulpbron-eienaar**: Jy, as die **gebruiker/entiteit**, gee toestemming vir toegang tot jou hulpbron, soos jou sosiale media-rekeningplasings.
- **hulpbronbediener**: Die **bediener wat geauthentiseerde versoek stuur** nadat die aansoek 'n `toegangstoken` namens die `hulpbron-eienaar` verkry het, bv. **https://sosialemedia.com**.
- **kliëntaansoek**: Die **aansoek wat toestemming soek** van die `hulpbron-eienaar`, soos **https://voorbeeld.com**.
- **toestemmingsdiens**: Die **bediener wat `toegangstokens` uitreik** aan die `kliëntaansoek` na die suksesvolle outentifisering van die `hulpbron-eienaar` en die verkryging van toestemming, bv. **https://sosialemedia.com**.
- **kliënt\_id**: 'n Openbare, unieke identifiseerder vir die aansoek.
- **kliëntgeheim:** 'n vertroulike sleutel, slegs bekend aan die aansoek en die toestemmingsdiens, wat gebruik word vir die genereer van `toegangstokens`.
- **response\_type**: 'n waarde wat **die tipe token wat versoek word, spesifiseer**, soos `code`.
- **scope**: Die **vlak van toegang** wat die `kliëntaansoek` van die `hulpbron-eienaar` versoek.
- **redirect\_uri**: Die **URL waarna die gebruiker na toestemming omgelei word**. Dit moet tipies ooreenstem met die vooraf geregistreerde omleidings-URL.
- **state**: 'n parameter om **data oor die gebruiker se omleiding na en van die toestemmingsdiens te behou**. Sy uniekheid is krities vir die diens as 'n **CSRF-beskermingsmeganisme**.
- **grant\_type**: 'n parameter wat **die toestemmingstipe en die tipe token wat teruggegee moet word, aandui**.
- **code**: Die toestemmingskode van die `toestemmingsdiens`, wat saam met `kliënt_id` en `kliëntgeheim` deur die kliëntaansoek gebruik word om 'n `toegangstoken` te bekom.
- **toegangstoken**: Die **token wat die kliëntaansoek gebruik vir API-versoeke** namens die `hulpbron-eienaar`.
- **ververs\_token**: Maak dit vir die aansoek moontlik om 'n nuwe `toegangstoken` te **verkry sonder om die gebruiker weer te versoek**.
### Vloei
Die **werklike OAuth-vloei** verloop soos volg:
1. Jy navigeer na [https://voorbeeld.com](https://voorbeeld.com) en kies die "Integreer met Sosiale Media" knoppie.
2. Die webwerf stuur dan 'n versoek na [https://sosialemedia.com](https://sosialemedia.com) om jou toestemming te vra om https://voorbeeld.com se aansoek 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 voorgehou met 'n toestemmingsbladsy.
4. Na jou goedkeuring stuur die sosiale media 'n reaksie na die `redirect_uri` met die `code` en `state` parameters:
```
https://example.com?code=uniqueCode123&state=randomString123
```
5. https://example.com maak gebruik van hierdie `code`, saam met sy `client_id` en `client_secret`, om 'n serverkant versoek te maak om 'n `access_token` namens jou te verkry, wat toegang gee tot die toestemmings wat jy ingestem het:
```
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. Laastens, die proses sluit af as https://example.com jou `access_token` gebruik om 'n API-oproep aan sosiale media te maak om toegang te verkry
## Swakhede <a href="#323a" id="323a"></a>
### Oop omleidings\_uri <a href="#cc36" id="cc36"></a>
Die `redirect_uri` is noodsaaklik vir sekuriteit in OAuth en OpenID-implementasies, aangesien dit aandui waar sensetiewe data, soos magtigingskodes, na magtiging gestuur word. Indien verkeerd gekonfigureer, kan dit aanvallers moontlik maak om hierdie versoek na skadelike bedieners om te lei, wat rekening-oorneem moontlik maak.
Uitbuitingstegnieke wissel gebaseer op die valideringslogika van die magtigingbediener. Dit kan wissel van streng pad-passing tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Gewone uitbuitingsmetodes sluit oop omleidings, padtraversering, die uitbuiting van swak regexe, 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 vatbaar vir omleidingsaanvalle. Hierdie parameters is opsioneel en hul ondersteuning wissel tussen bedieners.
Vir diegene wat 'n OpenID-bediener teiken, lys die ontdekkings-eindpunt (`**.well-known/openid-configuration**`) dikwels waardevolle konfigurasiebesonderhede 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 omleidingsimplementasie <a href="#bda5" id="bda5"></a>
Soos genoem in hierdie foutvindingsverslag [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) is dit moontlik dat die omleidings-URL in die respons van die bediener na die gebruiker se verifikasie **weerspieël word**, wat **vatbaar vir XSS** is. Moontlike lading om te toets:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Onvanige hantering van die staat parameter <a href="#bda5" id="bda5"></a>
In OAuth-implementasies kan die misbruik of weglaat van die **`state` parameter** die risiko van **Cross-Site Request Forgery (CSRF)**-aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die `state` parameter óf **nie gebruik word nie, as 'n statiese waarde gebruik word, of nie behoorlik gevalideer word nie**, wat aanvallers in staat stel om CSRF-beskerming te omseil.
Aanvallers kan hierdie kwesbaarheid uitbuit deur die magtigingsproses te onderskep om hul rekening met 'n slagoffer se rekening te skakel, wat kan lei tot potensiële **rekening-oorneemings**. Dit is veral krities in toepassings waar OAuth gebruik word vir **verifikasiedoeleindes**.
Regte-wêreld voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie **CTF-uitdagings** en **hakplatforms**, wat die praktiese implikasies daarvan beklemtoon. Die probleem strek ook tot integrasies met derdeparty dienste soos **Slack**, **Stripe**, en **PayPal**, waar aanvallers kennisgewings of betalings na hul rekeninge kan omskakel.
Behoorlike hantering en validering van die **`state` parameter** is noodsaaklik om teen CSRF te beskerm en die OAuth-vloei te beveilig.
### Voor Rekening-oorneemings <a href="#ebe4" id="ebe4"></a>
1. **Sonner E-posverifikasie by Rekening Skepping**: Aanvallers kan voortydig 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdepartydiens vir aanmelding gebruik, kan die aansoek per ongeluk hierdie derdeparty-rekening aan die aanvaller se voorgeskepte rekening koppel, wat tot ongemagtigde toegang kan lei.
2. **Uitbuiting van Laks OAuth E-posverifikasie**: Aanvallers kan OAuth-dienste uitbuit wat nie e-posse verifieer deur met hul diens te registreer en dan die rekening se e-pos na die slagoffer se e-pos te verander. Hierdie metode loop soortgelyk risiko van ongemagtigde rekeningtoegang, soortgelyk aan die eerste scenario, maar deur 'n ander aanvalvektor.
### Bekendmaking van Geheime <a href="#e177" id="e177"></a>
Die identifisering en beskerming van geheime OAuth parameters is noodsaaklik. Terwyl die **`client_id`** veilig bekendgemaak kan word, stel die bekendmaking van die **`client_secret`** aansienlike risiko's. As die `client_secret` gekompromitteer word, kan aanvallers die identiteit en vertroue van die aansoek uitbuit om gebruiker se `access_tokens` en privaat inligting te **steel**.
'n Algemene kwesbaarheid ontstaan wanneer aansoeke die uitruil van die magtigings `code` vir 'n `access_token` aan die kliëntkant hanteer in plaas van die bedienerkant. Hierdie fout lei tot die blootstelling van die `client_secret`, wat aanvallers in staat stel om `access_tokens` onder die skyn van die aansoek te genereer. Verder kan aanvallers deur sosiale manipulasie voorregte eskaleer deur addisionele omvang aan die OAuth-magtiging toe te voeg, wat die vertroude status van die aansoek verder uitbuit.
### Kliënt Geheim Bruteforce
Jy kan probeer om die **kliënt_geheim bruteforce** van 'n diensverskaffer met die identiteitsverskaffer te wees om rekeninge te steel.\
Die versoek vir BF kan soortgelyk lyk aan:
```
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 lek Code + State
Sodra die klient die **kode en staat** het, as dit **weerspieël word binne die Referer-kop** wanneer hy na 'n ander bladsy blaai, dan is dit kwesbaar.
### Toegangsteken gestoor in Blaaigeskiedenis
Gaan na die **blaaigeskiedenis en kyk of die toegangsteken daar gestoor is**.
### Ewige Magtigingskode
Die **magtigingskode behoort net vir 'n rukkie te leef om die tydvenster te beperk waar 'n aanvaller dit kan steel en gebruik**.
### Magtigings/Vernuwings Teken nie aan klient gebind nie
As jy die **magtigingskode kan kry en dit met 'n ander klient kan gebruik, kan jy ander rekeninge oorneem**.
### Gelukkige Paaie, XSS, Iframes & Posboodskappe om kode & staat waardes te lek
**[Kyk na hierdie pos](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 foutvindingsverslag: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) kan jy sien dat die **teken** wat **AWS Cognito** aan die gebruiker teruggee, dalk **genoeg regte het om die gebruikersdata te oorskryf**. Daarom, as jy die **gebruiker se e-pos vir 'n ander gebruiker se e-pos kan verander**, kan jy dalk **ander rekeninge oorneem**.
```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"
}
]
}
```
Vir meer gedetailleerde inligting oor hoe om AWS Cognito te misbruik, kyk:
{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}
### Misbruik van ander Apps se tokens <a href="#bda5" id="bda5"></a>
Soos [**vermeld in hierdie uiteensetting**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), kan OAuth-vloeiwyses wat verwag om die **token** (en nie 'n kode) te ontvang, kwesbaar wees as hulle nie nagaan of die token aan die program behoort nie.
Dit is omdat 'n **aanvaller** 'n **toepassing wat OAuth ondersteun en met Facebook inlog** (byvoorbeeld) in sy eie toepassing kan skep. Dan, sodra 'n slagoffer met Facebook in die **aanvaller se toepassing** inlog, kan die aanvaller die **OAuth-token van die gebruiker wat aan sy toepassing gegee is, kry en dit gebruik om in te log in die slagoffer se OAuth-toepassing deur die slagoffer se gebruikerstoken**.
{% hint style="danger" %}
Daarom, as die aanvaller daarin slaag om die gebruiker sy eie OAuth-toepassing te laat gebruik, sal hy in staat wees om die slagoffer se rekening in toepassings oor te neem wat 'n token verwag en nie nagaan of die token aan hul program-ID toegeken is nie.
{% endhint %}
### Twee skakels & koekie <a href="#bda5" id="bda5"></a>
Volgens [**hierdie uiteensetting**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), was dit moontlik om 'n slagoffer 'n bladsy met 'n **returnUrl** wat na die aanvaller se gasheer wys, te laat oopmaak. Hierdie inligting sou in 'n koekie (RU) **gestoor word** en in 'n **later stap** sal die **prompt** die **gebruiker vra** of hy toegang wil gee aan daardie aanvaller se gasheer.
Om hierdie prompt te omseil, was dit moontlik om 'n lus te open om die **Oauth-vloei** te begin wat hierdie RU-koekie met die **returnUrl** sou instel, die lus te sluit voordat die prompt vertoon word, en 'n nuwe lus sonder daardie waarde te open. Dan sal die **prompt nie oor die aanvaller se gasheer inlig nie**, maar die koekie sal daaraan gestel word, sodat die **token na die aanvaller se gasheer gestuur sal word** in die omleiding.
### SSRF-parameters <a href="#bda5" id="bda5"></a>
**[Kyk na hierdie navorsing](https://portswigger.net/research/hidden-oauth-attack-vectors) vir verdere besonderhede oor hierdie tegniek.**
Dinamiese Kliëntregistrasie in OAuth dien as 'n minder voor die hand liggende maar kritieke vektor vir sekuriteitskwessies, spesifiek vir **Server-Side Request Forgery (SSRF)**-aanvalle. Hierdie eindpunt laat OAuth-bedieners toe om besonderhede oor kliënttoepassings te ontvang, insluitend sensitiewe URL's wat uitgebuit kan word.
**Kernpunte:**
- **Dinamiese Kliëntregistrasie** word dikwels gekarteer na `/register` 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 kenmerk voldoen aan spesifikasies wat uiteengesit is in **RFC7591** en **OpenID Connect Registration 1.0**, wat parameters insluit wat potensieel vatbaar is vir SSRF.
- Die registrasieproses kan bedieners onbedoeld blootstel aan SSRF op verskeie maniere:
- **`logo_uri`**: 'n URL vir die kliënttoepassing se logo wat deur die bediener opgehaal kan word, wat SSRF kan veroorsaak of tot XSS kan lei as die URL verkeerd hanteer word.
- **`jwks_uri`**: 'n URL na die kliënt se JWK-dokument, wat indien booswillig saamgestel, die bediener kan dwing om uitgaande versoeke na 'n aanvallerbeheerde bediener te maak.
- **`sector_identifier_uri`**: Verwys na 'n JSON-reeks van `redirect_uris`, wat die bediener kan ophaal, wat 'n SSRF-geleentheid kan skep.
- **`request_uris`**: Lys toegelate versoek-URL's vir die kliënt, wat uitgebuit kan word as die bediener hierdie URL's aan die begin van die magtigingsproses ophaal.
**Uitbuitingsstrategie:**
- SSRF kan geaktiveer word deur 'n nuwe kliënt met booswillige URL's in parameters soos `logo_uri`, `jwks_uri`, of `sector_identifier_uri` te registreer.
- Terwyl direkte uitbuiting via `request_uris` gematig kan word deur witlysbeheer, kan die voorsiening van 'n voorafgeregistreerde, aanvallerbeheerde `request_uri` SSRF tydens die magtigingsfase fasiliteer.
## OAuth-aanbieders Race Voorwaardes
As die platform wat jy toets 'n OAuth-aanbieder is, [**lees hierdie om te toets vir moontlike Race Voorwaardes**](race-condition.md).
## Verwysings
* [**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/" %}
<details>
<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Ander maniere om HackTricks te ondersteun:
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFT's**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
</details>
Reference in a new issue View git blame Copy permalink