OAuth to Account takeover
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Basic Information
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 imeresource 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
client application
nakon uspešne autentifikacijeresource 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
client application
traži odresource owner
.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 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 se koristi zajedno saclient_id
iclient_secret
od strane klijentske aplikacije za dobijanjeaccess_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.
Flow
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
sacode
istate
parametrima:
https://example.com koristi ovaj
code
, zajedno sa svojimclient_id
iclient_secret
, da izvrši zahtev sa servera kako bi dobioaccess_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
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 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.
XSS u implementaciji preusmeravanja
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:
CSRF - Nepravilno rukovanje parametrom stanja
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 za autentifikacione svrhe.
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
Bez verifikacije e-pošte prilikom kreiranja naloga: Napadači mogu unapred kreirati nalog koristeći e-poštu ž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 e-pošte u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju e-poštu tako što se registruju sa svojom uslugom, a zatim menjaju e-poštu naloga na onu ž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
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, kroz socijalno inženjerstvo, napadači bi mogli eskalirati privilegije dodavanjem dodatnih opsega u OAuth autorizaciju, dodatno iskorišćavajući povereni 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:
Referer Header leaking Code + State
Kada klijent ima code i state, ako je reflektovan unutar Referer header-a kada pretražuje drugu stranicu, onda je ranjiv.
Access Token Stored in Browser History
Idite na istoriju pretraživača 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
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.
For more detailed info about how to abuse AWS cognito check:
Abusing other Apps tokens
Kao što je spomenuto u ovom izveštaju, OAuth tokovi koji očekuju da prime token (a ne kod) mogu 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 iskoristi ga za prijavu u žrtvin OAuth aplikaciju koristeći žrtvin korisnički token.
Stoga, ako napadač uspe da dobije pristup korisniku svojoj OAuth aplikaciji, moći će da preuzme žrtvin nalog u aplikacijama koje očekuju token i ne provere da li je token dodeljen njihovom ID-u aplikacije.
Two links & cookie
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 redirekciji.
Prompt Interaction Bypass
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že biti moguće označiti parametar response_mode
da se naznači gde želite da kod bude dostavljen u finalnom URL-u:
response_mode=query
-> Kod se pruža unutar GET parametra:?code=2397rf3gu93f
response_mode=fragment
-> Kod se pruža unutar URL fragment parametra#code=2397rf3gu93f
response_mode=form_post
-> Kod se pruža unutar POST forme sa inputom nazvanimcode
i vrednošćuresponse_mode=web_message
-> Kod se šalje u post poruci:window.opener.postMessage({"code": "asdasdasd...
SSRFs parameters
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 iskorišćeni.
Ključne tačke:
Dinamička registracija klijenata se često mapira na
/register
i prihvata detalje kao što suclient_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 postavljenih 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 klijentovog JWK dokumenta, 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 nizredirect_uris
, koji server može preuzeti, stvarajući priliku za SSRF.request_uris
: Navodi dozvoljene URI zahteve za klijenta, koji se mogu iskoristiti 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
, ilisector_identifier_uri
.Dok direktna eksploatacija putem
request_uris
može biti ublažena kontrolama na beloj listi, pružanje unapred registrovanog, napadačem kontrolisanogrequest_uri
može olakšati SSRF tokom faze autorizacije.
OAuth providers Race Conditions
Ako je platforma koju testirate OAuth provajder pročitajte ovo da testirate moguće Race Conditions.
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated