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 na Rekeningoorneming

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

Ander maniere om HackTricks te ondersteun:

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

Basiese Inligting

OAuth bied verskeie weergawes, met fundamentele insigte beskikbaar by OAuth 2.0-dokumentasie. Hierdie bespreking fokus hoofsaaklik op die wyd gebruikte OAuth 2.0-oorspronklike toestemmingstipe, wat 'n toestemmingsraamwerk bied wat 'n aansoek in staat stel om toegang te verkry tot of aksies uit te voer op 'n gebruiker se rekening in 'n ander aansoek (die toestemmingsdiens).

Beskou 'n hipotetiese webwerf https://voorbeeld.com, ontwerp om al jou sosiale media plasings ten toon te stel, insluitend privaat een. Om dit te bereik, word OAuth 2.0 gebruik. https://voorbeeld.com sal jou toestemming vra om toegang tot jou sosiale media plasings te verkry. Gevolglik sal 'n toestemmingskerm op https://sosialemedia.com verskyn wat die toestemmings wat versoek word en die ontwikkelaar wat die versoek maak uiteensit. Na jou toestemming kry https://voorbeeld.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 stuur nadat die aansoek 'n toegangstoken namens die hulpbron-eienaar verkry het, bv. https://sosialemedia.com.
  • kliëntaansoek: Die aansoek wat toestemming soek van die hulpbron-eienaar, soos https://voorbeeld.com.
  • toestemmingsdiens: Die bediener wat toegangstokens uitreik aan die kliëntaansoek na die suksesvolle outentifisering van die hulpbron-eienaar en die verkryging van toestemming, bv. https://sosialemedia.com.
  • kliënt_id: 'n Openbare, unieke identifiseerder vir die aansoek.
  • kliëntgeheim: 'n vertroulike sleutel, slegs bekend aan die aansoek en die toestemmingsdiens, wat gebruik word vir die genereer van toegangstokens.
  • response_type: 'n waarde wat die tipe token wat versoek word, spesifiseer, soos code.
  • scope: Die vlak van toegang wat die kliëntaansoek van die hulpbron-eienaar versoek.
  • redirect_uri: Die URL waarna die gebruiker na toestemming omgelei word. Dit moet tipies ooreenstem met die vooraf geregistreerde omleidings-URL.
  • state: 'n parameter om data oor die gebruiker se omleiding na en van die toestemmingsdiens te behou. Sy uniekheid is krities vir die diens as 'n CSRF-beskermingsmeganisme.
  • grant_type: 'n parameter wat die toestemmingstipe en die tipe token wat teruggegee moet word, aandui.
  • code: Die toestemmingskode van die toestemmingsdiens, wat saam met kliënt_id en kliëntgeheim deur die kliëntaansoek gebruik word om 'n toegangstoken te bekom.
  • toegangstoken: Die token wat die kliëntaansoek gebruik vir API-versoeke namens die hulpbron-eienaar.
  • ververs_token: Maak dit vir die aansoek moontlik om 'n nuwe toegangstoken te verkry sonder om die gebruiker weer te versoek.

Vloei

Die werklike OAuth-vloei verloop soos volg:

  1. Jy navigeer na https://voorbeeld.com en kies die "Integreer met Sosiale Media" knoppie.
  2. Die webwerf stuur dan 'n versoek na https://sosialemedia.com om jou toestemming te vra om https://voorbeeld.com se aansoek 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 voorgehou met 'n toestemmingsbladsy.

  2. Na jou goedkeuring stuur die sosiale media 'n reaksie 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 wat 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. Laastens, die proses sluit af as https://example.com jou access_token gebruik om 'n API-oproep aan sosiale media te maak om toegang te verkry

Swakhede

Oop omleidings_uri

Die redirect_uri is noodsaaklik vir sekuriteit in OAuth en OpenID-implementasies, aangesien dit aandui waar sensetiewe data, soos magtigingskodes, na magtiging gestuur word. Indien verkeerd gekonfigureer, kan dit aanvallers moontlik maak om hierdie versoek na skadelike bedieners om te lei, wat rekening-oorneem moontlik maak.

Uitbuitingstegnieke wissel gebaseer op die valideringslogika van die magtigingbediener. Dit kan wissel van streng pad-passing tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Gewone uitbuitingsmetodes sluit oop omleidings, padtraversering, die uitbuiting van swak regexe, en HTML-inspuiting vir token-diefstal in.

