GCP <--> Workspace Pivoting
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)
Delegation ya Domain-Wide ya Google Workspace inaruhusu kituo cha utambulisho, iwe ni 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:
Ikiwa 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 anatosha na inahitajika kwa ajili ya kujifanya. Hata hivyo, mamlaka ya mtumiaji anayejifananisha yatatumika, hivyo ikiwa ni Super Admin utaweza kupata 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 kupata APIs 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 SA na eneo la OAuth. Mchakato wa kuunda kitu kipya cha JWT ut pitia mchanganyiko wote wa maeneo ya OAuth kutoka orodha ya oauth_scopes.txt, ili kupata uwezekano wote wa uwakilishi. Orodha ya oauth_scopes.txt inasasishwa na maeneo yote ya OAuth ambayo tumepata kuwa muhimu kwa kutumia vitambulisho vya Workspace.
Njia ya _make_authorization_grant_assertion inaonyesha umuhimu wa kutangaza mtumiaji wa workspace wa lengo, anayeitwa subject, kwa ajili ya kuzalisha JWTs chini ya DWD. Ingawa hii inaweza kuonekana inahitaji mtumiaji maalum, ni muhimu kutambua kwamba DWD inaathiri kila kitambulisho ndani ya kikoa. Kwa hivyo, kuunda JWT kwa mtumiaji yeyote wa kikoa kunaathiri vitambulisho vyote katika kikoa hicho, 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 wa lengo hajulikani tayari, zana hii inarahisisha utambuzi wa moja kwa moja wa watumiaji halali wa workspace kwa kuskan watumiaji wa kikoa wenye majukumu kwenye miradi ya GCP. Ni muhimu kutambua (tena) kwamba JWTs ni maalum kwa kikoa na hazizalishwi kwa kila mtumiaji; hivyo, mchakato wa moja kwa moja unalenga kitambulisho kimoja cha kipekee kwa kila kikoa.
Tathmini na unda tokeni mpya ya ufikiaji 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:
It's possible to check Domain Wide Delegations in https://admin.google.com/u/1/ac/owl/domainwidedelegation.
An attacker with the ability to create service accounts in a GCP project and super admin privilege to GWS could create a new delegation allowing SAs to impersonate some GWS users:
Generating a New Service Account and Corresponding Key Pair: On GCP, new service account resources can be produced either interactively via the console or programmatically using direct API calls and CLI tools. This requires the role iam.serviceAccountAdmin or any custom role equipped with the iam.serviceAccounts.create permission. Once the service account is created, we'll proceed to generate a related key pair (iam.serviceAccountKeys.create permission).
Creation of new delegation: It's important to understand that only the Super Admin role possesses the capability to set up global Domain-Wide delegation in Google Workspace and Domain-Wide delegation cannot be set up programmatically, It can only be created and adjusted manually through the Google Workspace console.
The creation of the rule can be found under the page API controls → Manage Domain-Wide delegation in Google Workspace Admin console.
Attaching OAuth scopes privilege: When configuring a new delegation, Google requires only 2 parameters, the Client ID, which is the OAuth ID of the GCP Service Account resource, and OAuth scopes that define what API calls the delegation requires.
The full list of OAuth scopes can be found here, but here is a recommendation: 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
Acting on behalf of the target identity: At this point, we have a functioning delegated object in GWS. Now, using the GCP Service Account private key, we can perform API calls (in the scope defined in the OAuth scope parameter) to trigger it and act on behalf of any identity that exists in Google Workspace. As we learned, the service account will generate access tokens per its needs and according to the permission he has to REST API applications.
Check the previous section for some tools to use this delegation.
OAuth SA ID is global and can be used for cross-organizational delegation. There has been no restriction implemented to prevent cross-global delegation. In simple terms, service accounts from different GCP organizations can be used to configure domain-wide delegation on other Workspace organizations. This would result in only needing Super Admin access to Workspace, and not access to the same GCP account, as the adversary can create Service Accounts and private keys on his personally controlled GCP account.
By default Workspace users have the permission to create new projects, and when a new project is created the creator gets the Owner role over it.
Therefore, a user can create a project, enable the APIs to enumerate Workspace in his new project and try to enumerate it.
Ili mtumiaji aweze kuhesabu Workspace, anahitaji pia ruhusa za kutosha za Workspace (sio kila mtumiaji ataweza kuhesabu directory).
Check zaidi ya utafutaji katika:
You 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, labda hatashuku 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 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.
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 google groups privesc unaweza kuwa na uwezo wa kupandisha hadhi hadi kundi lenye aina fulani ya ufikiaji wa kibali kwa GCP.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
