# OAuth hadi Kuchukua Udhibiti wa Akaunti
Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)! Njia nyingine za kusaidia HackTricks: * Ikiwa unataka kuona **kampuni yako inatangazwa kwenye HackTricks** au **kupakua HackTricks kwa muundo wa PDF** Angalia [**MPANGO WA KUJIUNGA**](https://github.com/sponsors/carlospolop)! * Pata [**swag rasmi ya PEASS & HackTricks**](https://peass.creator-spring.com) * Gundua [**The PEASS Family**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) ya kipekee * **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au [**kikundi cha telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Shiriki mbinu zako za kudukua kwa kuwasilisha PR kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
## Taarifa Msingi OAuth inatoa toleo mbalimbali, na ufahamu wa msingi unapatikana kwenye [hati ya OAuth 2.0](https://oauth.net/2/). Majadiliano haya yanazingatia sana [aina ya idhini ya nambari ya utoaji wa OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), ambayo hutoa **mfumo wa idhini unaoruhusu programu kupata au kutekeleza hatua kwenye akaunti ya mtumiaji kwenye programu nyingine** (seva ya idhini). Fikiria tovuti ya kufikirika _**https://example.com**_, iliyoundwa kuonyesha **machapisho yako ya media ya kijamii**, pamoja na yale ya faragha. Ili kufanikisha hili, OAuth 2.0 hutumiwa. _https://example.com_ itaomba idhini yako ya **kupata machapisho yako ya media ya kijamii**. Kwa hiyo, skrini ya idhini itaonekana kwenye _https://socialmedia.com_, ikielezea **idhini inayotakiwa na msanidi programu anayefanya ombi**. Baada ya idhini yako, _https://example.com_ inapata uwezo wa **kupata machapisho yako kwa niaba yako**. Ni muhimu kuelewa sehemu zifuatazo ndani ya mfumo wa OAuth 2.0: - **mmiliki wa rasilimali**: Wewe, kama **mtumiaji/kifaa**, unaidhinisha upatikanaji wa rasilimali yako, kama vile machapisho ya akaunti yako ya media ya kijamii. - **seva ya rasilimali**: **Seva inayosimamia maombi yaliyothibitishwa** baada ya programu kupata `access token` kwa niaba ya `mmiliki wa rasilimali`, kwa mfano, **https://socialmedia.com**. - **programu ya mteja**: **Programu inayotafuta idhini** kutoka kwa `mmiliki wa rasilimali`, kama vile **https://example.com**. - **seva ya idhini**: **Seva inayotoa `access token`** kwa `programu ya mteja` baada ya kuthibitisha kwa mafanikio `mmiliki wa rasilimali` na kupata idhini, kwa mfano, **https://socialmedia.com**. - **client\_id**: Kitambulisho cha umma na cha kipekee kwa programu. - **client\_secret:** Neno la siri la siri, linalojulikana tu kwa programu na seva ya idhini, linalotumiwa kuzalisha `access_token`. - **response\_type**: Thamani inayoelezea **aina ya token inayohitajika**, kama vile `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 kuongoza iliyosajiliwa mapema. - **state**: Parameta ya **kudumisha data wakati mtumiaji anaelekezwa na kurudi kutoka kwa seva ya idhini**. Unyenyekevu 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 ambayo programu ya mteja hutumia kwa maombi ya API** kwa niaba ya `mmiliki wa rasilimali`. - **refresh\_token**: Inawezesha programu kupata **access_token mpya bila kumwomba tena mtumiaji**. ### Mchakato **Mchakato halisi wa OAuth** unafuata hatua zifuatazo: 1. Nenda kwenye [https://example.com](https://example.com) na chagua kifungo "Integrate with Social Media". 2. Tovuti hiyo kisha itatuma ombi kwa [https://socialmedia.com](https://socialmedia.com) kuomba idhini yako kuruhusu programu ya https://example.com kupata machapisho yako. Ombi linajengwa kama ifuatavyo: ``` https://socialmedia.com/auth ?response_type=code &client_id=example_clientId &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback &scope=readPosts &state=randomString123 ``` 3. Kisha utapewa ukurasa wa idhini. 4. Baada ya idhini yako, Mtandao wa Kijamii utatuma jibu kwa `redirect_uri` na vigezo vya `code` na `state`: ``` https://example.com?code=uniqueCode123&state=randomString123 ``` 5. https://example.com hutumia `code` hii, pamoja na `client_id` na `client_secret` yake, kufanya ombi la upande wa seva ili kupata `access_token` kwa niaba yako, kuruhusu ufikiaji wa ruhusa ulizokubali: ``` POST /oauth/access_token Host: socialmedia.com ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ``` 6. Hatimaye, mchakato unakamilika kwa https://example.com kutumia `access_token` yako kufanya wito wa API kwa Mitandao ya Kijamii ili kupata ufikiaji. ## Mianya ### Open redirect\_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 imepangwa vibaya, inaweza kuruhusu wadukuzi kupelekeza maombi haya kwa seva mbaya, kuruhusu kuchukua udhibiti wa akaunti. Teknolojia za kudukua hutofautiana kulingana na mantiki ya ukaguzi wa seva ya idhini. Zinaweza kutofautiana kutoka kwa kulinganisha njia kwa kukubali URL yoyote ndani ya kikoa au kwenye saraka iliyotajwa. Njia za kawaida za kudukua ni pamoja na kupelekeza wazi, kuvuka njia, kudukua 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 ni rahisi kudukuliwa kwa mashambulizi ya kupelekeza. Vigezo hivi ni hiari na msaada wao hutofautiana kati ya seva. Kwa wale wanaolenga seva ya OpenID, kipengele cha ugunduzi (`**.well-known/openid-configuration**`) mara nyingi hutoa maelezo muhimu ya usanidi kama vile `registration_endpoint`, `request_uri_parameter_supported`, na "`require_request_uri_registration`. Maelezo haya yanaweza kusaidia katika kutambua kipengele cha usajili na maelezo mengine ya usanidi wa seva. ### XSS katika utekelezaji wa kupelekeza Kama ilivyotajwa katika ripoti hii ya zawadi ya mdudu [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) inaweza kuwa inawezekana kuwa **URL ya kupelekeza inaonyeshwa katika jibu** la seva baada ya mtumiaji kuthibitisha, ikiwa **inavuja kwa XSS**. Payload inayowezekana kujaribu: ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - Kukosa kushughulikia kwa usahihi kipengele cha hali Katika utekelezaji wa OAuth, matumizi mabaya au kutotumia kipengele cha **`hali`** kinaweza kuongeza hatari kubwa ya mashambulizi ya **Cross-Site Request Forgery (CSRF)**. Udhaifu huu unatokea wakati kipengele cha `hali` kinapotumiwa **kwa njia isiyofaa, kutumiwa kama thamani ya tuli, au kutokushughulikiwa kwa usahihi**, kuruhusu wadukuzi kukiuka ulinzi wa CSRF. Wadukuzi wanaweza kutumia hili kwa kuvuruga mchakato wa idhini ili kuunganisha akaunti yao na akaunti ya muathirika, hivyo kusababisha **uchukuzi wa akaunti**. Hii ni hatari hasa katika programu ambapo OAuth hutumiwa kwa **madhumuni ya uwakilishi**. Mifano halisi ya udhaifu huu imeandikwa katika changamoto mbalimbali za **CTF** na **jukwaa za udukuzi**, ikionyesha athari zake za vitendo. Tatizo hili pia linahusisha ujumuishaji na huduma za tatu kama vile **Slack**, **Stripe**, na **PayPal**, ambapo wadukuzi wanaweza kuhamisha arifa au malipo kwenye akaunti zao. Kushughulikia na kuthibitisha kwa usahihi kipengele cha **`hali`** ni muhimu kwa kulinda dhidi ya CSRF na kusimamia mchakato wa OAuth. ### Kabla ya Uchukuzi wa Akaunti 1. **Bila Uthibitisho wa Barua pepe Wakati wa Kuunda Akaunti**: Wadukuzi wanaweza kuunda akaunti mapema kwa kutumia barua pepe ya muathirika. Ikiwa muathirika baadaye anatumia huduma ya tatu kwa kuingia, programu inaweza kwa bahati mbaya kuunganisha akaunti hii ya tatu na akaunti iliyoundwa mapema na muhalifu, hivyo kusababisha ufikiaji usiohalali. 2. **Kudukua Uthibitisho Mdogo wa Barua pepe wa OAuth**: Wadukuzi wanaweza kutumia huduma za OAuth ambazo hazithibitishi barua pepe kwa kujisajili na huduma hiyo na kisha kubadilisha barua pepe ya akaunti kuwa ya muathirika. Njia hii ina hatari sawa ya ufikiaji usiohalali wa akaunti, kama ilivyo kwa kisa cha kwanza lakini kupitia njia tofauti ya shambulio. ### Kufichua Siri Kutambua na kulinda vigezo vya siri vya OAuth ni muhimu. Ingawa **`client_id`** inaweza kufichuliwa salama, kufichua **`client_secret`** kunasababisha hatari kubwa. Ikiwa `client_secret` inaingiliwa, wadukuzi wanaweza kutumia utambulisho na imani ya programu kuiba **`access_tokens`** za watumiaji na habari za kibinafsi. Udhaifu wa kawaida unatokea wakati programu inashughulikia ubadilishaji wa `code` ya idhini kwa `access_token` upande wa mteja badala ya upande wa seva. Kosa hili husababisha kufichuliwa kwa `client_secret`, kuruhusu wadukuzi kuzalisha `access_tokens` kwa udanganyifu wa programu. Zaidi ya hayo, kupitia uhandisi wa kijamii, wadukuzi wanaweza kuongeza mamlaka kwa kuongeza wigo zaidi kwa idhini ya OAuth, hivyo kudhoofisha hadhi ya programu. ### Kuvunja Nguvu ya Siri ya Mteja Unaweza kujaribu **kuvunja nguvu ya siri ya mteja** wa mtoa huduma na mtoa huduma wa kitambulisho ili kujaribu kuiba akaunti.\ Ombi la kuvunja nguvu linaweza kuonekana kama ifuatavyo: ``` 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 habari cha Referer kinachovuja Kanuni + Hali Mara tu mteja anapopata **kanuni na hali**, ikiwa ina **reflected ndani ya kichwa cha habari cha Referer** wakati anapata ukurasa tofauti, basi ina udhaifu. ### Kitufe cha Kufikia Kimehifadhiwa kwenye Historia ya Kivinjari Nenda kwenye **historia ya kivinjari na angalia ikiwa kitufe cha kufikia kimehifadhiwa hapo**. ### Kanuni ya Idhini Isiyokoma **Kanuni ya idhini inapaswa kuishi kwa muda fulani ili kupunguza dirisha la wakati ambapo mshambuliaji anaweza kuiba na kuitumia**. ### Kitufe cha Idhini / Kiboreshaji kisichounganishwa na mteja Ikiwa unaweza kupata **kanuni ya idhini na kuitumia na mteja tofauti basi unaweza kuchukua udhibiti wa akaunti nyingine**. ### Njia za Furaha, XSS, Iframes & Ujumbe wa Post kuvuja kanuni & hali **[Angalia chapisho hili](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)** ### AWS Cognito Katika ripoti hii ya tuzo ya mdudu: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) unaweza kuona kuwa **kitufe** ambacho **AWS Cognito** inarudisha kwa mtumiaji kinaweza kuwa na **mamlaka ya kutosha ya kuandika tena data ya mtumiaji**. Kwa hivyo, ikiwa unaweza **kubadilisha barua pepe ya mtumiaji kwa barua pepe tofauti ya mtumiaji**, huenda uka **chukua udhibiti** wa akaunti za wengine. ```bash # 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" } ] } ``` Kwa habari zaidi kuhusu jinsi ya kutumia AWS Cognito angalia: {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %} ### Kutumia vibaya vitufe vya programu nyingine Kama [**ilivyotajwa katika nakala hii**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), mifumo ya OAuth ambayo inatarajia kupokea **kitufe** (na sio nambari) inaweza kuwa na udhaifu ikiwa haitathibitishi kwamba kitufe kinamilikiwa 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 baada ya muathirika kuingia kwa kutumia Facebook katika **programu ya mshambuliaji**, mshambuliaji anaweza kupata **kitufe cha OAuth cha mtumiaji kilichotolewa kwa programu yake, na kukitumia kuingia katika programu ya OAuth ya muathirika kwa kutumia kitufe cha mtumiaji cha muathirika**. {% hint style="danger" %} Kwa hiyo, ikiwa mshambuliaji anafanikiwa kupata mtumiaji kufikia programu yake ya OAuth, ataweza kuchukua udhibiti wa akaunti ya muathirika katika programu ambazo zinatarajia kitufe na hazithibitishi ikiwa kitufe kilipewa ID yao ya programu. {% endhint %} ### Viungo viwili na kuki Kulingana na [**nakala hii**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), ilikuwa inawezekana kufanya muathirika afungue ukurasa na **returnUrl** inayoelekeza kwenye mwenyeji wa mshambuliaji. Habari hii ingehifadhiwa katika kuki (RU) na katika hatua ya baadaye, **kielekezi** kitauliza **mtumiaji** ikiwa anataka kutoa ufikiaji kwa mwenyeji huyo wa mshambuliaji. Ili kuepuka kielekezi hiki, ilikuwa inawezekana kufungua kichupo ili kuanzisha **mtiririko wa OAuth** ambao ungehifadhi kuki hii ya RU kwa kutumia **returnUrl**, kufunga kichupo kabla ya kielekezi kuonyeshwa, na kufungua kichupo kipya bila thamani hiyo. Kwa hiyo, **kielekezi hakitatoa habari kuhusu mwenyeji wa mshambuliaji**, lakini kuki itakuwa imewekwa kwake, hivyo **kitufe kitatumwa kwa mwenyeji wa mshambuliaji** katika uhamishaji. ### Parameta za SSRF **[Angalia utafiti huu](https://portswigger.net/research/hidden-oauth-attack-vectors) kwa maelezo zaidi kuhusu mbinu hii.** Usajili wa Mteja wa Kudumu katika OAuth unatumika kama njia isiyoeleweka lakini muhimu kwa udhaifu wa usalama, hasa kwa mashambulizi ya **Server-Side Request Forgery (SSRF)**. Kipengele hiki kinawezesha seva za OAuth kupokea maelezo kuhusu programu za wateja, ikiwa ni pamoja na URL nyeti ambazo zinaweza kudukuliwa. **Mambo muhimu:** - Usajili wa Mteja wa Kudumu mara nyingi unahusishwa na `/register` na unakubali maelezo kama vile `client_name`, `client_secret`, `redirect_uris`, na URL kwa ajili ya nembo au JSON Web Key Sets (JWKs) kupitia maombi ya POST. - Kipengele hiki kinazingatia maelekezo yaliyowekwa katika **RFC7591** na **OpenID Connect Registration 1.0**, ambayo ni pamoja na parameta ambazo zinaweza kuwa na udhaifu wa SSRF. - Mchakato wa usajili unaweza kusababisha seva kuwa wazi kwa SSRF kwa njia kadhaa: - **`logo_uri`**: URL kwa nembo ya programu ya mteja ambayo inaweza kupatikana na seva, ikisababisha SSRF au kusababisha XSS ikiwa URL haikushughulikiwa vizuri. - **`jwks_uri`**: URL kwa hati ya JWK ya mteja, ambayo ikiwa imeundwa kwa nia mbaya, inaweza kusababisha seva kufanya maombi ya kutoka kwa seva inayodhibitiwa na mshambuliaji. - **`sector_identifier_uri`**: Inahusisha orodha ya JSON ya `redirect_uris`, ambayo seva inaweza kupata, ikiumba fursa ya SSRF. - **`request_uris`**: Inaorodhesha URI za maombi zilizoruhusiwa kwa mteja, ambazo zinaweza kudukuliwa ikiwa seva inapata URI hizi mwanzoni mwa mchakato wa idhini. **Mbinu ya Udukuzi:** - SSRF inaweza kusababishwa kwa kusajili mteja mpya na URL mbaya katika parameta kama vile `logo_uri`, `jwks_uri`, au `sector_identifier_uri`. - Ingawa udukuzi wa moja kwa moja kupitia `request_uris` unaweza kudhibitiwa na udhibiti wa orodha nyeupe, kutoa `request_uri` iliyosajiliwa mapema na inayodhibitiwa na mshambuliaji kunaweza kurahisisha SSRF wakati wa hatua ya idhini. ## Masharti ya OAuth ya Masharti ya Mashindano Ikiwa jukwaa unayopima ni mtoa huduma wa OAuth [**soma hii ili kujaribu Masharti ya Mashindano yanayowezekana**](race-condition.md). ## Marejeo * [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) * [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
Jifunze kuhusu udukuzi wa AWS kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)! Njia nyingine za kusaidia HackTricks: * Ikiwa unataka kuona **kampuni yako inayotangazwa katika HackTricks** au **kupakua HackTricks katika PDF** Angalia [**MPANGO WA KUJIUNGA**](https://github.com/sponsors/carlospolop)! * Pata [**swag rasmi wa PEASS & HackTricks**](https://peass.creator-spring.com) * Gundua [**The PEASS Family**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee * **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au [**kikundi cha telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Shiriki mbinu zako za udukuzi kwa kuwasilisha PR kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.