Benewens 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-bediener teiken, lys die ontdekkings-eindpunt (**.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 konfigurasiespesifieke van die bediener te identifiseer.

XSS in omleidingsimplementasie

Soos genoem in hierdie foutvindingsverslag https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html is dit moontlik dat die omleidings-URL in die respons van die bediener na die gebruiker se verifikasie weerspieël word, wat 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 - Onvanige hantering van die staat 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, of nie behoorlik gevalideer word nie, wat aanvallers in staat stel om CSRF-beskerming te omseil.

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

Regte-wêreld voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie CTF-uitdagings en hakplatforms, wat die praktiese implikasies daarvan beklemtoon. Die probleem strek ook tot integrasies met derdeparty dienste soos Slack, Stripe, en PayPal, waar aanvallers kennisgewings of betalings na hul rekeninge kan omskakel.

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

Voor Rekening-oorneemings

  1. Sonner E-posverifikasie by Rekening Skepping: Aanvallers kan voortydig 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdepartydiens vir aanmelding gebruik, kan die aansoek per ongeluk hierdie derdeparty-rekening aan die aanvaller se voorgeskepte rekening koppel, wat tot ongemagtigde toegang kan lei.

  2. Uitbuiting van Laks OAuth E-posverifikasie: Aanvallers kan OAuth-dienste uitbuit wat nie e-posse verifieer deur met hul diens te registreer en dan die rekening se e-pos na die slagoffer se e-pos te verander. Hierdie metode loop soortgelyk risiko van ongemagtigde rekeningtoegang, soortgelyk aan die eerste scenario, maar deur 'n ander aanvalvektor.

Bekendmaking van Geheime

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

'n Algemene kwesbaarheid ontstaan wanneer aansoeke die uitruil van die magtigings code vir 'n access_token aan die kliëntkant hanteer in plaas van die bedienerkant. 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 sosiale manipulasie voorregte eskaleer deur addisionele omvang aan die OAuth-magtiging toe te voeg, wat die vertroude status van die aansoek verder uitbuit.

Kliënt Geheim Bruteforce

Jy kan probeer om die kliënt_geheim bruteforce van 'n diensverskaffer met die identiteitsverskaffer te wees om rekeninge te steel.
Die versoek vir BF 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 Header lek Code + State

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

Toegangsteken gestoor in Blaaigeskiedenis

Gaan na die blaaigeskiedenis en kyk of die toegangsteken daar gestoor is.

Ewige Magtigingskode

Die magtigingskode behoort net vir 'n rukkie te leef om die tydvenster te beperk waar 'n aanvaller dit kan steel en gebruik.

Magtigings/Vernuwings Teken nie aan klient gebind nie

As jy die magtigingskode kan kry en dit met 'n ander klient kan gebruik, kan jy ander rekeninge oorneem.

Gelukkige Paaie, XSS, Iframes & Posboodskappe om kode & staat waardes te lek

Kyk na hierdie pos

AWS Cognito

In hierdie foutvindingsverslag: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kan jy sien dat die teken wat AWS Cognito aan die gebruiker teruggee, dalk genoeg regte het om die gebruikersdata te oorskryf. Daarom, as jy die gebruiker se e-pos vir 'n ander gebruiker se e-pos kan verander, 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 Apps se tokens

Soos vermeld in hierdie uiteensetting, kan OAuth-vloeiwyses wat verwag om die token (en nie 'n kode) te ontvang, kwesbaar wees as hulle nie nagaan of die token aan die program behoort nie.

Dit is omdat 'n aanvaller 'n toepassing wat OAuth ondersteun en met Facebook inlog (byvoorbeeld) in sy eie toepassing kan skep. Dan, sodra 'n slagoffer met Facebook in die aanvaller se toepassing inlog, kan die aanvaller die OAuth-token van die gebruiker wat aan sy toepassing gegee is, kry en dit gebruik om in te log in die slagoffer se OAuth-toepassing deur die slagoffer se gebruikerstoken.

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

Twee skakels & koekie

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

Om hierdie prompt te omseil, was dit moontlik om 'n lus te open om die Oauth-vloei te begin wat hierdie RU-koekie met die returnUrl sou instel, die lus te sluit voordat die prompt vertoon word, en 'n nuwe lus sonder daardie waarde te open. Dan sal die prompt nie oor die aanvaller se gasheer inlig 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 sekuriteitskwessies, spesifiek vir Server-Side Request Forgery (SSRF)-aanvalle. Hierdie eindpunt laat OAuth-bedieners toe 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 (JWKs) via POST-versoeke.
  • Hierdie kenmerk 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 bedieners onbedoeld blootstel aan SSRF op verskeie maniere:
  • logo_uri: 'n URL vir die kliënttoepassing se logo 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 kliënt se JWK-dokument, wat indien booswillig saamgestel, die bediener kan dwing om uitgaande versoeke na 'n aanvallerbeheerde bediener te maak.
  • sector_identifier_uri: Verwys na 'n JSON-reeks van redirect_uris, wat die bediener kan ophaal, wat 'n SSRF-geleentheid kan skep.
  • request_uris: Lys toegelate versoek-URL's vir die kliënt, wat uitgebuit kan word as die bediener hierdie URL's aan die begin van die magtigingsproses ophaal.

Uitbuitingsstrategie:

  • SSRF kan geaktiveer word deur 'n nuwe kliënt met booswillige 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, aanvallerbeheerde request_uri SSRF tydens die magtigingsfase fasiliteer.

OAuth-aanbieders Race Voorwaardes

As die platform wat jy toets 'n OAuth-aanbieder is, lees hierdie om te toets vir moontlike Race Voorwaardes.

Verwysings

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

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

Ander maniere om HackTricks te ondersteun: