Serbian - Ht
HackTricks Training Twitter Linkedin Sponsor

OAuth to Account takeover

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

LogoWebsec | Uw Cybersecurity Specialist

Osnovne informacije

OAuth nudi različite verzije, sa osnovnim informacijama dostupnim na OAuth 2.0 dokumentaciji. Ova diskusija se uglavnom fokusira na široko korišćeni OAuth 2.0 tip dozvole autorizacije, pružajući okvir za autorizaciju koji omogućava aplikaciji pristup ili izvršavanje radnji na korisničkom nalogu u drugoj aplikaciji (autorizacioni server).

Pretpostavimo hipotetički sajt https://primer.com, dizajniran da prikaže sve vaše postove na društvenim mrežama, uključujući privatne. Da bi se to postiglo, koristi se OAuth 2.0. https://primer.com će zatražiti vašu dozvolu da pristupi vašim postovima na društvenim mrežama. Kao rezultat toga, pojaviće se ekran saglasnosti na https://društvenamreža.com, koji opisuje dozvole koje se traže i razvojni programer koji traži dozvolu. Nakon vaše autorizacije, https://primer.com dobija mogućnost da pristupi vašim postovima 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, poput vaših postova na društvenim mrežama.

  • server resursa: Server koji upravlja autentifikovanim zahtevima nakon što je aplikacija obezbedila pristupni token u ime vlasnika resursa, npr. https://društvenamreža.com.

  • klijentska aplikacija: Aplikacija koja traži autorizaciju od vlasnika resursa, poput https://primer.com.

  • autorizacioni server: Server koji izdaje pristupne tokene klijentskoj aplikaciji nakon uspešne autentifikacije vlasnika resursa i obezbeđivanja autorizacije, npr. https://društvenamreža.com.

  • client_id: Javni, jedinstveni identifikator aplikacije.

  • client_secret: Poverljiv ključ, poznat samo aplikaciji i autorizacionom serveru, korišćen za generisanje pristupnih tokena.

  • response_type: Vrednost koja specificira tip tokena koji se zahteva, poput koda.

  • scope: Nivo pristupa koji klijentska aplikacija zahteva od vlasnika resursa.

  • redirect_uri: URL na koji se korisnik preusmerava nakon autorizacije. Ovo obično mora biti usklađeno sa unapred registrovanim URL-om za preusmeravanje.

  • state: Parametar za održavanje podataka tokom preusmeravanja korisnika ka i od autorizacionog servera. Njegova jedinstvenost je ključna za služenje kao mehanizam zaštite od CSRF-a.

  • grant_type: Parametar koji ukazuje tip dozvole i tip tokena koji će biti vraćen.

  • code: Kod autorizacije od autorizacionog servera, korišćen zajedno sa client_id i client_secret od strane klijentske aplikacije za dobijanje pristupnog tokena.

  • access_token: Token koji klijentska aplikacija koristi za API zahteve u ime vlasnika resursa.

  • refresh_token: Omogućava aplikaciji da dobije novi pristupni token bez ponovnog traženja od korisnika.

Tok

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

  1. Idete na https://primer.com i izaberete dugme "Integriši sa društvenim mrežama".

  2. Sajt zatim šalje zahtev na https://društvenamreža.com tražeći vašu autorizaciju da dozvolite aplikaciji https://primer.com pristup vašim postovima. Zahtev je struktuiran kao:

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

  1. Zatim vam se prikazuje stranica saglasnosti.

  2. Nakon vašeg odobrenja, društveni medijum šalje odgovor na redirect_uri sa parametrima code i state:

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

  1. https://example.com koristi ovaj code, zajedno sa svojim client_id i client_secret, kako bi napravio serverski zahtev za dobijanje access_token u vaše ime, omogućavajući pristup dozvolama koje ste odobrili:

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

  1. Na kraju, proces se završava kada https://example.com koristi vaš access_token da bi napravio API poziv ka društvenim medijima kako bi pristupio

Ranjivosti

Otvoreni redirect_uri

redirect_uri je ključan za sigurnost u OAuth i OpenID implementacijama, jer usmerava gde se šalju osetljivi podaci, poput autorizacionih kodova, nakon autorizacije. Ako nije ispravno konfigurisan, može omogućiti napadačima da preusmere ove zahteve ka zlonamernim serverima, omogućavajući preuzimanje naloga.

Tehnike eksploatacije variraju na osnovu logike validacije autorizacionog servera. Mogu se kretati od stroge provere putanje do prihvatanja bilo kog URL-a unutar određene domene ili poddirektorijuma. Česte metode eksploatacije uključuju otvorene redirekcije, prolazak kroz putanje, eksploataciju slabe regexe i HTML ubacivanje radi krađe tokena.

Pored redirect_uri, i drugi OAuth i OpenID parametri poput client_uri, policy_uri, tos_uri i initiate_login_uri su podložni napadima preusmeravanja. Ovi parametri su opcioni i podrška za njih varira među serverima.

Za one koji ciljaju OpenID server, endpoint otkrića (**.well-known/openid-configuration**) često navodi važne detalje konfiguracije poput registration_endpoint, request_uri_parameter_supported i "require_request_uri_registration. Ovi detalji mogu pomoći u identifikaciji endpointa za registraciju i drugih specifičnosti konfiguracije servera.

XSS u implementaciji redirekcije

Kako je navedeno u ovom izveštaju o nagradama za otkrivanje grešaka https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html moguće je da se URL redirekcije odražava u odgovoru servera nakon što 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 stanjem parametra

U implementacijama OAuth-a, zloupotreba ili izostavljanje 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 nije pravilno validiran, omogućavajući napadačima da zaobiđu zaštitu od CSRF napada.

Napadači mogu iskoristiti ovo presretanjem procesa autorizacije kako bi povezali svoj nalog sa žrtvinim nalogom, što može dovesti do potencijalnog preuzimanja naloga. Ovo je posebno kritično u aplikacijama gde se OAuth koristi u svrhe autentikacije.

Primeri ove ranjivosti su dokumentovani u različitim CTF izazovima i platformama za hakovanje, ističući njene praktične implikacije. Problem se takođe proširuje na integracije sa uslugama trećih strana poput 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 napada i obezbeđivanje sigurnosti OAuth protoka.

Pre Preuzimanja Naloga

  1. Bez Verifikacije Emaila Prilikom Kreiranja Naloga: Napadači mogu preventivno 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 prethodno kreiranim nalogom napadača, što dovodi do neovlašćenog pristupa.

  2. Iskorišćavanje Blage Verifikacije Emaila u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju emaile registracijom na njihovoj usluzi, a zatim promeniti email naloga u email žrtve. Ovaj metod takođe nosi rizik neovlašćenog pristupa nalogu, slično kao u prvom scenariju, ali kroz drugi vektor napada.

Otkrivanje Tajni

Identifikacija i zaštita tajnih OAuth parametara su ključni. 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_token-e i privatne informacije.

Česta ranjivost se javlja kada aplikacije greškom rukuju razmenom autorizacionog koda za access_token na strani klijenta umesto na serverskoj strani. Ova greška dovodi do izlaganja client_secret, omogućavajući napadačima da generišu access_token-e pod maskom aplikacije. Osim toga, kroz socijalno inženjerstvo, napadači bi mogli da eskaliraju privilegije dodavanjem dodatnih opsega autorizacije u OAuth autorizaciju, dalje iskorišćavajući poveren statusa aplikacije.

Bruteforce Tajnog Klijenta

Možete pokušati bruteforce-ovati tajni_klijent pružaoca usluge sa identitet 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 otkriva kod + stanje

Kada klijent dobije kod i stanje, ako je reflektovan unutar Referer zaglavlja prilikom prelaska na drugu stranicu, onda je ranjiv.

Pristupni token sačuvan u istoriji pretraživača

Idite na istoriju pretraživača i proverite da li je pristupni token sačuvan tamo.

Večni autorizacioni kod

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

Autorizacioni/Osvježavajući token nije vezan za klijenta

Ako možete dobiti autorizacioni kod i koristiti ga sa drugim klijentom, onda možete preuzeti kontrolu nad drugim nalozima.

Srećni putovi, XSS, Iframe-ovi & Post poruke za otkrivanje koda & vrednosti stanja

Proverite ovaj post

AWS Cognito

U ovom izveštaju o otkrivanju grešaka: 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 preuzeti 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 više detalja o tome kako zloupotrebiti AWS Cognito proverite:

LogoAWS - Cognito Unauthenticated EnumHackTricks Cloud

Zloupotreba tokena drugih aplikacija

Kao što je pomenuto u ovom tekstu, OAuth protoci 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 kreirati aplikaciju koja podržava OAuth i prijaviti se putem Facebook-a (na primer) u svojoj sopstvenoj aplikaciji. Zatim, kada se žrtva prijavi putem Facebook-a u napadačevu aplikaciju, napadač bi mogao dobiti OAuth token korisnika dat njegovoj aplikaciji i koristiti ga za prijavu u OAuth aplikaciju žrtve koristeći token korisnika žrtve.

Stoga, ako napadač uspe da natera korisnika da pristupi svojoj OAuth aplikaciji, biće u mogućnosti da preuzme kontrolu nad nalogom žrtve u aplikacijama koje očekuju token i ne proveravaju da li je token dodeljen njihovom app ID-u.

Dva linka & kolačić

Prema ovom tekstu, bilo je moguće naterati žrtvu da otvori stranicu sa returnUrl koja vodi ka napadačevom hostu. Ove informacije bi bile sačuvane u kolačiću (RU) i u kasnijem koraku prompt će pitati korisnika da li želi da dozvoli pristup tom napadačevom hostu.

Da bi se zaobišao ovaj prompt, bilo je moguće otvoriti karticu kako bi se pokrenuo Oauth protokol koji bi postavio ovaj RU kolačić koristeći returnUrl, zatvoriti karticu pre nego što se pokaže prompt, i otvoriti novu karticu bez te vrednosti. Tada, prompt neće obavestiti o napadačevom hostu, ali će kolačić biti postavljen na njega, tako da će token biti poslat napadačevom hostu u preusmeravanju.

Parametri SSRF-a

Proverite ovaj istraživački rad za dalje detalje o ovoj tehnici.

Dinamička registracija klijenata u OAuth-u služi kao manje očigledan, ali ključan vektor za ranjivosti bezbednosti, posebno za Server-Side Request Forgery (SSRF) napade. Ovaj endpoint omogućava OAuth serverima da primaju detalje o klijentskim aplikacijama, uključujući osetljive URL-ove koji bi mogli biti iskorišćeni.

Ključne tačke:

  • Dinamička registracija klijenata često je mapirana na /register i prihvata detalje poput client_name, client_secret, redirect_uris, i URL-ove za logoe ili JSON Web Key Sets (JWKs) putem POST zahteva.

  • Ova funkcionalnost 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-u na nekoliko načina:

  • logo_uri: URL za logo klijentske aplikacije koji može biti preuzet od strane servera, pokrećući SSRF ili dovodeći do XSS-a ako se URL nepravilno obradi.

  • jwks_uri: URL do JWK dokumenta klijenta, koji ako je zlonamerno oblikovan, može naterati server da vrši odlazne zahteve ka serveru pod kontrolom napadača.

  • sector_identifier_uri: Referenca na JSON niz redirect_uris, koje server može preuzeti, stvarajući priliku za SSRF.

  • request_uris: Navodi dozvoljene URI-je zahteva za klijenta, koje mogu biti iskorišćene ako server preuzme ove URI-je na početku procesa autorizacije.

Strategija eksploatacije:

  • SSRF može biti pokrenut registracijom novog klijenta sa zlonamernim URL-ovima u parametrima poput logo_uri, jwks_uri, ili sector_identifier_uri.

  • Iako direktna eksploatacija putem request_uris može biti umanjena kontrolama bele liste, obezbeđivanje prethodno registrovanog, napadačem kontrolisanog request_uri-ja može olakšati SSRF tokom faze autorizacije.

Trke uslova pružalaca OAuth-a

Ako je platforma koju testirate pružalac OAuth-a pročitajte ovo da biste testirali moguće trke uslova.

Reference

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

PreviousNoSQL injectionNextOpen Redirect

Last updated