GCP <--> Workspace Pivoting
From GCP to GWS
Msingi wa Delegation ya Domain Wide
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:
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 kusanidi delegation ya domain wide, mtumiaji yeyote wa Workspace haitajiki, kwa hivyo jua tu mtumiaji mmoja halali inatosha na inahitajika 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 aliyeteuliwa 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_2048ya 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
JWTkitu 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 ambayo tumepata kuwa muhimu kwa kutumia vitambulisho vya Workspace.Njia ya
_make_authorization_grant_assertioninaonyesha 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 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 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:
Create a new delegation (Persistence)
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.serviceAccountAdminor any custom role equipped with theiam.serviceAccounts.createpermission. Once the service account is created, we'll proceed to generate a related key pair (iam.serviceAccountKeys.createpermission).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.
Cross-Organizational 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.
Creating a Project to enumerate Workspace
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:
Kutumia vibaya akreditivu za Gcloud
Unaweza kupata taarifa zaidi kuhusu mtiririko wa gcloud kuingia katika:
Kama ilivyoelezwa hapo, gcloud inaweza kuomba upeo https://www.googleapis.com/auth/drive ambao utamruhusu mtumiaji kufikia diski ya mtumiaji.
Kama mshambuliaji, ikiwa umepata kimwili kompyuta ya mtumiaji na mtumiaji bado ameingia na akaunti yake unaweza kuingia kwa kuzalisha tokeni yenye ufikiaji wa diski kwa kutumia:
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"
Kutoka GWS hadi GCP
Ufikiaji wa watumiaji wenye mamlaka ya GCP
Ikiwa mshambuliaji ana ufikiaji kamili juu ya GWS atakuwa na uwezo wa kufikia 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.
Kuinua Mamlaka ya Vikundi vya Google
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.
Marejeleo
Last updated
