Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md
Translator workflow 6c06826974 Translated to Serbian
2024-02-10 13:11:20 +00:00

18 KiB
Raw Blame History

OAuth za preuzimanje naloga

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

Drugi načini podrške HackTricks-u:

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 grant tip 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).

Razmotrimo hipotetički veb sajt https://example.com, dizajniran da prikaže sve vaše objave na društvenim mrežama, uključujući privatne. Da bi se to postiglo, 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, pojaviće se ekran za saglasnost na https://socialmedia.com, koji prikazuje dozvole koje se traže i razvojnog programera koji je podneo zahtev. Nakon vaše autorizacije, https://example.com dobija mogućnost da pristupa 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 društvenom mrežnom nalogu.
  • 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 tokene klijentskoj aplikaciji nakon uspešne autentifikacije vlasnika resursa i obezbeđivanja autorizacije, npr. https://socialmedia.com.
  • client_id: Javni, jedinstveni identifikator aplikacije.
  • client_secret: Poverljivi ključ, poznat samo aplikaciji i autorizacionom serveru, koji se koristi za generisanje access tokena.
  • response_type: Vrednost koja određuje tip traženog tokena, kao što je code.
  • scope: Nivo pristupa koji klijentska aplikacija traži od vlasnika resursa.
  • redirect_uri: URL na koji korisnik biva preusmeren nakon autorizacije. Ovo obično mora biti u skladu sa prethodno registrovanim preusmerenim URL-om.
  • state: Parametar za čuvanje podataka tokom preusmeravanja korisnika ka i od autorizacionog servera. Njegova jedinstvenost je ključna za služenje kao mehanizam zaštite od CSRF napada.
  • grant_type: Parametar koji ukazuje tip granta i tip tokena koji će biti vraćen.
  • code: Autorizacioni kod sa autorizacionog servera, koji se koristi zajedno sa client_id i client_secret od strane klijentske aplikacije za dobijanje access_tokena.
  • 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 dozvole od korisnika.

Tok

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

  1. Posetite https://example.com i izaberite dugme "Integriši sa društvenim mrežama".
  2. Sajt zatim šalje zahtev na https://socialmedia.com tražeći vašu autorizaciju da dozvoli aplikaciji https://example.com pristup 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

  1. Zatim vam se prikazuje stranica za davanje pristanka.

  2. Nakon što odobrite, društvena mreža š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, da bi napravio serverski zahtev za dobijanje access_token-a 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"}
  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 je konfigurisan na pogrešan način, 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. One mogu ići od stroge provere putanje do prihvatanja bilo koje URL adrese unutar određene domene ili poddirektorijuma. Uobičajene metode eksploatacije uključuju otvorene preusmere, pretragu putanja, iskorišćavanje slabih regularnih izraza i HTML ubacivanje radi krađe tokena.

Osim 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 otkrivanja (**.well-known/openid-configuration**) često sadrži vredne konfiguracione detalje 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 preusmeravanja

Kao što je pomenuto u ovom izveštaju o nagradi za otkrivanje grešaka https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, moguće je da se URL preusmeravanja reflektuje 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 parametrom stanja

U implementacijama OAuth-a, zloupotreba ili izostavljanje parametra stanja može značajno povećati rizik od napada Cross-Site Request Forgery (CSRF). Ova ranjivost se javlja kada se parametar state ili ne koristi, koristi kao statička vrednost ili nije pravilno validiran, što omogućava napadačima da zaobiđu CSRF zaštitu.

Napadači mogu iskoristiti ovo tako što presreću proces 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 svrhu autentifikacije.

Primeri ove ranjivosti su dokumentovani u raznim CTF izazovima i hakerskim platformama, što ističe njene praktične implikacije. Ovaj problem takođe se odnosi 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 parametra stanja su ključni za zaštitu od CSRF i obezbeđivanje sigurnosti OAuth protoka.

Preuzimanje naloga pre preuzimanja

  1. Bez provere 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 unapred kreiranim nalogom napadača, što dovodi do neovlašćenog pristupa.

  2. Iskorišćavanje slabih provjera e-pošte u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne proveravaju e-poštu tako što se registruju sa svojom uslugom, a zatim promene e-poštu naloga na žrtvinu. Ovaj metod takođe predstavlja rizik od neovlašćenog pristupa nalogu, slično kao i prvi scenario, 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čajan rizik. Ako client_secret bude kompromitovan, napadači mogu iskoristiti identitet i poverenje aplikacije kako bi ukrali korisničke access_tokens i privatne informacije.

Česta ranjivost se javlja kada aplikacije greškom rukuju razmenom autorizacijskog koda za access_token na strani klijenta umesto na strani servera. Ova greška dovodi do otkrivanja client_secret, omogućavajući napadačima da generišu access_token pod lažnim identitetom aplikacije. Osim toga, kroz socijalno inženjerstvo, napadači mogu povećati privilegije dodavanjem dodatnih opsega autorizacije OAuth-a, dalje iskorišćavajući poveren status aplikacije.

Brute force napad na tajni klijenta

Možete pokušati brute force napadom na tajnu klijenta pružatelja usluga sa identifikacionim pružateljem 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 se reflektuje unutar Referer zaglavlja kada prelazi 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 treba da živi samo određeno vreme kako bi se ograničio vremenski prozor 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 druge naloge.

Srećni putovi, XSS, Iframe i Post poruke za otkrivanje vrednosti koda i 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 za prebrisavanje korisničkih podataka. Stoga, ako možete promeniti e-poštu korisnika za drugu e-poštu korisnika, 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, pogledajte:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

Zloupotreba tokena drugih aplikacija

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

{% hint style="danger" %} Dakle, ako napadač uspe da navede korisnika da pristupi njegovoj sopstvenoj OAuth aplikaciji, on će moći preuzeti kontrolu nad žrtvinim nalogom u aplikacijama koje očekuju token i ne proveravaju da li je token dodeljen njihovom ID-u aplikacije. {% endhint %}

Dva linka i kolačić

Prema ovom članku, bilo je moguće naterati žrtvu da otvori stranicu sa returnUrl koji pokazuje na napadačevu host. Ove informacije bi bile sačuvane u kolačiću (RU), a u kasnijem koraku prompt će pitati korisnika da li želi da pruži pristup napadačevom hostu.

Da bi se zaobišao ovaj prompt, bilo je moguće otvoriti karticu kako bi se pokrenuo Oauth tok koji bi postavio ovaj RU kolačić koristeći returnUrl, zatvoriti karticu pre nego što se prikaž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 ovu istraživačku studiju za dalje detalje o ovoj tehnici.

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

Ključne tačke:

  • Dinamička registracija klijenta č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 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 URL nije pravilno obrađen.
  • jwks_uri: URL do JWK dokumenta klijenta, koji ako je zlonamerno oblikovan, može naterati server da izvrš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 mogućnost za SSRF.
  • request_uris: Navodi dozvoljene URI-je zahteva za klijenta, koje mogu biti iskorišćene ako server preuzima ove URI-je na početku procesa autorizacije.

Strategija iskorišćavanja:

  • SSRF se može pokrenuti registracijom novog klijenta sa zlonamernim URL-ovima u parametrima poput logo_uri, jwks_uri ili sector_identifier_uri.
  • Iako se direktno iskorišćavanje putem request_uris može umanjiti kontrolama bele liste, obezbeđivanje prethodno registrovanog, napadačem kontrolisanog request_uri može olakšati SSRF tokom faze autorizacije.

Trke uslova OAuth provajdera

Ako je platforma koju testirate OAuth provajder, 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 da podržite HackTricks: