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:
- As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat, kyk na die SUBSCRIPTION PLANS!
- Kry die amptelike PEASS & HackTricks swag
- Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
- Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
- Deel jou hacktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-repos.
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 diehulpbron-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 diekliënttoepassing
na die suksesvolle outentisering van diehulpbron-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 diehulpbron-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 metclient_id
enclient_secret
deur die kliënttoepassing gebruik word om 'ntoegangsteken
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:
- Jy navigeer na https://example.com en kies die "Integreer met Sosiale Media" knoppie.
- 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
-
Jy word dan voorgestel aan 'n toestemmingsbladsy.
-
Na jou goedkeuring stuur Sosiale Media 'n antwoord na die
redirect_uri
met diecode
enstate
parameters:
https://example.com?code=uniqueCode123&state=randomString123
- https://example.com maak gebruik van hierdie
code
, saam met syclient_id
enclient_secret
, om 'n serverkant versoek te maak om 'naccess_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"}
- 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
-
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.
-
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
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 soosclient_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 vanredirect_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
, ofsector_identifier_uri
te registreer. - Terwyl direkte uitbuiting via
request_uris
gematig kan word deur witlysbeheer, kan die voorsiening van 'n voorafgeregistreerde, aanvaller-beheerderequest_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
- https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
- https://portswigger.net/research/hidden-oauth-attack-vectors
Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!
Ander maniere om HackTricks te ondersteun:
- As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat, kyk na die SUBSCRIPTION PLANS!
- Kry die amptelike PEASS & HackTricks-uitrusting
- Ontdek The PEASS Family, ons versameling eksklusiewe NFT's
- Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
- Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.