OAuth to Account takeover
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
OAuth inatoa toleo mbalimbali, huku maarifa ya msingi yanapatikana katika OAuth 2.0 documentation. Majadiliano haya yanazingatia hasa OAuth 2.0 authorization code grant type, ikitoa mfumo waidhinishaji unaowezesha programu kufikia au kufanya vitendo kwenye akaunti ya mtumiaji katika programu nyingine (seva ya idhini).
Fikiria tovuti ya mfano https://example.com, iliyoundwa ili kuonyesha machapisho yako yote ya mitandao ya kijamii, ikiwa ni pamoja na ya faragha. Ili kufanikisha hili, OAuth 2.0 inatumika. https://example.com itahitaji ruhusa yako ili kufikia machapisho yako ya mitandao ya kijamii. Kwa hivyo, skrini ya idhini itaonekana kwenye https://socialmedia.com, ikielezea ruhusa zinazohitajika na mtengenezaji anayefanya ombi. Baada ya idhini yako, https://example.com inapata uwezo wa kufikia machapisho yako kwa niaba yako.
Ni muhimu kuelewa vipengele vifuatavyo ndani ya mfumo wa OAuth 2.0:
mwenye rasilimali: Wewe, kama mtumiaji/kitengo, unaruhusu ufikiaji wa rasilimali yako, kama vile machapisho ya akaunti yako ya mitandao ya kijamii.
seva ya rasilimali: seva inayosimamia maombi yaliyothibitishwa baada ya programu kupata access token kwa niaba ya mwenye rasilimali, mfano, https://socialmedia.com.
programu ya mteja: programu inayotafuta idhini kutoka kwa mwenye rasilimali, kama vile https://example.com.
seva ya idhini: seva inayotoa access tokens kwa programu ya mteja baada ya uthibitisho wa mafanikio wa mwenye rasilimali na kupata idhini, mfano, https://socialmedia.com.
client_id: Kitambulisho cha umma, cha kipekee kwa programu.
client_secret: Funguo ya siri, inayojulikana tu kwa programu na seva ya idhini, inayotumika kwa ajili ya kuzalisha access_tokens.
response_type: Thamani inayobainisha aina ya token inayohitajika, kama code.
scope: ngazi ya ufikiaji ambayo programu ya mteja inahitaji kutoka kwa mwenye rasilimali.
redirect_uri: URL ambayo mtumiaji anarejeshwa baada ya idhini. Hii kwa kawaida inapaswa kuendana na URL ya kuhamasisha iliyosajiliwa awali.
state: Kigezo cha kuhifadhi data wakati wa kuelekea na kurudi kwa mtumiaji kwenye seva ya idhini. Upekee wake ni muhimu kwa ajili ya kutumikia kama mekanismu ya ulinzi wa CSRF.
grant_type: Kigezo kinachoashiria aina ya grant na aina ya token itakayorejeshwa.
code: Kodu ya idhini kutoka kwa seva ya idhini, inayotumika pamoja na client_id na client_secret na programu ya mteja ili kupata access_token.
access_token: token ambayo programu ya mteja inatumia kwa maombi ya API kwa niaba ya mwenye rasilimali.
refresh_token: Inaruhusu programu kupata access_token mpya bila kumlazimisha mtumiaji tena.
mchakato halisi wa OAuth unafanyika kama ifuatavyo:
Unatembelea https://example.com na kuchagua kitufe cha “Integrate with Social Media”.
Tovuti hiyo kisha inatuma ombi kwa https://socialmedia.com ikitafuta idhini yako ili kuruhusu programu ya https://example.com kufikia machapisho yako. Ombi limeundwa kama:
Kisha unawasilishwa na ukurasa wa idhini.
Kufuatia idhini yako, Social Media inatuma jibu kwa redirect_uri na vigezo vya code na state:
https://example.com inatumia code hii, pamoja na client_id na client_secret yake, kufanya ombi la upande wa seva ili kupata access_token kwa niaba yako, ikiruhusu ufikiaji wa ruhusa ulizokubali:
Hatimaye, mchakato unamalizika wakati https://example.com inatumia access_token yako kufanya wito wa API kwa Mitandao ya Kijamii kupata
redirect_uri ni muhimu kwa usalama katika utekelezaji wa OAuth na OpenID, kwani inaelekeza mahali ambapo data nyeti, kama vile misimbo ya idhini, inatumwa baada ya idhini. Ikiwa imewekwa vibaya, inaweza kuruhusu washambuliaji kuelekeza maombi haya kwa seva mbaya, na kuwezesha kuchukuliwa kwa akaunti.
Mbinu za unyakuzi zinatofautiana kulingana na mantiki ya uthibitishaji ya seva ya idhini. Zinweza kutofautiana kutoka kwa mechi kali ya njia hadi kukubali URL yoyote ndani ya eneo lililotajwa au saraka ndogo. Mbinu za kawaida za unyakuzi ni pamoja na mwelekeo wazi, kupita njia, kutumia regex dhaifu, na kuingiza HTML kwa wizi wa token.
Mbali na redirect_uri, vigezo vingine vya OAuth na OpenID kama client_uri, policy_uri, tos_uri, na initiate_login_uri pia vinaweza kuathiriwa na mashambulizi ya kuelekeza. Vigezo hivi ni hiari na msaada wao unategemea seva.
Kwa wale wanaolenga seva ya OpenID, mwisho wa ugunduzi (**.well-known/openid-configuration**) mara nyingi huorodhesha maelezo muhimu ya usanidi kama registration_endpoint, request_uri_parameter_supported, na "require_request_uri_registration. Maelezo haya yanaweza kusaidia katika kubaini mwisho wa usajili na maelezo mengine ya usanidi wa seva.
Kama ilivyotajwa katika ripoti hii ya bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html inaweza kuwa inawezekana kwamba URL ya kuelekeza inajitokeza katika jibu la seva baada ya mtumiaji kuthibitisha, ikiwa vulnerable to XSS. Payload inay posible kujaribu:
Katika utekelezaji wa OAuth, matumizi mabaya au kukosekana kwa state parameter kunaweza kuongeza hatari ya mashambulizi ya Cross-Site Request Forgery (CSRF) kwa kiasi kikubwa. Uthibitisho huu unatokea wakati state parameter haijatumiwa, imetumiwa kama thamani ya kudumu, au haijathibitishwa ipasavyo, ikiruhusu washambuliaji kupita ulinzi wa CSRF.
Washambuliaji wanaweza kutumia hii kwa kukamata mchakato wa uthibitishaji ili kuunganisha akaunti yao na akaunti ya mwathirika, na kusababisha uwezekano wa kuchukua akaunti. Hii ni muhimu hasa katika programu ambapo OAuth inatumika kwa malengo ya uthibitishaji.
Mifano halisi ya udhaifu huu imeandikwa katika changamoto mbalimbali za CTF na majukwaa ya udukuzi, ikionyesha athari zake za vitendo. Tatizo hili pia linapanuka kwa ushirikiano na huduma za upande wa tatu kama Slack, Stripe, na PayPal, ambapo washambuliaji wanaweza kuelekeza arifa au malipo kwa akaunti zao.
Usimamizi na uthibitisho sahihi wa state parameter ni muhimu kwa kulinda dhidi ya CSRF na kuhakikisha mchakato wa OAuth unakuwa salama.
Bila Uthibitisho wa Barua Pepe kwenye Uundaji wa Akaunti: Washambuliaji wanaweza kuunda akaunti kabla kwa kutumia barua pepe ya mwathirika. Ikiwa mwathirika baadaye anatumia huduma ya upande wa tatu kuingia, programu inaweza bila kukusudia kuunganisha akaunti hii ya upande wa tatu na akaunti iliyoundwa na mshambuliaji, na kusababisha ufikiaji usioidhinishwa.
Kutatua Uthibitisho wa Barua Pepe wa OAuth: Washambuliaji wanaweza kutumia huduma za OAuth ambazo hazithibitishi barua pepe kwa kujiandikisha na huduma yao na kisha kubadilisha barua pepe ya akaunti kuwa ya mwathirika. Njia hii pia ina hatari ya ufikiaji usioidhinishwa wa akaunti, sawa na hali ya kwanza lakini kupitia njia tofauti ya shambulio.
Kutambua na kulinda vigezo vya siri vya OAuth ni muhimu. Ingawa client_id inaweza kufichuliwa kwa usalama, kufichua client_secret kuna hatari kubwa. Ikiwa client_secret itakabiliwa, washambuliaji wanaweza kutumia utambulisho na imani ya programu ili kuiba access_tokens za mtumiaji na taarifa binafsi.
Udhaifu wa kawaida unatokea wakati programu zinashughulikia kwa makosa kubadilishana code ya uthibitisho kwa access_token upande wa mteja badala ya upande wa seva. Makosa haya yanapelekea kufichuliwa kwa client_secret, ikiruhusu washambuliaji kuunda access_tokens chini ya kivuli cha programu. Zaidi ya hayo, kupitia uhandisi wa kijamii, washambuliaji wanaweza kuongeza mamlaka kwa kuongeza maeneo mengine kwenye uthibitisho wa OAuth, wakitumia zaidi hadhi ya kuaminika ya programu.
Unaweza kujaribu kuvunjia siri ya client_secret ya mtoa huduma na mtoa kitambulisho ili kujaribu kuiba akaunti. Ombi la BF linaweza kuonekana kama:
Mara tu mteja ana code na state, ikiwa inatolewa ndani ya Referer header anapovinjari kwenye ukurasa tofauti, basi iko hatarini.
Nenda kwenye historia ya kivinjari na angalia kama access token imehifadhiwa humo.
Authorization code inapaswa kuishi kwa muda fulani tu ili kupunguza dirisha la muda ambapo mshambuliaji anaweza kuiba na kuitumia.
Ikiwa unaweza kupata authorization code na kuifanya na mteja tofauti basi unaweza kuchukua akaunti nyingine.
Katika ripoti hii ya bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ unaweza kuona kwamba token ambayo AWS Cognito inamrudishia mtumiaji inaweza kuwa na idhini za kutosha kubadilisha data za mtumiaji. Hivyo, ikiwa unaweza kubadilisha barua pepe ya mtumiaji kwa barua pepe tofauti ya mtumiaji, unaweza kuwa na uwezo wa kuchukua akaunti za wengine.
For more detailed info about how to abuse AWS cognito check:
Kama ilivyotajwa katika andiko hili, mchakato wa OAuth unaotarajia kupokea token (na si nambari) unaweza kuwa na hatari ikiwa hauhakiki kwamba token inamhusu programu hiyo.
Hii ni kwa sababu mshambuliaji anaweza kuunda programu inayounga mkono OAuth na kuingia kwa Facebook (kwa mfano) katika programu yake mwenyewe. Kisha, mara tu mwathirika anapoingia kwa Facebook katika programu ya mshambuliaji, mshambuliaji anaweza kupata OAuth token ya mtumiaji aliyepewa programu yake, na kuitumia kuingia katika programu ya OAuth ya mwathirika kwa kutumia token ya mtumiaji wa mwathirika.
Hivyo, ikiwa mshambuliaji atafanikiwa kumfanya mtumiaji aingie katika programu yake ya OAuth, atakuwa na uwezo wa kuchukua akaunti ya mwathirika katika programu zinazotarajia token na hazikaguzi kama token ilitolewa kwa ID ya programu yao.
Kulingana na andiko hili, ilikuwa inawezekana kumfanya mwathirika afungue ukurasa wenye returnUrl unaoelekeza kwenye mwenyeji wa mshambuliaji. Taarifa hii ingekuwa imehifadhiwa katika cookie (RU) na katika hatua ya baadaye prompt itakuwa inauliza mtumiaji kama anataka kutoa ufikiaji kwa mwenyeji wa mshambuliaji.
Ili kupita prompt hii, ilikuwa inawezekana kufungua tab ili kuanzisha Oauth flow ambayo ingeiweka cookie hii ya RU kwa kutumia returnUrl, kufunga tab kabla ya prompt kuonyeshwa, na kufungua tab mpya bila thamani hiyo. Kisha, prompt haitatoa taarifa kuhusu mwenyeji wa mshambuliaji, lakini cookie itakuwa imewekwa kwake, hivyo token itatumwa kwa mwenyeji wa mshambuliaji katika uelekezaji.
Kama ilivyoelezwa katika video hii, baadhi ya utekelezaji wa OAuth huruhusu kuashiria prompt GET parameter kama None (&prompt=none) ili kuzuia watumiaji kuulizwa kuthibitisha ufikiaji uliopewa katika prompt kwenye wavuti ikiwa tayari wameingia kwenye jukwaa.
Kama ilivyoelezwa katika video hii, inaweza kuwa inawezekana kuashiria parameter response_mode kuashiria unataka nambari ipi itolewe katika URL ya mwisho:
response_mode=query -> Nambari inatolewa ndani ya parameter ya GET: ?code=2397rf3gu93f
response_mode=fragment -> Nambari inatolewa ndani ya parameter ya URL fragment #code=2397rf3gu93f
response_mode=form_post -> Nambari inatolewa ndani ya fomu ya POST yenye input inayoitwa code na thamani
response_mode=web_message -> Nambari inatumwa katika ujumbe wa posta: window.opener.postMessage({"code": "asdasdasd...
Kulingana na andiko hili, huu ni mchakato wa OAuth unaoruhusu kuingia katika OAuth kupitia jina la mtumiaji na nenosiri. Ikiwa wakati wa mchakato huu rahisi token yenye ufikiaji wa vitendo vyote ambavyo mtumiaji anaweza kufanya inarudishwa basi inawezekana kupita 2FA kwa kutumia token hiyo.
Hii blogpost inaelezea jinsi ilivyowezekana kutumia open redirect kwa thamani kutoka kwa referrer ili kutumia OAuth kwa ATO. Shambulio lilikuwa:
Mwathirika anafikia ukurasa wa wavuti wa mshambuliaji
Mwathirika anafungua kiungo kibaya na opener inaanzisha mchakato wa Google OAuth na response_type=id_token,code&prompt=none kama vigezo vya ziada kwa kutumia kama referrer tovuti ya mshambuliaji.
Katika opener, baada ya mtoa huduma kumruhusu mwathirika, inawapelekea nyuma kwa thamani ya parameter ya redirect_uri (wavuti ya mwathirika) kwa nambari ya 30X ambayo bado inashikilia tovuti ya mshambuliaji katika referer.
Tovuti ya mwathirika inasababisha open redirect kulingana na referrer ikielekeza mtumiaji wa mwathirika kwenye tovuti ya mshambuliaji, kwani respose_type ilikuwa id_token,code, nambari itatumwa nyuma kwa mshambuliaji katika fragment ya URL ikimruhusu kuchukua akaunti ya mtumiaji kupitia Google katika tovuti ya mwathirika.
Angalia utafiti huu Kwa maelezo zaidi ya mbinu hii.
Usajili wa Wateja wa Kijivu katika OAuth unatumika kama njia isiyo wazi lakini muhimu kwa udhaifu wa usalama, haswa kwa mashambulizi ya Server-Side Request Forgery (SSRF). Endpoint hii inaruhusu seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URLs nyeti ambazo zinaweza kutumika vibaya.
Mambo Muhimu:
Usajili wa Wateja wa Kijivu mara nyingi unahusishwa na /register na unakubali maelezo kama client_name, client_secret, redirect_uris, na URLs za alama au JSON Web Key Sets (JWKs) kupitia maombi ya POST.
Kipengele hiki kinazingatia vipimo vilivyowekwa katika RFC7591 na OpenID Connect Registration 1.0, ambavyo vinajumuisha vigezo ambavyo vinaweza kuwa na hatari kwa SSRF.
Mchakato wa usajili unaweza kwa bahati mbaya kufichua seva kwa SSRF kwa njia kadhaa:
logo_uri: URL ya alama ya programu ya mteja ambayo inaweza kupatikana na seva, ikisababisha SSRF au kupelekea XSS ikiwa URL itashughulikiwa vibaya.
jwks_uri: URL ya hati ya JWK ya mteja, ambayo ikiwa imeundwa kwa njia mbaya, inaweza kusababisha seva kufanya maombi ya nje kwa seva inayodhibitiwa na mshambuliaji.
sector_identifier_uri: Inarejelea orodha ya JSON ya redirect_uris, ambayo seva inaweza kupakua, ikisababisha fursa ya SSRF.
request_uris: Inataja URIs za maombi zinazoruhusiwa kwa mteja, ambazo zinaweza kutumika vibaya ikiwa seva itazipakua mwanzoni mwa mchakato waidhinishaji.
Mkakati wa Kutumia:
SSRF inaweza kuanzishwa kwa kujiandikisha mteja mpya na URLs mbaya katika vigezo kama logo_uri, jwks_uri, au sector_identifier_uri.
Ingawa matumizi ya moja kwa moja kupitia request_uris yanaweza kupunguziliwa mbali na udhibiti wa orodha ya ruhusa, kutoa request_uri iliyosajiliwa awali, inayodhibitiwa na mshambuliaji kunaweza kuwezesha SSRF wakati wa hatua ya uthibitishaji.
Ikiwa jukwaa unalojaribu ni mtoa huduma wa OAuth soma hii ili kujaribu uwezekano wa Race Conditions.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
