Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

19 KiB
Raw Blame History

OAuth to Account takeover

Naučite AWS hakovanje od početnika do eksperta sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini da podržite HackTricks:

{% embed url="https://websec.nl/" %}

Osnovne Informacije

OAuth nudi različite verzije, sa osnovnim uvidima dostupnim na OAuth 2.0 dokumentaciji. Ova diskusija se prvenstveno fokusira na široko korišćeni OAuth 2.0 authorization code grant type, pružajući okvir za autorizaciju koji omogućava aplikaciji da pristupi ili izvrši radnje na korisničkom nalogu u drugoj aplikaciji (server za autorizaciju).

Razmotrite hipotetički sajt https://example.com, dizajniran da prikaže sve vaše objave na društvenim mrežama, uključujući privatne. Da bi to postigao, 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, navodeći 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 u okviru OAuth 2.0:

  • resource owner: Vi, kao korisnik/entitet, dajete dozvolu za pristup vašem resursu, kao što su vaše objave na društvenim mrežama.
  • resource server: Server koji upravlja autentifikovanim zahtevima nakon što aplikacija dobije 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 client application nakon uspešne autentifikacije resource owner i dobijanja autorizacije, npr. https://socialmedia.com.
  • client_id: Javni, jedinstveni identifikator za aplikaciju.
  • client_secret: Tajni ključ, poznat samo aplikaciji i serveru za autorizaciju, korišćen 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 od resource owner.
  • redirect_uri: URL na koji se korisnik preusmerava nakon autorizacije. Ovo obično mora da se poklapa sa unapred registrovanim URL-om za preusmeravanje.
  • state: Parametar za održavanje podataka tokom preusmeravanja korisnika na i sa servera za autorizaciju. Njegova jedinstvenost je ključna za služenje kao CSRF zaštitni mehanizam.
  • grant_type: Parametar koji označava tip granta i tip tokena koji će biti vraćen.
  • code: Autorizacioni kod sa authorization server, korišćen zajedno sa client_id i client_secret od strane client application za dobijanje access_token.
  • access_token: Token koji client application koristi za API zahteve u ime resource owner.
  • refresh_token: Omogućava aplikaciji da dobije novi access_token bez ponovnog traženja od korisnika.

Tok

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

  1. Vi posećujete https://example.com i birate dugme “Integrate with Social Media”.
  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
  1. Zatim vam se prikazuje stranica za saglasnost.
  2. Nakon vašeg odobrenja, Social Media šalje odgovor na redirect_uri sa code i state parametrima:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com koristi ovaj code, zajedno sa client_id i client_secret, da napravi server-side zahtev 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"}
  1. Konačno, proces se završava kada https://example.com koristi vaš access_token da napravi API poziv ka Social Media za pristup

Ranljivosti

Open redirect_uri

redirect_uri je ključan za sigurnost u OAuth i OpenID implementacijama, jer usmerava gde se šalju osetljivi podaci, kao što su autorizacioni kodovi, nakon autorizacije. Ako je pogrešno konfigurisan, može omogućiti napadačima da preusmere ove zahteve ka zlonamernim serverima, omogućavajući preuzimanje naloga.

Tehnike eksploatacije variraju u zavisnosti od logike validacije autorizacionog servera. Mogu se kretati od striktnih podudaranja putanja do prihvatanja bilo kog URL-a unutar specificiranog domena ili poddirektorijuma. Uobičajene metode eksploatacije uključuju otvorene preusmeravanja, putanje zaobilaska, eksploataciju 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, discovery endpoint (**.well-known/openid-configuration**) često navodi vredne detalje konfiguracije kao što su registration_endpoint, request_uri_parameter_supported i "require_request_uri_registration. Ovi detalji mogu pomoći u identifikaciji registration endpoint-a i drugih specifičnosti konfiguracije servera.

XSS u implementaciji preusmeravanja

Kao što je pomenuto u ovom bug bounty izveštaju https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html moguće je da se preusmeravanje URL-a reflektuje u odgovoru servera nakon što se korisnik autentifikuje, što je ranjivo 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 state parametrom

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

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

