hacktricks/pentesting-web/oauth-to-account-takeover.md
2024-02-11 02:07:06 +00:00

18 KiB

OAuth na Rekeningsoorname

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Basiese Inligting

OAuth bied verskeie weergawes aan, met fundamentele insigte beskikbaar by OAuth 2.0-dokumentasie. Hierdie bespreking fokus hoofsaaklik op die wyd gebruikte OAuth 2.0-autorisasiekode-toekenningsmetode, wat 'n outorisasieraamwerk bied wat 'n toepassing in staat stel om toegang te verkry tot of aksies uit te voer op 'n gebruiker se rekening in 'n ander toepassing (die outoriseringsbediener).

Beskou 'n hipotetiese webwerf https://example.com, ontwerp om al jou sosiale media plasings te vertoon, insluitend privaat plasings. Om dit te bereik, word OAuth 2.0 gebruik. https://example.com sal jou toestemming vra om toegang te verkry tot jou sosiale media plasings. Gevolglik sal 'n toestemmingskerm verskyn op https://socialmedia.com, waar die toestemmings wat versoek word en die ontwikkelaar wat die versoek maak, uiteengesit word. Nadat jy toestemming verleen het, verkry https://example.com die vermoë om namens jou toegang tot jou plasings te verkry.

Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0-raamwerk te verstaan:

  • hulpbron-eienaar: Jy, as die gebruiker/entiteit, gee toestemming vir toegang tot jou hulpbron, soos jou sosiale media-rekeningplasings.
  • hulpbronbediener: Die bediener wat geauthentiseerde versoek aanstuur nadat die toepassing 'n toegangsteken namens die hulpbron-eienaar verkry het, bv. https://socialmedia.com.
  • kliënttoepassing: Die toepassing wat outorisasie soek van die hulpbron-eienaar, soos https://example.com.
  • outoriseringsbediener: Die bediener wat toegangstekens uitreik aan die kliënttoepassing na die suksesvolle outentisering van die hulpbron-eienaar en die verkryging van outorisasie, bv. https://socialmedia.com.
  • client_id: 'n Openbare, unieke identifiseerder vir die toepassing.
  • client_secret: 'n Vertroulike sleutel, wat slegs bekend is aan die toepassing en die outoriseringsbediener, wat gebruik word om toegangstekens te genereer.
  • response_type: 'n Waarde wat die tipe teken wat versoek word, soos code, spesifiseer.
  • scope: Die vlak van toegang wat die kliënttoepassing versoek van die hulpbron-eienaar.
  • redirect_uri: Die URL waarna die gebruiker omgelei word na outorisasie. Dit moet tipies ooreenstem met die vooraf geregistreerde omleidings-URL.
  • state: 'n Parameter om data oor die gebruiker se omleiding na en van die outoriseringsbediener te behou. Sy uniekheid is krities vir die diens as 'n CSRF-beskermingsmeganisme.
  • grant_type: 'n Parameter wat die toekenningsmetode en die tipe teken wat teruggegee moet word aandui.
  • code: Die outorisasiekode van die outoriseringsbediener, wat saam met client_id en client_secret deur die kliënttoepassing gebruik word om 'n toegangsteken te verkry.
  • access_token: Die teken wat die kliënttoepassing gebruik vir API-versoeke namens die hulpbron-eienaar.
  • refresh_token: Stel die toepassing in staat om 'n nuwe toegangsteken te verkry sonder om die gebruiker weer te versoek.

Vloei

Die werklike OAuth-vloei verloop as volg:

  1. Jy navigeer na https://example.com en kies die "Integreer met Sosiale Media" knoppie.
  2. Die webwerf stuur dan 'n versoek na https://socialmedia.com om jou toestemming te vra om https://example.com se toepassing toegang tot jou plasings te gee. Die versoek is gestruktureer as:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Jy word dan voorgestel aan 'n toestemmingsbladsy.

  2. Na jou goedkeuring stuur Sosiale Media 'n antwoord na die redirect_uri met die code en state parameters:

https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com maak gebruik van hierdie code, saam met sy client_id en client_secret, om 'n serverkant versoek te maak om 'n access_token namens jou te verkry, wat toegang gee tot die toestemmings waarvoor jy ingestem het:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Uiteindelik sluit die proses af as https://example.com jou access_token gebruik om 'n API-oproep na Sosiale Media te maak om toegang te verkry.

Kwesbaarhede

Oop omleiding_uri

Die redirect_uri is van kritieke belang vir veiligheid in OAuth- en OpenID-implementering, aangesien dit aandui waar sensitiewe data, soos magtigingskodes, na magtiging gestuur word. As dit verkeerd gekonfigureer is, kan dit aanvallers in staat stel om hierdie versoek na kwaadwillige bedieners om te lei, wat rekeningsoorname moontlik maak.

Uitbuitingstegnieke wissel gebaseer op die valideringslogika van die magtigingbediener. Dit kan wissel van streng padvergelyking tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Algemene uitbuitingsmetodes sluit in oop omleidings, padtraversal, uitbuiting van swak regexes, en HTML-injeksie vir token-diefstal.

Afgesien van redirect_uri is ander OAuth- en OpenID-parameters soos client_uri, policy_uri, tos_uri, en initiate_login_uri ook vatbaar vir omleidingsaanvalle. Hierdie parameters is opsioneel en hul ondersteuning wissel tussen bedieners.

Vir diegene wat 'n OpenID-bedieners teiken, lys die ontdekkingspunt (**.well-known/openid-configuration**) dikwels waardevolle konfigurasiebesonderhede soos registration_endpoint, request_uri_parameter_supported, en "require_request_uri_registration. Hierdie besonderhede kan help om die registrasie-eindpunt en ander konfigurasiebesonderhede van die bediener te identifiseer.

XSS in omleiding-implementering

Soos genoem in hierdie foutjagverslag https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html is dit moontlik dat die omleiding URL weerspieël word in die respons van die bediener nadat die gebruiker geïdentifiseer is, en dus vatbaar vir XSS is. Moontlike lading om te toets:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Onvoldoende hantering van die state parameter

In OAuth-implementasies kan die misbruik of weglaat van die state parameter die risiko van Cross-Site Request Forgery (CSRF)-aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die state parameter óf nie gebruik word nie, as 'n statiese waarde gebruik word, óf nie behoorlik gevalideer word nie, wat aanvallers in staat stel om CSRF-beskerming te omseil.

Aanvallers kan hiervan gebruik maak deur die magtigingsproses te onderskep om hul rekening met 'n slagoffer se rekening te koppel, wat kan lei tot potensiële rekening-oorneemings. Dit is veral krities in toepassings waar OAuth vir verifikasiedoeleindes gebruik word.

Regte hantering en validering van die state parameter is noodsaaklik om teen CSRF te beskerm en die OAuth-vloei te beveilig.

Voor Rekening-oorneemings

  1. Sonder e-posverifikasie by rekening-skepping: Aanvallers kan voortydig 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derde party-diens vir inteken gebruik, kan die aansoek per ongeluk hierdie derde party-rekening aan die aanvaller se voorgeskepte rekening koppel, wat tot ongemagtigde toegang kan lei.

  2. Uitbuiting van lakse OAuth e-posverifikasie: Aanvallers kan OAuth-dienste wat nie e-posse verifieer nie, uitbuit deur met hul diens te registreer en dan die rekening se e-pos na die slagoffer se e-pos te verander. Hierdie metode stel soortgelyk risiko van ongemagtigde rekeningstoegang in, soos die eerste scenario, maar deur 'n ander aanvalsvektor.

Blootstelling van Geheime

Die identifisering en beskerming van geheime OAuth-parameters is noodsaaklik. Terwyl die client_id veilig bekend gemaak kan word, stel die bekendmaking van die client_secret beduidende risiko's in. As die client_secret gekompromitteer word, kan aanvallers die identiteit en vertroue van die aansoek uitbuit om gebruikers se access_tokens en privaat inligting te steel.

'n Algemene kwesbaarheid ontstaan wanneer aansoeke die uitruil van die magtigingskode vir 'n access_token aan die kliëntkant in plaas van die bedienerkant verwerk. Hierdie fout lei tot die blootstelling van die client_secret, wat aanvallers in staat stel om access_tokens onder die skyn van die aansoek te genereer. Verder kan aanvallers deur middel van sosiale manipulasie voorregte verhoog deur addisionele omvang aan die OAuth-magtiging toe te voeg, wat die vertroude status van die aansoek verder uitbuit.

Kliëntgeheim Bruteforce

Jy kan probeer om die kliëntgeheim van 'n diensverskaffer met die identiteitsverskaffer bruteforce om rekeninge te steel. Die versoek om te bruteforce kan soortgelyk lyk aan:

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-kop lekende Kode + State

Sodra die kliënt die kode en state het, as dit weerspieël word binne die Referer-kop wanneer hy na 'n ander bladsy blaai, is dit kwesbaar.

Toegangsteken gestoor in blaaiergeskiedenis

Gaan na die blaaiergeskiedenis en kyk of die toegangsteken daarin gestoor is.

Ewige Toestemmingskode

Die toestemmingskode moet net vir 'n rukkie leef om die tydvenster te beperk waarin 'n aanvaller dit kan steel en gebruik.

Toestemmings-/Vernuwingskode nie aan kliënt gekoppel nie

As jy die toestemmingskode kan kry en dit met 'n ander kliënt kan gebruik, kan jy ander rekeninge oorneem.

Gelukkige Paaie, XSS, Iframes & Post-boodskappe om kode- en state-waardes te lek

Kyk na hierdie pos

AWS Cognito

In hierdie foutjagverslag: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kan jy sien dat die teken wat AWS Cognito aan die gebruiker teruggee, dalk genoeg toestemmings het om die gebruikersdata te oorskryf. Daarom, as jy die gebruiker se e-pos kan verander na 'n ander gebruiker se e-pos, kan jy dalk ander rekeninge oorneem.

# 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"
}
]
}

Vir meer gedetailleerde inligting oor hoe om AWS Cognito te misbruik, kyk:

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

Misbruik van ander toepassings se tokens

Soos vermeld in hierdie verslag, kan OAuth-vloeiwyses wat verwag dat die token (en nie 'n kode) ontvang word, kwesbaar wees as hulle nie nagaan of die token aan die toepassing behoort nie.

Dit is omdat 'n aanvaller 'n toepassing kan skep wat OAuth ondersteun en met Facebook kan aanmeld (byvoorbeeld) in sy eie toepassing. Dan kan die aanvaller, nadat 'n slagoffer met Facebook in die aanvaller se toepassing aangemeld het, die OAuth-token van die gebruiker wat aan sy toepassing gegee is, bekom en dit gebruik om by die slagoffer se OAuth-toepassing in te teken met die slagoffer se gebruikerstoken.

{% hint style="danger" %} Daarom, as die aanvaller daarin slaag om die gebruiker toegang tot sy eie OAuth-toepassing te gee, sal hy in staat wees om die rekening van die slagoffer oor te neem in toepassings wat 'n token verwag en nie nagaan of die token aan hul app-ID toegeken is nie. {% endhint %}

Twee skakels & koekie

Volgens hierdie verslag was dit moontlik om 'n slagoffer 'n bladsy te laat oopmaak met 'n returnUrl wat na die aanvaller se gasheer verwys. Hierdie inligting sou in 'n koekie (RU) gestoor word en in 'n latere stap sal die prompt die gebruiker vra of hy toegang wil gee tot daardie aanvaller se gasheer.

Om hierdie prompt te omseil, was dit moontlik om 'n oortjie oop te maak om die Oauth-vloeiwys te begin wat hierdie RU-koekie met die returnUrl sou stel, die oortjie te sluit voordat die prompt gewys word, en 'n nuwe oortjie sonder daardie waarde oop te maak. Dan sal die prompt nie inligting oor die aanvaller se gasheer verskaf nie, maar die koekie sal daaraan gestel word, sodat die token na die aanvaller se gasheer gestuur sal word in die omleiding.

SSRF-parameters

Kyk na hierdie navorsing vir verdere besonderhede oor hierdie tegniek.

Dinamiese Kliëntregistrasie in OAuth dien as 'n minder voor die hand liggende maar kritieke vektor vir sekuriteitskwesbaarhede, spesifiek vir Server-Side Request Forgery (SSRF)-aanvalle. Hierdie eindpunt stel OAuth-bedieners in staat om besonderhede oor kliënttoepassings te ontvang, insluitend sensitiewe URL's wat uitgebuit kan word.

Kernpunte:

  • Dinamiese Kliëntregistrasie word dikwels gekarteer na /register en aanvaar besonderhede soos client_name, client_secret, redirect_uris, en URL's vir logo's of JSON Web Key Sets (JWK's) via POST-aanvrae.
  • Hierdie funksie voldoen aan spesifikasies wat uiteengesit is in RFC7591 en OpenID Connect Registration 1.0, wat parameters insluit wat potensieel vatbaar is vir SSRF.
  • Die registrasieproses kan servers onbedoeld blootstel aan SSRF op verskeie maniere:
  • logo_uri: 'n URL vir die logo van die kliënttoepassing wat deur die bediener opgehaal kan word, wat SSRF kan veroorsaak of tot XSS kan lei as die URL verkeerd hanteer word.
  • jwks_uri: 'n URL na die JWK-dokument van die kliënt, wat, as dit kwaadwillig saamgestel is, die bediener kan dwing om uitgaande aanvrae na 'n aanvaller-beheerde bediener te maak.
  • sector_identifier_uri: Verwys na 'n JSON-array van redirect_uris, wat die bediener moontlik kan ophaal en 'n SSRF-geleentheid skep.
  • request_uris: Lys toegelate aanvraag-URI's vir die kliënt, wat uitgebuit kan word as die bediener hierdie URI's aan die begin van die magtigingsproses ophaal.

Uitbuitingsstrategie:

  • SSRF kan geaktiveer word deur 'n nuwe kliënt met kwaadwillige URL's in parameters soos logo_uri, jwks_uri, of sector_identifier_uri te registreer.
  • Terwyl direkte uitbuiting via request_uris gematig kan word deur witlysbeheer, kan die voorsiening van 'n voorafgeregistreerde, aanvaller-beheerde request_uri SSRF fasiliteer gedurende die magtigingsfase.

OAuth-verskaffers Racevoorwaardes

As die platform wat jy toets 'n OAuth-verskaffer is, lees hierdie om te toets vir moontlike Racevoorwaardes.

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun: