Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Delegation ya Domain-Wide ya Google Workspace inaruhusu kituo cha utambulisho, ama programu ya nje kutoka Google Workspace Marketplace au GCP Service Account ya ndani, kupata data katika Workspace kwa niaba ya watumiaji.
Hii inamaanisha kwamba akaunti za huduma ndani ya miradi ya GCP ya shirika zinaweza kuwa na uwezo wa kujifanya watumiaji wa Workspace wa shirika hilo hilo (au hata kutoka shirika tofauti).
Kwa maelezo zaidi kuhusu jinsi hii inavyofanya kazi angalia:
GCP - Understanding Domain-Wide DelegationIkiwa mshambuliaji ameathiri ufikiaji fulani juu ya GCP na anajua barua pepe halali ya mtumiaji wa Workspace (kama inavyopendelewa super admin) wa kampuni, anaweza kuorodhesha miradi yote ambayo ana ufikiaji nayo, kuorodhesha SAs zote za miradi, kuangalia ni akaunti za huduma zipi ana ufikiaji nazo, na kurudia hatua hizi zote na kila SA anayeweza kujifanya. Kwa orodha ya akaunti zote za huduma alizo na ufikiaji nazo na orodha ya barua pepe za Workspace, mshambuliaji anaweza kujaribu kujifanya mtumiaji kwa kila akaunti ya huduma.
Kumbuka kwamba wakati wa kusanidi delegation ya domain wide, mtumiaji yeyote wa Workspace hatahitajika, kwa hivyo jua tu mtumiaji mmoja halali ni wa kutosha na unahitajika kwa ajili ya kujifanya. Hata hivyo, mamlaka ya mtumiaji anayejifananisha yatatumika, hivyo ikiwa ni Super Admin utaweza kufikia kila kitu. Ikiwa haina ufikiaji wowote hii itakuwa haina maana.
Hii ni script rahisi itakay zalisha token ya OAuth kama mtumiaji aliyepewa mamlaka ambayo unaweza kutumia kufikia API nyingine za Google kwa kutumia au bila gcloud:
Hii ni zana inayoweza kufanya shambulio ikifuatia hatua hizi:
Tathmini Miradi ya GCP kwa kutumia Resource Manager API.
Pitia kila rasilimali ya mradi, na tathmini rasilimali za akaunti ya huduma ya GCP ambazo mtumiaji wa IAM wa awali ana ufikiaji kwa kutumia GetIAMPolicy.
Pitia kila jukumu la akaunti ya huduma, na pata majukumu ya ndani, ya msingi, na ya kawaida yenye ruhusa ya serviceAccountKeys.create kwenye rasilimali ya akaunti ya huduma inayolengwa. Inapaswa kuzingatiwa kwamba jukumu la Mhariri kwa asili lina ruhusa hii.
Unda funguo mpya ya KEY_ALG_RSA_2048 ya faragha kwa kila rasilimali ya akaunti ya huduma ambayo imepatikana na ruhusa inayofaa katika sera ya IAM.
Pitia kila akaunti ya huduma mpya na unda JWT kitu kwa ajili yake ambacho kinajumuisha akidi za funguo za faragha za SA na eneo la OAuth. Mchakato wa kuunda kitu kipya cha JWT ut apitia mchanganyiko wote wa maeneo ya OAuth kutoka kwenye orodha ya oauth_scopes.txt, ili kupata uwezekano wote wa uwakilishi. Orodha ya oauth_scopes.txt inasasishwa na maeneo yote ya OAuth tuliyogundua kuwa muhimu kwa kutumia vitambulisho vya Workspace.
Mbinu ya _make_authorization_grant_assertion inaonyesha umuhimu wa kutangaza mtumiaji wa workspace wa lengo, anayeitwa subject, kwa ajili ya kuunda JWTs chini ya DWD. Ingawa hii inaweza kuonekana inahitaji mtumiaji maalum, ni muhimu kutambua kwamba DWD inaathiri kila kitambulisho ndani ya eneo. Kwa hivyo, kuunda JWT kwa mtumiaji yeyote wa eneo kunaathiri vitambulisho vyote katika eneo hilo, kulingana na ukaguzi wetu wa mchanganyiko. Kwa maneno rahisi, mtumiaji mmoja halali wa Workspace anatosha kuendelea.
Mtumiaji huyu anaweza kufafanuliwa katika faili ya config.yaml ya DeleFriend. Ikiwa mtumiaji wa workspace wa lengo hajulikani tayari, zana hii inarahisisha utambuzi wa moja kwa moja wa watumiaji halali wa workspace kwa kuskan watumiaji wa eneo wenye majukumu kwenye miradi ya GCP. Ni muhimu kutambua (tena) kwamba JWTs ni maalum kwa eneo na hazizalishwi kwa kila mtumiaji; hivyo, mchakato wa moja kwa moja unalenga kitambulisho kimoja cha kipekee kwa kila eneo.
Tathmini na unda tokeni mpya ya ufikiaji wa bearer kwa kila JWT na thibitisha tokeni hiyo dhidi ya tokeninfo API.
Gitlab imeunda hii script ya Python ambayo inaweza kufanya mambo mawili - orodhesha directory ya mtumiaji na kuunda akaunti mpya ya kiutawala huku ikionyesha json yenye akidi za SA na mtumiaji wa kuiga. Hapa kuna jinsi unavyoweza kuitumia:
Ni uwezekano wa kuangalia Mamlaka ya Kikoa Kote katika https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Mshambuliaji mwenye uwezo wa kuunda akaunti za huduma katika mradi wa GCP na privilege ya super admin kwa GWS anaweza kuunda mamlaka mpya inayoruhusu SAs kuiga baadhi ya watumiaji wa GWS:
Kuzalisha Akaunti ya Huduma Mpya na Jifunguo Husika: Kwenye GCP, rasilimali mpya za akaunti ya huduma zinaweza kuzalishwa ama kwa njia ya kuingiliana kupitia console au kwa njia ya programu kwa kutumia wito wa moja kwa moja wa API na zana za CLI. Hii inahitaji role iam.serviceAccountAdmin au jukumu lolote la kawaida lililo na iam.serviceAccounts.create ruhusa. Mara akaunti ya huduma itakapoundwa, tutaendelea kuzalisha jifunguo husika (iam.serviceAccountKeys.create ruhusa).
Uundaji wa mamlaka mpya: Ni muhimu kuelewa kwamba ni tu jukumu la Super Admin ndilo lina uwezo wa kuanzisha mamlaka ya Kikoa Kote katika Google Workspace na mamlaka ya Kikoa Kote haiwezi kuanzishwa kwa njia ya programu, Inaweza kuundwa na kurekebishwa kwa mikono kupitia console ya Google Workspace.
Uundaji wa sheria unaweza kupatikana chini ya ukurasa API controls → Manage Domain-Wide delegation in Google Workspace Admin console.
Kuweka ruhusa za OAuth scopes: Wakati wa kuunda mamlaka mpya, Google inahitaji tu vigezo 2, Kitambulisho cha Mteja, ambacho ni Kitambulisho cha OAuth cha Rasilimali ya Akaunti ya Huduma ya GCP, na OAuth scopes zinazofafanua ni wito gani wa API mamlaka inahitaji.
orodha kamili ya OAuth scopes inaweza kupatikana hapa, lakini hapa kuna pendekezo: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Kufanya kwa niaba ya kitambulisho cha lengo: Katika hatua hii, tuna kitu kilichopewa mamlaka kinachofanya kazi katika GWS. Sasa, tukitumia funguo binafsi za Akaunti ya Huduma ya GCP, tunaweza kufanya wito wa API (katika upeo ulioainishwa katika vigezo vya OAuth scope) ili kuhamasisha na kufanya kwa niaba ya kitambulisho chochote kilichopo katika Google Workspace. Kama tulivyojifunza, akaunti ya huduma itazalisha tokeni za ufikiaji kulingana na mahitaji yake na kulingana na ruhusa alizonazo kwa programu za REST API.
Angalia sehemu ya awali kwa baadhi ya zana za kutumia mamlaka hii.
Kitambulisho cha OAuth SA ni cha kimataifa na kinaweza kutumika kwa mamlaka ya kuvuka mashirika. Hakuna vizuizi vilivyowekwa kuzuia mamlaka ya kuvuka kimataifa. Kwa maneno rahisi, akaunti za huduma kutoka mashirika tofauti ya GCP zinaweza kutumika kuunda mamlaka ya kikoa kote kwenye mashirika mengine ya Workspace. Hii itasababisha kuhitaji tu ufikiaji wa Super Admin kwa Workspace, na si ufikiaji wa akaunti hiyo hiyo ya GCP, kwani mpinzani anaweza kuunda Akaunti za Huduma na funguo binafsi kwenye akaunti yake ya GCP anayoitawala.
Kwa default watumiaji wa Workspace wana ruhusa ya kuunda miradi mipya, na wakati mradi mpya unaundwa mwandishi anapata jukumu la Mmiliki juu yake.
Hivyo, mtumiaji anaweza kuunda mradi, kuwezesha APIs ili kuhesabu Workspace katika mradi wake mpya na kujaribu kuhesabu.
Ili mtumiaji aweze kuhesabu Workspace anahitaji pia ruhusa za kutosha za Workspace (sio kila mtumiaji ataweza kuhesabu directory).
Check zaidi ya utafutaji katika:
GCP - IAM, Principals & Org Policies EnumYou can find further information about the gcloud flow to login in:
As explained there, gcloud can request the scope https://www.googleapis.com/auth/drive which would allow a user to access the drive of the user.
As an attacker, if you have compromised kimwili the computer of a user and the mtumiaji bado ameingia with his account you could login generating a token with access to drive using:
If an attacker compromises the computer of a user he could also modify the file google-cloud-sdk/lib/googlecloudsdk/core/config.py and add in the CLOUDSDK_SCOPES the scope 'https://www.googleapis.com/auth/drive':
Hivyo, wakati mtumiaji atakapojisajili tena ataunda token yenye ufikiaji wa drive ambayo mshambuliaji anaweza kuitumia kupata drive. Kwa wazi, kivinjari kitaonyesha kwamba token iliyoundwa itakuwa na ufikiaji wa drive, lakini kwa kuwa mtumiaji atajita gcloud auth login, huenda hata shuku chochote.
Ili kuorodhesha faili za drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Ikiwa mshambuliaji ana ufikiaji kamili juu ya GWS ataweza kupata vikundi vyenye ufikiaji wa mamlaka juu ya GCP au hata watumiaji, hivyo kuhamia kutoka GWS hadi GCP kwa kawaida ni "rahisi" zaidi kwa sababu watumiaji katika GWS wana mamlaka makubwa juu ya GCP.
Kwa kawaida watumiaji wanaweza kujiunga kwa urahisi na vikundi vya Workspace vya Shirika na vikundi hivyo vinaweza kuwa na ruhusa za GCP zilizotolewa (angalia vikundi vyako katika https://groups.google.com/).
Kwa kutumia kuinua mamlaka ya vikundi vya google unaweza kuwa na uwezo wa kuinua hadi kundi lenye aina fulani ya ufikiaji wa mamlaka kwa GCP.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