Primeri ove ranjivosti u stvarnom svetu dokumentovani su u raznim CTF izazovima i hakerskim platformama, ističući njene praktične implikacije. Problem se takođe proteže 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 pre kreiranja

  1. Bez verifikacije emaila 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 unapred kreiranim nalogom napadača, što dovodi do neovlašćenog pristupa.
  2. Iskorišćavanje slabe verifikacije emaila u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju emailove tako što će se registrovati sa svojom uslugom, a zatim promeniti email naloga na email žrtve. Ova metoda slična je prvoj situaciji, ali kroz drugačiji vektor napada.

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čajan rizik. 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 maskom aplikacije. Štaviše, kroz socijalni inženjering, napadači mogu eskalirati privilegije dodavanjem dodatnih opsega OAuth autorizaciji, dodatno eksploatišući poverenje aplikacije.

Bruteforce client secreta

Možete pokušati da bruteforce client_secret provajdera usluga 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 leaking Code + State

Kada klijent ima code i state, ako su reflektovani unutar Referer header-a kada pređe na drugu stranicu, onda je ranjiv.

Access Token Stored in Browser History

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

Everlasting Authorization Code

Authorization code treba da traje samo određeno vreme kako bi se ograničio vremenski prozor u kojem napadač može da ga ukrade i iskoristi.

Authorization/Refresh Token not bound to client

Ako možete dobiti authorization code i koristiti ga sa drugim klijentom, onda možete preuzeti druge naloge.

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

Pogledajte ovaj post

AWS Cognito

U ovom bug bounty izveštaju: 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. Dakle, ako možete promeniti korisnički email na 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 detaljnije informacije 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 proveravaju da li token pripada aplikaciji.

To je zato što napadač može kreirati aplikaciju koja podržava OAuth i prijaviti se sa Facebook-om (na primer) u svojoj aplikaciji. Zatim, kada se žrtva prijavi sa Facebook-om u napadačevoj aplikaciji, napadač može dobiti OAuth token korisnika dodeljen njegovoj aplikaciji i koristiti ga za prijavu u OAuth aplikaciju žrtve koristeći token korisnika žrtve.

{% hint style="danger" %} Dakle, ako napadač uspe da korisnik pristupi njegovoj OAuth aplikaciji, moći će da preuzme nalog žrtve 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čev host. Ova informacija bi bila sačuvana u kolačiću (RU) i 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 da se pokrene Oauth tok 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. Zatim, prompt neće informisati o napadačevom hostu, ali će kolačić biti postavljen na njega, tako da će token biti poslat na napadačev host u preusmeravanju.

Zaobilaženje interakcije sa promptom

Kao što je objašnjeno u ovom videu, neke OAuth implementacije omogućavaju da se navede prompt GET parametar kao None (&prompt=none) da spreče korisnike da budu pitani za potvrdu datog pristupa u promptu na webu ako su već prijavljeni na platformu.

response_mode

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

  • response_mode=query -> Kod je dostavljen unutar GET parametra: ?code=2397rf3gu93f
  • response_mode=fragment -> Kod je dostavljen unutar fragment parametra URL-a #code=2397rf3gu93f
  • response_mode=form_post -> Kod je dostavljen unutar POST forme sa inputom nazvanim code i vrednošću
  • response_mode=web_message -> Kod je poslat u post poruci: window.opener.postMessage({"code": "asdasdasd...

SSRF parametri

Pogledajte ovo istraživanje za dodatne 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. Ovaj endpoint omogućava OAuth serverima da prime detalje o klijentskim aplikacijama, uključujući osetljive URL-ove koji mogu biti zloupotrebljeni.

Ključne tačke:

  • Dinamička registracija klijenata je često mapirana 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 potencijalno ranjive na SSRF.
  • Proces registracije može nenamerno izložiti servere SSRF-u na nekoliko načina:
  • logo_uri: URL za logotip klijentske aplikacije koji server može preuzeti, pokrećući SSRF ili dovodeći do XSS ako se URL neadekvatno 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: Referiše se na JSON niz redirect_uris, koji server može preuzeti, stvarajući SSRF priliku.
  • request_uris: Navodi dozvoljene URI zahteve za klijenta, koji mogu biti zloupotrebljeni ako server preuzima ove URI-je na početku autorizacionog procesa.

Strategija eksploatacije:

  • SSRF može biti pokrenut 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 bele liste, snabdevanje unapred registrovanim, napadačem kontrolisanim request_uri može olakšati SSRF tokom faze autorizacije.

OAuth provajderi Uslovi trke

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

Reference

{% embed url="https://websec.nl/" %}

Naučite AWS hakovanje od početnika do eksperta sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini da podržite HackTricks: