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

18 KiB
Raw Blame History

OAuth hadi Uchukuzi wa Akaunti

Jifunze AWS hacking kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks:

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

Taarifa Msingi

OAuth inatoa toleo mbalimbali, na ufahamu wa msingi unapatikana kwenye hati ya OAuth 2.0. Mjadala huu unazingatia kwa kiasi kikubwa aina ya idhini ya nambari ya uthibitishaji ya OAuth 2.0, ikitoa mtaala wa idhini unaowezesha programu kupata au kutekeleza vitendo kwenye akaunti ya mtumiaji kwenye programu nyingine (seva ya idhini).

Fikiria tovuti ya dhana https://mfano.com, iliyoundwa kuonyesha machapisho yako ya mitandao ya kijamii, pamoja na yale ya faragha. Ili kufanikisha hili, OAuth 2.0 inatumika. https://mfano.com itaomba idhini yako ku kupata machapisho yako ya mitandao ya kijamii. Kwa hivyo, skrini ya idhini itaonekana kwenye https://mitandaojamii.com, ikielezea idhini inayotakiwa na mwandishi wa ombi. Baada ya idhini yako, https://mfano.com inapata uwezo wa kupata machapisho yako kwa niaba yako.

Ni muhimu kuelewa vipengele vifuatavyo ndani ya mfumo wa OAuth 2.0:

  • mmiliki wa rasilimali: Wewe, kama mtumiaji/kitu, unaidhinisha upatikanaji wa rasilimali yako, kama machapisho ya akaunti yako ya mitandao ya kijamii.
  • seva ya rasilimali: Seva inayosimamia maombi yaliyothibitishwa baada ya programu kupata access token kwa niaba ya mmiliki wa rasilimali, k.m., https://mitandaojamii.com.
  • programu ya mteja: Programu inayotafuta idhini kutoka kwa mmiliki wa rasilimali, kama vile https://mfano.com.
  • seva ya idhini: Seva inayotoa access token kwa programu ya mteja baada ya uthibitishaji mafanikio wa mmiliki wa rasilimali na kupata idhini, k.m., https://mitandaojamii.com.
  • client_id: Kitambulisho cha umma, cha kipekee kwa programu.
  • client_secret: Neno la siri, linalojulikana tu kwa programu na seva ya idhini, hutumiwa kuzalisha access_tokens.
  • response_type: Thamani inayoeleza aina ya token inayotakiwa, kama code.
  • scope: Kiwango cha upatikanaji ambacho programu ya mteja inaomba kutoka kwa mmiliki wa rasilimali.
  • redirect_uri: URL ambayo mtumiaji anaelekezwa baada ya idhini. Kawaida hii lazima ifanane na URL ya kuhamisha iliyosajiliwa mapema.
  • state: Parameta ya kuhifadhi data wakati wa kuhamisha mtumiaji kwenye na kutoka kwa seva ya idhini. Upekee wake ni muhimu kama muhimili wa ulinzi wa CSRF.
  • grant_type: Parameta inayoonyesha aina ya idhini na aina ya token itakayorudishwa.
  • code: Nambari ya idhini kutoka kwa seva ya idhini, inayotumiwa pamoja na client_id na client_secret na programu ya mteja kupata access_token.
  • access_token: Token ambao programu ya mteja hutumia kwa maombi ya API kwa niaba ya mmiliki wa rasilimali.
  • refresh_token: Inawezesha programu kupata access_token mpya bila kumwuliza tena mtumiaji.

Mzunguko

Mzunguko halisi wa OAuth unafuata hatua zifuatazo:

  1. Nenda kwenye https://mfano.com na chagua kitufe cha "Integrate with Social Media".
  2. Tovuti hiyo kisha itatuma ombi kwa https://mitandaojamii.com kuomba idhini yako kuruhusu programu ya https://mfano.com kupata machapisho yako. Ombi hilo limeundwa kama:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

  1. Kisha utaletewa ukurasa wa idhini.

  2. Baada ya idhini yako, Mitandao ya Kijamii inatuma jibu kwa redirect_uri na vigezo vya code na state:

https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com inatumia hii code, pamoja na client_id na client_secret yake, kufanya ombi upande wa server kupata access_token kwa niaba yako, kuruhusu ufikiaji wa ruhusa ulizoidhinisha:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Hatimaye, mchakato unamalizika kama https://example.com inatumia access_token yako kufanya wito wa API kwa Mitandao ya Kijamii ili kupata

Mapungufu

Uelekezaji wazi_uri

redirect_uri ni muhimu kwa usalama katika utekelezaji wa OAuth na OpenID, kwani inaelekeza wapi data nyeti, kama nambari za idhini, zinatumwa baada ya idhini. Ikiwa imepangiliwa vibaya, inaweza kuruhusu wachawi kuuelekeza maombi haya kwa seva zenye nia mbaya, kuruhusu utekaji wa akaunti.

Mbinu za kutumia zinatofautiana kulingana na mantiki ya uthibitishaji wa seva ya idhini. Wanaweza kutofautiana kutoka kwa kulinganisha njia kwa umakini hadi kukubali URL yoyote ndani ya kikoa au folda iliyotajwa. Mbinu za kawaida za kutumia ni pamoja na uelekezaji wazi, upitishaji wa njia, kutumia regex dhaifu, na kuingiza HTML kwa wizi wa alama.

Mbali na redirect_uri, vigezo vingine vya OAuth na OpenID kama client_uri, policy_uri, tos_uri, na initiate_login_uri pia wanaweza kuwa katika hatari ya mashambulizi ya uelekezaji. Vigezo hivi sio lazima na msaada wao hutofautiana kati ya seva.

Kwa wale wanaolenga seva ya OpenID, kipengele cha ugunduzi (**.well-known/openid-configuration**) mara nyingi hupata maelezo muhimu ya usanidi kama vile registration_endpoint, request_uri_parameter_supported, na "require_request_uri_registration. Maelezo haya yanaweza kusaidia katika kutambua mwisho wa usajili na maelezo mengine ya usanidi wa seva.

XSS katika utekelezaji wa uelekezaji

Kama ilivyotajwa katika ripoti hii ya tuzo ya mdudu https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html inaweza kuwa inawezekana kwamba URL ya uelekezaji inaonyeshwa katika majibu ya seva baada ya mtumiaji kujithibitisha, ikiwa inavuliwa kwa XSS. Payload inayowezekana kwa majaribio:

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

CSRF - Kukosea kushughulikia parameter ya hali

Katika utekelezaji wa OAuth, matumizi mabaya au kutokuwepo kwa parameter ya state inaweza kuongeza hatari kubwa ya mashambulizi ya Cross-Site Request Forgery (CSRF). Udhaifu huu unatokea wakati parameter ya state inatumika kwa njia isiyo sahihi, kutumika kama thamani ya msingi, au kutokuwa na uthibitisho sahihi, kuruhusu wachomaji kukiuka ulinzi wa CSRF.

Wachomaji wanaweza kutumia hili kwa kuingilia mchakato wa idhini ili kuunganisha akaunti yao na akaunti ya muathiriwa, ikisababisha uchukuzi wa akaunti. Hii ni muhimu sana katika programu ambapo OAuth inatumika kwa madhumuni ya uthibitisho.

Mifano halisi ya udhaifu huu imerekodiwa katika changamoto mbalimbali za CTF na majukwaa ya udukuzi, ikionyesha athari zake za vitendo. Tatizo hili pia linahusiana na uingizaji wa huduma za tatu kama Slack, Stripe, na PayPal, ambapo wachomaji wanaweza kuelekeza arifa au malipo kwa akaunti zao.

Kushughulikia na kuthibitisha parameter ya state kwa usahihi ni muhimu kwa kulinda dhidi ya CSRF na kusimamia mchakato wa OAuth.

Kabla ya Uchukuzi wa Akaunti

  1. Bila Uthibitishaji wa Barua pepe Wakati wa Uundaji wa Akaunti: Wachomaji wanaweza kuunda akaunti mapema kwa kutumia barua pepe ya muathiriwa. Ikiwa muathiriwa baadaye anatumia huduma ya tatu kwa kuingia, programu inaweza kwa bahati mbaya kuunganisha akaunti hii ya tatu ya muathiriwa na akaunti iliyoundwa mapema ya mchomaji, ikisababisha ufikiaji usioidhinishwa.

  2. Kutumia Uthibitishaji wa Barua pepe wa Lax OAuth: Wachomaji wanaweza kutumia huduma za OAuth ambazo hazithibitishi barua pepe kwa kusajili na huduma yao na kisha kubadilisha barua pepe ya akaunti kuwa ya muathiriwa. Mbinu hii ina hatari sawa ya ufikiaji usioidhinishwa wa akaunti, kama kwenye kisa cha kwanza lakini kupitia vector tofauti wa shambulizi.

Kufichua Siri

Kutambua na kulinda paramita za siri za OAuth ni muhimu. Ingawa client_id inaweza kufichuliwa salama, kufunua client_secret kunaweza kuleta hatari kubwa. Ikiwa client_secret itafichuliwa, wachomaji wanaweza kutumia kitambulisho na imani ya programu kuiba access_tokens za watumiaji na habari za kibinafsi.

Udhaifu wa kawaida unatokea wakati programu zinashughulikia kwa makosa kubadilishana ya code ya idhini kwa access_token upande wa mteja badala ya upande wa seva. Kosa hili husababisha kufichuliwa kwa client_secret, kuruhusu wachomaji kuzalisha access_tokens chini ya kivuli cha programu. Zaidi ya hayo, kupitia uhandisi wa kijamii, wachomaji wanaweza kuongeza mamlaka kwa kuongeza mizunguko zaidi kwa idhini ya OAuth, kuchimba zaidi hadhi ya kuaminika ya programu.

Kuvunja Neno la Siri la Mteja

Unaweza kujaribu kuvunja neno la siri la mteja wa mtoa huduma na mtoa huduma wa kitambulisho ili kujaribu kuiba akaunti.
Ombi la BF linaweza kuonekana kama:

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]

Kichwa cha Referer kuvuja Msimbo + Hali

Mara tu mteja anapopata msimbo na hali, ikiwa inajitokeza ndani ya kichwa cha Referer anapobofya ukurasa tofauti, basi ni hatarishi.

Funguo la Kufikia lililohifadhiwa katika Historia ya Kivinjari

Nenda kwenye historia ya kivinjari na angalia ikiwa funguo la kufikia limehifadhiwa hapo.

Msimbo wa Kibali wa Milele

Msimbo wa kibali unapaswa kuishi kwa muda fulani tu ili kupunguza dirisha la muda ambapo mshambuliaji anaweza kuiba na kutumia.

Msimbo wa Kibali/Msimbo wa Kufufua usiofungwa kwa mteja

Ikiwa unaweza kupata msimbo wa kibali na kutumia na mteja tofauti basi unaweza kuchukua akaunti za wengine.

Njia za Furaha, XSS, Iframes & Ujumbe wa Post kuvuja msimbo & hali

Angalia chapisho hili

AWS Cognito

Katika ripoti ya tuzo ya mdudu huyu: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ unaweza kuona kwamba funguo ambao AWS Cognito inampa mtumiaji huenda ukawa na idhini za kutosha za kubadilisha data ya mtumiaji. Kwa hivyo, ikiwa unaweza kubadilisha barua pepe ya mtumiaji kwa barua pepe ya mtumiaji tofauti, unaweza kuchukua akaunti za wengine.

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

Kudanganya Vyeti vya Programu Nyingine

Kama ilivyotajwa katika makala hii, Mifumo ya OAuth ambayo inatarajia kupokea tokeni (na sio nambari) inaweza kuwa hatarini ikiwa haitathibitisha kuwa tokeni inamilikiwa na programu.

Hii ni kwa sababu mshambuliaji anaweza kuunda programu inayounga mkono OAuth na kuingia kwa kutumia Facebook (kwa mfano) katika programu yake mwenyewe. Kisha, mara tu muathiriwa anapojiingia kwa kutumia Facebook katika programu ya mshambuliaji, mshambuliaji anaweza kupata tokeni ya OAuth ya mtumiaji iliyotolewa kwa programu yake, na kuitumia kuingia katika programu ya OAuth ya muathiriwa kwa kutumia tokeni ya mtumiaji wa muathiriwa.

{% hint style="danger" %} Hivyo, ikiwa mshambuliaji anafanikiwa kupata mtumiaji kumruhusu kutumia programu yake ya OAuth, ataweza kuchukua akaunti ya muathiriwa katika programu ambazo zinatarajia tokeni na hazithibitishi ikiwa tokeni ilitolewa kwa kitambulisho cha programu yao. {% endhint %}

Viungo viwili & kuki

Kulingana na makala hii, ilikuwa inawezekana kumfanya muathiriwa afungue ukurasa na returnUrl inayoashiria kwenye mwenyeji wa mshambuliaji. Taarifa hii ingehifadhiwa katika kuki (RU) na katika hatua inayofuata prompt itamuuliza mtumiaji ikiwa anataka kutoa ruhusa kwa mwenyeji huyo wa mshambuliaji.

Ili kuepuka prompt hii, ilikuwa inawezekana kufungua kichupo kuanzisha mtiririko wa Oauth ambao ungehifadhi kuki hii ya RU kwa kutumia returnUrl, kufunga kichupo kabla ya prompt kuonyeshwa, na kufungua kichupo kipya bila thamani hiyo. Kisha, prompt haitaonyesha kuhusu mwenyeji wa mshambuliaji, lakini kuki itahifadhiwa kwake, hivyo tokeni itatumwa kwa mwenyeji wa mshambuliaji katika uendeshaji.

Vigezo vya SSRFs

Angalia utafiti huu kwa maelezo zaidi kuhusu mbinu hii.

Usajili wa Mteja wa Kudumu katika OAuth unatumika kama vectori isiyo wazi lakini muhimu kwa mapungufu ya usalama, hasa kwa mashambulizi ya Server-Side Request Forgery (SSRF). Kipengele hiki huruhusu seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URL nyeti ambazo zinaweza kutumiwa vibaya.

Muhimu:

  • Usajili wa Mteja wa Kudumu mara nyingi unahusishwa na /register na hukubali maelezo kama vile client_name, client_secret, redirect_uris, na URLs za vielelezo au Seti za Muhimu za Wavuti za JSON (JWKs) kupitia maombi ya POST.
  • Kipengele hiki kinazingatia maelekezo yaliyowekwa katika RFC7591 na Usajili wa OpenID Connect 1.0, ambayo ni pamoja na vigezo vinavyoweza kuwa hatarini kwa SSRF.
  • Mchakato wa usajili unaweza kwa bahati mbaya kuweka wazi seva kwa SSRF kwa njia kadhaa:
  • logo_uri: URL kwa vielelezo vya programu ya mteja ambayo inaweza kupakuliwa na seva, ikichochea SSRF au kusababisha XSS ikiwa URL itashughulikiwa vibaya.
  • jwks_uri: URL kwa hati ya JWK ya mteja, ambayo ikipangwa kwa udanganyifu, inaweza kusababisha seva kufanya maombi ya kutoka kwenda kwa seva inayodhibitiwa na mshambuliaji.
  • sector_identifier_uri: Inahusisha safu ya JSON ya redirect_uris, ambayo seva inaweza kupakua, ikiumba fursa ya SSRF.
  • request_uris: Inaorodhesha URI zilizoruhusiwa za ombi kwa mteja, ambazo zinaweza kutumiwa vibaya ikiwa seva itapakua URI hizi mwanzoni mwa mchakato wa idhini.

Stratejia ya Utekaji:

  • SSRF inaweza kuanzishwa kwa kusajili mteja mpya na URL zenye nia mbaya katika vigezo kama logo_uri, jwks_uri, au sector_identifier_uri.
  • Ingawa utekelezaji wa moja kwa moja kupitia request_uris unaweza kupunguzwa na udhibiti wa orodha nyeupe, kutoa request_uri iliyosajiliwa mapema, inayodhibitiwa na mshambuliaji, inaweza kurahisisha SSRF wakati wa hatua ya idhini.

Masharti ya Mashindano ya Watoa Huduma wa OAuth

Ikiwa jukwaa unalolipima ni mtoa huduma wa OAuth soma hii ili kujaribu Mashindano ya Watoa Huduma.

Marejeo

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

Jifunze kuhusu udukuzi wa AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks: