OAuth to Account takeover
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
OAuth nudi različite verzije, sa osnovnim uvidima dostupnim na OAuth 2.0 documentation. Ova diskusija se prvenstveno fokusira na široko korišćeni OAuth 2.0 authorization code grant type, pružajući okvir autorizacije koji omogućava aplikaciji da pristupi ili izvrši radnje na korisničkom nalogu u drugoj aplikaciji (server za autorizaciju).
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:
resource owner: Vi, kao korisnik/entitet, autorizujete pristup vašem resursu, kao što su objave na vašem nalogu na društvenim mrežama.
resource server: server koji upravlja autentifikovanim zahtevima nakon što je aplikacija obezbedila access token u ime resource owner, npr. https://socialmedia.com.
client application: aplikacija koja traži autorizaciju od resource owner, kao što je https://example.com.
authorization server: server koji izdaje access tokens klijentskoj aplikaciji nakon uspešne autentifikacije resource owner i obezbeđivanja autorizacije, npr. https://socialmedia.com.
client_id: Javni, jedinstveni identifikator za aplikaciju.
client_secret: Tajni ključ, poznat samo aplikaciji i serveru za autorizaciju, 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 resource owner.
redirect_uri: URL na koji se korisnik preusmerava nakon autorizacije. Ovo obično mora biti u skladu sa prethodno registrovanim URL-om za preusmeravanje.
state: Parametar za održavanje podataka tokom preusmeravanja korisnika ka i sa servera za autorizaciju. Njegova jedinstvenost je ključna za služenje kao mehanizam zaštite od CSRF.
grant_type: Parametar koji označava tip granta i tip tokena koji će biti vraćen.
code: Autorizacioni kod sa authorization server, 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 resource owner.
refresh_token: Omogućava aplikaciji da dobije novi access_token bez ponovnog traženja od korisnika.
Aktuelni OAuth tok se odvija na sledeći način:
Idete na https://example.com i birate dugme “Integrate with Social Media”.
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:
Zatim se prikazuje stranica za pristanak.
Nakon vašeg odobrenja, Social Media šalje odgovor na redirect_uri sa code i state parametrima:
https://example.com koristi ovaj code, zajedno sa svojim client_id i client_secret, da izvrši server-side zahtev za dobijanje access_token u vaše ime, omogućavajući pristup dozvolama na koje ste pristali:
Na kraju, proces se završava kada https://example.com koristi vaš access_token da izvrši API poziv ka društvenim mrežama kako bi pristupio
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 detalje o konfiguraciji 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.
Kao što je pomenuto u ovom izveštaju o nagradama za greške 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:
U OAuth implementacijama, zloupotreba ili izostavljanje state parametra može značajno povećati rizik od Cross-Site Request Forgery (CSRF) napada. Ova ranjivost nastaje 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štitu.
Napadači mogu iskoristiti ovo presrećući 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.
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.
Iskorišćavanje labave verifikacije email-a u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju email adrese tako što se registruju sa svojom uslugom, a zatim menjaju 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.
Identifikacija i zaštita tajnih OAuth parametara je ključna. Dok se client_id može bezbedno otkriti, otkrivanje client_secret nosi 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 nastaje 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 eskalirati privilegije dodavanjem dodatnih opsega u OAuth autorizaciju, dodatno iskorišćavajući povereni status aplikacije.
Možete pokušati da bruteforce-ujete client_secret provajdera usluga sa provajderom identiteta kako biste pokušali da ukradete naloge. Zahtev za BF može izgledati slično:
Kada klijent ima code i state, ako je reflektovan unutar Referer header-a kada pretražuje drugu stranicu, onda je ranjiv.
Idite na istoriju pretraživača i proverite da li je access token sačuvan tamo.
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.
Ako možete da dobijete authorization code i koristite ga sa različitim klijentom, onda možete preuzeti druge naloge.
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.
For more detailed info about how to abuse AWS cognito check:
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 prijavi se 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 token korisnika žrtve.
Stoga, ako napadač uspe da dobije pristup korisniku svojoj OAuth aplikaciji, moći će da preuzme žrtvin račun u aplikacijama koje očekuju token i ne provere da li je token dodeljen njihovom ID-u aplikacije.
Prema ovom izveštaju, bilo je moguće naterati žrtvu da otvori stranicu sa returnUrl koja pokazuje 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 preusmeravanju.
Kao što je objašnjeno u ovom videu, neke OAuth implementacije omogućavaju da se prompt GET parametar označi kao None (&prompt=none) kako bi se sprečilo da se korisnicima postavlja pitanje da potvrde dodeljeni pristup u promptu na vebu ako su već prijavljeni na platformu.
Kao što je objašnjeno u ovom videu, možda bi bilo 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 nazvanim code i vrednošću
response_mode=web_message -> Kod se šalje u post poruci: window.opener.postMessage({"code": "asdasdasd...
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.
Ovaj blog post komentariše kako je bilo moguće zloupotrebiti otvoreno preusmeravanje na vrednost iz referrera da bi se zloupotrebio OAuth za ATO. Napad je bio:
Žrtva pristupa napadačevoj veb stranici
Ž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 referrer napadačevu veb stranicu.
U otvaraču, nakon što provajder odobri žrtvu, vraća ih nazad na vrednost parametra redirect_uri (žrtvina veb) sa 30X kodom koji i dalje drži napadačevu veb stranicu u refereru.
Žrtvina veb stranica pokreće otvoreno preusmeravanje zasnovano na referreru preusmeravajući korisnika žrtve 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.
Pogledajte ovo istraživanje Za daljnje detalje o ovoj tehnici.
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 beloj listi, pružanje unapred registrovanog, napadačem kontrolisanog request_uri može olakšati SSRF tokom faze autorizacije.
Ako je platforma koju testirate OAuth provajder pročitajte ovo da biste testirali moguće Race Conditions.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
