OAuth do preuzimanja naloga

Reading time: 13 minutes

Osnovne informacije

OAuth nudi različite verzije, sa osnovnim uvidima dostupnim na OAuth 2.0 dokumentacija. Ova diskusija se prvenstveno fokusira na široko korišćeni OAuth 2.0 tip dodeljivanja autorizacionog koda, pružajući okvir autorizacije koji omogućava aplikaciji da pristupi ili izvrši radnje na korisničkom nalogu u drugoj aplikaciji (autorizacioni server).

Zamislite hipotetičku veb stranicu https://example.com, dizajniranu da prikaže sve vaše objave na društvenim mrežama, uključujući privatne. Da bi to postigla, koristi se OAuth 2.0. https://example.com će zatražiti vašu dozvolu da pristupi vašim objavama na društvenim mrežama. Kao rezultat toga, na https://socialmedia.com će se pojaviti ekran za saglasnost, koji će prikazati dozvole koje se traže i programera koji podnosi zahtev. Nakon vaše autorizacije, https://example.com dobija mogućnost da pristupi vašim objavama u vaše ime.

Važno je razumeti sledeće komponente unutar OAuth 2.0 okvira:

• vlasnik resursa: Vi, kao korisnik/entitet, autorizujete pristup vašem resursu, kao što su objave na vašem nalogu na društvenim mrežama.
• server resursa: server koji upravlja autentifikovanim zahtevima nakon što je aplikacija obezbedila access token u ime vlasnika resursa, npr., https://socialmedia.com.
• klijentska aplikacija: aplikacija koja traži autorizaciju od vlasnika resursa, kao što je https://example.com.
• autorizacioni server: server koji izdaje access tokens klijentskoj aplikaciji nakon uspešne autentifikacije vlasnika resursa i obezbeđivanja autorizacije, npr., https://socialmedia.com.
• client_id: Javni, jedinstveni identifikator za aplikaciju.
• client_secret: Tajni ključ, poznat samo aplikaciji i autorizacionom serveru, koji se koristi za generisanje access_tokens.
• response_type: Vrednost koja specificira tip tokena koji se traži, kao što je code.
• scope: nivo pristupa koji klijentska aplikacija traži od vlasnika resursa.
• redirect_uri: URL na koji se korisnik preusmerava nakon autorizacije. Ovo obično mora biti u skladu sa unapred registrovanim URL-om za preusmeravanje.
• state: Parametar za održavanje podataka tokom preusmeravanja korisnika ka i sa autorizacionog servera. Njegova jedinstvenost je ključna za služenje kao mehanizam zaštite od CSRF.
• grant_type: Parametar koji označava tip dodeljivanja i tip tokena koji treba da bude vraćen.
• code: Autorizacioni kod sa autorizacionog servera, koji klijentska aplikacija koristi zajedno sa client_id i client_secret da bi dobila access_token.
• access_token: token koji klijentska aplikacija koristi za API zahteve u ime vlasnika resursa.
• refresh_token: Omogućava aplikaciji da dobije novi access_token bez ponovnog traženja od korisnika.

Tok

Aktuelni OAuth tok se odvija na sledeći način:

1. Idete na https://example.com i birate dugme “Integracija sa društvenim mrežama”.
2. Sajt zatim šalje zahtev na https://socialmedia.com tražeći vašu autorizaciju da aplikacija https://example.com pristupi vašim objavama. Zahtev je strukturiran kao:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Zatim se prikazuje stranica za pristanak.
4. Nakon vašeg odobrenja, Social Media šalje odgovor na redirect_uri sa code i state parametrima:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com koristi ovaj code, zajedno sa svojim client_id i client_secret, da izvrši zahtev na serverskoj strani kako bi dobio access_token u vaše ime, omogućavajući pristup dozvolama na koje ste pristali:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Na kraju, proces se završava kada https://example.com koristi vaš access_token za API poziv ka društvenim mrežama kako bi pristupio

Ranljivosti

Otvoreni redirect_uri

redirect_uri je ključan za bezbednost u OAuth i OpenID implementacijama, jer usmerava gde se osetljivi podaci, poput autorizacionih kodova, šalju nakon autorizacije. Ako je pogrešno konfigurisano, može omogućiti napadačima da preusmere ove zahteve na zlonamerne servere, omogućavajući preuzimanje naloga.

Tehnike eksploatacije variraju u zavisnosti od logike validacije autorizacionog servera. Mogu se kretati od stroge provere putanje do prihvatanja bilo kog URL-a unutar specificirane domene ili poddirektorijuma. Uobičajene metode eksploatacije uključuju otvorene redirekcije, prelazak putanje, iskorišćavanje slabih regex-a i HTML injekciju za krađu tokena.

Pored redirect_uri, drugi OAuth i OpenID parametri kao što su client_uri, policy_uri, tos_uri i initiate_login_uri su takođe podložni napadima preusmeravanja. Ovi parametri su opcioni i njihova podrška varira među serverima.

Za one koji ciljaju OpenID server, krajnja tačka otkrivanja (**.well-known/openid-configuration**) često navodi vredne konfiguracione detalje kao što su registration_endpoint, request_uri_parameter_supported i "require_request_uri_registration. Ovi detalji mogu pomoći u identifikaciji krajnje tačke registracije i drugih specifičnosti konfiguracije servera.

XSS u implementaciji preusmeravanja

Kao što je pomenuto u ovom izveštaju o bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, može biti moguće da se URL preusmeravanja odražava u odgovoru servera nakon što se korisnik autentifikuje, što ga čini ranjivim na XSS. Mogući payload za testiranje:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Nepravilno rukovanje parametrom stanja

U OAuth implementacijama, zloupotreba ili propuštanje state parametra može značajno povećati rizik od napada Cross-Site Request Forgery (CSRF). Ova ranjivost se javlja kada se state parametar ili ne koristi, koristi kao statička vrednost, ili se nevalidira pravilno, omogućavajući napadačima da zaobiđu CSRF zaštite.

Napadači mogu iskoristiti ovo tako što će presresti proces autorizacije kako bi povezali svoj nalog sa nalogom žrtve, što može dovesti do potencijalnih preuzimanja naloga. Ovo je posebno kritično u aplikacijama gde se OAuth koristi u svrhe autentifikacije.

Primeri iz stvarnog sveta ove ranjivosti dokumentovani su u raznim CTF izazovima i hacking platformama, ističući njene praktične implikacije. Problem se takođe proširuje na integracije sa uslugama trećih strana kao što su Slack, Stripe, i PayPal, gde napadači mogu preusmeriti obaveštenja ili uplate na svoje naloge.

Pravilno rukovanje i validacija state parametra su ključni za zaštitu od CSRF i osiguranje OAuth toka.

Preuzimanje naloga

1. Bez verifikacije email-a prilikom kreiranja naloga: Napadači mogu unapred kreirati nalog koristeći email žrtve. Ako žrtva kasnije koristi uslugu treće strane za prijavu, aplikacija može nenamerno povezati ovaj nalog treće strane sa napadačevim unapred kreiranim nalogom, što dovodi do neovlašćenog pristupa.
2. Iskorišćavanje labave verifikacije email-a u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju email adrese tako što će se registrovati sa svojom uslugom, a zatim promeniti email naloga na onaj žrtve. Ova metoda takođe nosi rizik od neovlašćenog pristupa nalogu, slično prvom scenariju, ali kroz drugačiji napadački vektor.

Otkriće tajni

Identifikacija i zaštita tajnih OAuth parametara je ključna. Dok se client_id može bezbedno otkriti, otkrivanje client_secret predstavlja značajne rizike. Ako je client_secret kompromitovan, napadači mogu iskoristiti identitet i poverenje aplikacije da ukradu korisničke access_tokens i privatne informacije.

Uobičajena ranjivost se javlja kada aplikacije greškom rukovode razmenom autorizacionog code za access_token na klijentskoj strani umesto na serverskoj strani. Ova greška dovodi do izlaganja client_secret, omogućavajući napadačima da generišu access_tokens pod krinkom aplikacije. Štaviše, putem socijalnog inženjeringa, napadači bi mogli da eskaliraju privilegije dodavanjem dodatnih opsega OAuth autorizaciji, dodatno iskorišćavajući poveren status aplikacije.

Bruteforce klijent tajne

Možete pokušati da bruteforce-ujete client_secret provajdera usluga sa identitetskim provajderom kako biste pokušali da ukradete naloge.
Zahtev za BF može izgledati slično:

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

Kada klijent ima code and state, ako je reflektovan unutar Referer header-a kada pretražuje drugu stranicu, onda je ranjiv.

Access Token Stored in Browser History

Idite na browser history i proverite da li je access token sačuvan tamo.

Everlasting Authorization Code

Authorization code bi trebao da živi samo neko vreme kako bi se ograničio vremenski prozor u kojem napadač može da ga ukrade i koristi.

Authorization/Refresh Token not bound to client

Ako možete da dobijete authorization code i koristite ga sa različitim klijentom, onda možete preuzeti druge naloge.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

U ovom izveštaju o bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ možete videti da token koji AWS Cognito vraća korisniku može imati dovoljno dozvola da prepiše korisničke podatke. Stoga, ako možete promeniti korisnički email za drugi korisnički email, možda ćete moći da preuzmete druge naloge.

# 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"
}
]
}

Za detaljnije informacije o tome kako zloupotrebiti AWS cognito, proverite:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Zloupotreba tokena drugih aplikacija

Kao što je spomenuto u ovom izveštaju, OAuth tokovi koji očekuju da prime token (a ne kod) mogli bi biti ranjivi ako ne provere da li token pripada aplikaciji.

To je zato što bi napadač mogao da kreira aplikaciju koja podržava OAuth i prijavu putem Facebook-a (na primer) u svojoj aplikaciji. Zatim, kada žrtva prijavi putem Facebook-a u napadačevoj aplikaciji, napadač bi mogao da dobije OAuth token korisnika dodeljen njegovoj aplikaciji i koristi ga za prijavu u žrtvinu OAuth aplikaciju koristeći žrtvin korisnički token.

Dva linka i kolačić

Prema ovom izveštaju, bilo je moguće naterati žrtvu da otvori stranicu sa returnUrl koji upućuje na napadačev host. Ove informacije bi bile smeštene u kolačiću (RU), a u kasnijem koraku prompt će pitati korisnika da li želi da da pristup tom napadačevom hostu.

Da bi se zaobišao ovaj prompt, bilo je moguće otvoriti tab za iniciranje Oauth toka koji bi postavio ovaj RU kolačić koristeći returnUrl, zatvoriti tab pre nego što se prompt prikaže, i otvoriti novi tab bez te vrednosti. Tada prompt neće obavestiti o napadačevom hostu, ali bi kolačić bio postavljen na njega, tako da će token biti poslat na napadačev host u redirekciji.

Zaobilaženje interakcije sa promptom

Kao što je objašnjeno u ovom videu, neke OAuth implementacije omogućavaju da se GET parametar prompt označi kao None (&prompt=none) kako bi se sprečilo da korisnici budu pitani da potvrde dodeljeni pristup u promptu na vebu ako su već prijavljeni na platformu.

response_mode

Kao što je objašnjeno u ovom videu, možda je moguće označiti parametar response_mode da se naznači gde želite da kod bude dostavljen u konačnom URL-u:

• response_mode=query -> Kod se pruža unutar GET parametra: ?code=2397rf3gu93f
• response_mode=fragment -> Kod se pruža unutar fragmenta URL-a #code=2397rf3gu93f
• response_mode=form_post -> Kod se pruža unutar POST forme sa inputom pod nazivom code i vrednošću
• response_mode=web_message -> Kod se šalje u post poruci: window.opener.postMessage({"code": "asdasdasd...

OAuth ROPC tok - zaobilaženje 2 FA

Prema ovom blog postu, ovo je OAuth tok koji omogućava prijavu u OAuth putem korisničkog imena i lozinke. Ako tokom ovog jednostavnog toka bude vraćen token sa pristupom svim radnjama koje korisnik može da izvrši, tada je moguće zaobići 2FA koristeći taj token.

ATO na veb stranici koja preusmerava na osnovu otvorenog preusmeravanja na referent

Ovaj blog post komentariše kako je bilo moguće zloupotrebiti otvoreno preusmeravanje na vrednost iz referenta da bi se zloupotrebio OAuth za ATO. Napad je bio:

1. Žrtva pristupa napadačevoj veb stranici
2. Žrtva otvara zlonamerni link i otvarač pokreće Google OAuth tok sa response_type=id_token,code&prompt=none kao dodatnim parametrima koristeći kao referent napadačevu veb stranicu.
3. U otvaraču, nakon što provajder odobri žrtvu, vraća ih nazad na vrednost parametra redirect_uri (žrtvina veb stranica) sa 30X kodom koji i dalje drži napadačevu veb stranicu u referentu.
4. Žrtvina veb stranica pokreće otvoreno preusmeravanje na osnovu referenta preusmeravajući žrtvinog korisnika na napadačevu veb stranicu, pošto je respose_type bio id_token,code, kod će biti vraćen napadaču u fragmentu URL-a omogućavajući mu da preuzme račun korisnika putem Google-a na žrtvinom sajtu.

SSRF parametri

Proverite ovo istraživanje Za dalja objašnjenja ove tehnike.

Dinamička registracija klijenata u OAuth služi kao manje očigledan, ali kritičan vektor za sigurnosne ranjivosti, posebno za Server-Side Request Forgery (SSRF) napade. Ova tačka omogućava OAuth serverima da prime detalje o klijentskim aplikacijama, uključujući osetljive URL-ove koji bi mogli biti zloupotrebljeni.

Ključne tačke:

• Dinamička registracija klijenata se često mapira na /register i prihvata detalje kao što su client_name, client_secret, redirect_uris, i URL-ove za logotipe ili JSON Web Key Sets (JWKs) putem POST zahteva.
• Ova funkcija se pridržava specifikacija navedenih u RFC7591 i OpenID Connect Registration 1.0, koje uključuju parametre koji su potencijalno ranjivi na SSRF.
• Proces registracije može nenamerno izložiti servere SSRF na nekoliko načina:
• logo_uri: URL za logo klijentske aplikacije koji bi server mogao da preuzme, pokrećući SSRF ili dovodeći do XSS ako se URL pogrešno obradi.
• jwks_uri: URL do JWK dokumenta klijenta, koji, ako je zlonamerno kreiran, može uzrokovati da server izvrši izlazne zahteve ka serveru pod kontrolom napadača.
• sector_identifier_uri: Upućuje na JSON niz redirect_uris, koji server može preuzeti, stvarajući priliku za SSRF.
• request_uris: Navodi dozvoljene URI zahteva za klijenta, koji se mogu zloupotrebiti ako server preuzme ove URI na početku procesa autorizacije.

Strategija eksploatacije:

• SSRF se može pokrenuti registracijom novog klijenta sa zlonamernim URL-ovima u parametrima kao što su logo_uri, jwks_uri, ili sector_identifier_uri.
• Dok direktna eksploatacija putem request_uris može biti ublažena kontrolama na osnovu bele liste, pružanje unapred registrovanog, napadačem kontrolisanog request_uri može olakšati SSRF tokom faze autorizacije.

OAuth provajderi trke

Ako je platforma koju testirate OAuth provajder pročitajte ovo da biste testirali moguće trke.

Reference

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors