GCP <--> Workspace Pivoting

Support HackTricks

From GCP to GWS

Misingi ya Delegation ya Domain Wide

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 Delegation

Kuathiri delegation iliyopo

Ikiwa mshambuliaji ameathiri baadhi ya ufikiaji 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 kuunda delegation ya domain wide, mtumiaji yeyote wa Workspace hatahitajika, kwa hivyo jua tu mtumiaji mmoja halali ni wa kutosha na inahitajika kwa 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 unda token ya OAuth kama mtumiaji aliyeteuliwa ambayo unaweza kutumia kufikia API nyingine za Google kwa kutumia au bila gcloud:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

Hii ni zana inayoweza kufanya shambulio ikifuatia hatua hizi:

  1. Tathmini Miradi ya GCP kwa kutumia Resource Manager API.

  2. 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.

  3. 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.

  4. Unda funguo mpya za KEY_ALG_RSA_2048 za faragha kwa kila rasilimali ya akaunti ya huduma ambayo imepatikana na ruhusa inayofaa katika sera ya IAM.

  5. 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 yanahusiana na kutumia vitambulisho vya Workspace.

  6. Mbinu ya _make_authorization_grant_assertion inaonyesha umuhimu wa kutangaza mtumiaji wa workspace inayolengwa, 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 ni wa kutosha kuendelea. Mtumiaji huyu anaweza kufafanuliwa katika faili ya config.yaml ya DeleFriend. Ikiwa mtumiaji wa workspace anay target bado hajulikani, 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.

  7. Tathmini na unda token ya ufikiaji wa bearer mpya kwa kila JWT na thibitisha token 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:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Create a new delegation (Persistence)

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:

  1. Kuzalisha Akaunti ya Huduma Mpya na Jifunguo Husika: Kwenye GCP, rasilimali mpya za akaunti za 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).

  2. Uundaji wa mamlaka mpya: Ni muhimu kuelewa kwamba ni tu jukumu la Super Admin 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.

  1. Kuweka ruhusa za OAuth scopes: Wakati wa configuring mamlaka mpya, Google inahitaji tu vigezo 2, Kitambulisho cha Mteja, ambacho ni OAuth ID ya 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

  1. Kufanya kazi 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 kazi 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.

Cross-Organizational delegation

OAuth SA ID ni ya kimataifa na inaweza kutumika kwa mamlaka ya kuvuka shirika. 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 sio ufikiaji wa akaunti hiyo hiyo ya GCP, kwani mpinzani anaweza kuunda Akaunti za Huduma na funguo binafsi kwenye akaunti yake ya GCP anayodhibiti kibinafsi.

Creating a Project to enumerate Workspace

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).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Check zaidi ya utafutaji katika:

GCP - IAM, Principals & Org Policies Enum

Kutumia Gcloud

You can find further information about the gcloud flow to login in:

GCP - Non-svc Persistance

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:

gcloud auth login --enable-gdrive-access

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 hatashtuka chochote.

Ili kuorodhesha faili za drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

From GWS to GCP

Access privileged GCP users

Ikiwa mshambuliaji ana ufikiaji kamili juu ya GWS ataweza kupata vikundi vyenye ufikiaji wa kibali 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.

Google Groups Privilege Escalation

Kwa kawaida watumiaji wanaweza kujiunga kwa uhuru 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 google groups privesc unaweza kuwa na uwezo wa kupandisha hadhi hadi kundi lenye aina fulani ya ufikiaji wa kibali kwa GCP.

References

Support HackTricks

Last updated