# GCP <--> Workspace Pivoting

{{#include ../../../banners/hacktricks-training.md}}

## **Van GCP na GWS**

### **Basiese domeinwye delegasie**

Google Workspace se domeinwye delegasie laat 'n identiteitsobjek, hetsy 'n **eksterne app** van Google Workspace Marketplace of 'n interne **GCP-diensrekening**, toe om **data oor die Workspace namens gebruikers te bekom**.

> [!NOTE]
> Dit beteken basies dat **diensrekeninge** binne GCP-projekte van 'n organisasie dalk in staat is om **Workspace-gebruikers** van dieselfde organisasie (of selfs van 'n ander) te **verpersoonlik**.

Vir meer inligting oor hoe dit presies werk, kyk:

{{#ref}}
gcp-understanding-domain-wide-delegation.md
{{#endref}}

### Kompromitteer bestaande delegasie

As 'n aanvaller **toegang oor GCP gekompromitteer het** en **'n geldige Workspace-gebruiker e-pos** (verkieslik **super admin**) van die maatskappy ken, kan hy **alle projekte** wat hy toegang het tot, **alle SA's** van die projekte opnoem, kyk na watter **diensrekeninge hy toegang het tot**, en **herhaal** al hierdie stappe met elke SA wat hy kan verpersoonlik.\
Met 'n **lys van al die diensrekeninge** waartoe hy **toegang** het en die lys van **Workspace** **e-posse**, kan die aanvaller probeer om **gebruikers met elke diensrekening te verpersoonlik**.

> [!CAUTION]
> Let daarop dat wanneer die domeinwye delegasie gekonfigureer word, geen Workspace-gebruiker benodig word nie, daarom is dit net nodig om **een geldige te ken wat genoeg is en vereis word vir die verpersoonliking**.\
> Die **privileges van die verpersoonlikte gebruiker sal egter gebruik word**, so as dit Super Admin is, sal jy toegang tot alles hê. As dit geen toegang het nie, sal dit nutteloos wees.

#### [GCP Genereer Delegasie Token](https://github.com/carlospolop/gcp_gen_delegation_token)

Hierdie eenvoudige skrip sal **'n OAuth-token genereer as die gedelegeerde gebruiker** wat jy dan kan gebruik om ander Google API's mee te benader met of sonder `gcloud`:
```bash
# 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"
```
#### [**DelePwn**](https://github.com/n0tspam/delepwn)

Gebaseer op die volgende DeleFriend tool, maar met 'n paar toevoegings soos die vermoë om die domein, skyf, gmail, kalender te enumereer en ander operasies uit te voer.

#### [**DeleFriend**](https://github.com/axon-git/DeleFriend)

Dit is 'n tool wat die aanval kan uitvoer volgens die volgende stappe:

1. **Enumereer GCP Projekte** met behulp van die Resource Manager API.
2. Herhaal op elke projek hulpbron, en **enumereer GCP Diensrekening hulpbronne** waartoe die aanvanklike IAM gebruiker toegang het met behulp van _GetIAMPolicy_.
3. Herhaal op **elke diensrekening rol**, en vind ingeboude, basiese, en pasgemaakte rolle met _**serviceAccountKeys.create**_ toestemming op die teiken diensrekening hulpbron. Dit moet opgemerk word dat die Editor rol inherent hierdie toestemming besit.
4. Skep 'n **nuwe `KEY_ALG_RSA_2048`** private sleutel vir elke diensrekening hulpbron wat gevind is met relevante toestemming in die IAM beleid.
5. Herhaal op **elke nuwe diensrekening en skep 'n `JWT`** **objek** daarvoor wat saamgestel is uit die SA private sleutel akkrediteer en 'n OAuth omvang. Die proses om 'n nuwe _JWT_ objek te skep sal **herhaal op al die bestaande kombinasies van OAuth omvange** van die **oauth_scopes.txt** lys, ten einde al die delegasie moontlikhede te vind. Die lys **oauth_scopes.txt** word opgedateer met al die OAuth omvange wat ons gevind het om relevant te wees vir die misbruik van Workspace identiteite.
6. Die `_make_authorization_grant_assertion` metode onthul die noodsaaklikheid om 'n t**eiken werkruimte gebruiker** te verklaar, verwys as _subject_, vir die generering van JWTs onder DWD. Terwyl dit mag lyk asof dit 'n spesifieke gebruiker vereis, is dit belangrik om te besef dat **DWD elke identiteit binne 'n domein beïnvloed**. Gevolglik, die skep van 'n JWT vir **enige domein gebruiker** beïnvloed al die identiteite in daardie domein, ooreenkomstig met ons kombinasie enumering kontrole. Eenvoudig gestel, een geldige Workspace gebruiker is voldoende om vorentoe te beweeg.\
Hierdie gebruiker kan gedefinieer word in DeleFriend se _config.yaml_ lêer. As 'n teiken werkruimte gebruiker nie reeds bekend is nie, fasiliteer die tool die outomatiese identifikasie van geldige werkruimte gebruikers deur domein gebruikers met rolle op GCP projekte te skandeer. Dit is belangrik om (weer) op te let dat JWTs domein-spesifiek is en nie vir elke gebruiker gegenereer word nie; daarom, die outomatiese proses teiken 'n enkele unieke identiteit per domein.
7. **Enumereer en skep 'n nuwe draer toegangstoken** vir elke JWT en valideer die token teen die tokeninfo API.

#### [Gitlab se Python skrip](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)

Gitlab het [hierdie Python skrip](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) geskep wat twee dinge kan doen - die gebruiker gids lys en 'n nuwe administratiewe rekening skep terwyl 'n json met SA akkrediteer en die gebruiker om te verpersoonlik aangedui word. Hier is hoe jy dit sou gebruik:
```bash
# 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
```
### Skep 'n nuwe delegasie (Volharding)

Dit is moontlik om **Domein Wye Delegasies in** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)** te kontroleer.**

'n Aanvaller met die vermoë om **diensrekeninge in 'n GCP-projek te skep** en **super admin voorregte in GWS kan 'n nuwe delegasie skep wat SAs toelaat om as sommige GWS-gebruikers op te tree:**

1. **Genereer 'n Nuwe Diensrekening en Ooreenstemmende Sleutel Paar:** Op GCP kan nuwe diensrekening hulpbronne interaktief via die konsole of programmaties met direkte API-oproepe en CLI-gereedskap geproduseer word. Dit vereis die **rol `iam.serviceAccountAdmin`** of enige aangepaste rol toegerus met die **`iam.serviceAccounts.create`** **toestemming**. Sodra die diensrekening geskep is, sal ons voortgaan om 'n **verwante sleutel paar** te genereer (**`iam.serviceAccountKeys.create`** toestemming).
2. **Skep van 'n nuwe delegasie**: Dit is belangrik om te verstaan dat **slegs die Super Admin rol die vermoë het om globale Domein-Wye delegasie in Google Workspace op te stel** en Domein-Wye delegasie **kan nie programmaties opgestel word nie,** dit kan slegs **handmatig** deur die Google Workspace **konsole** geskep en aangepas word.
- Die skepping van die reël kan onder die bladsy **API kontroles → Bestuur Domein-Wye delegasie in Google Workspace Admin konsole** gevind word.
3. **Hechting van OAuth skope voorreg**: Wanneer 'n nuwe delegasie gekonfigureer word, vereis Google slegs 2 parameters, die Klient ID, wat die **OAuth ID van die GCP Diensrekening** hulpbron is, en **OAuth skope** wat definieer watter API-oproepe die delegasie benodig.
- Die **volledige lys van OAuth skope** kan [**hier**](https://developers.google.com/identity/protocols/oauth2/scopes) gevind word, maar hier is 'n aanbeveling: `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`
4. **Optree namens die teiken identiteit:** Op hierdie punt het ons 'n funksionerende gedelegeerde objek in GWS. Nou, **met die GCP Diensrekening private sleutel, kan ons API-oproepe uitvoer** (in die omvang gedefinieer in die OAuth skooparameter) om dit te aktiveer en **namens enige identiteit wat in Google Workspace bestaan op te tree**. Soos ons geleer het, sal die diensrekening toegangstokens genereer volgens sy behoeftes en volgens die toestemming wat hy het vir REST API-toepassings.
- Kontroleer die **vorige afdeling** vir sommige **gereedskap** om hierdie delegasie te gebruik.

#### Kruis-Organisatoriese delegasie

OAuth SA ID is globaal en kan gebruik word vir **kruis-organisatoriese delegasie**. Daar is geen beperking geïmplementeer om kruis-globale delegasie te voorkom nie. In eenvoudige terme, **diensrekeninge van verskillende GCP-organisasies kan gebruik word om domein-wye delegasie op ander Workspace-organisasies te konfigureer**. Dit sou beteken dat **slegs Super Admin toegang tot Workspace benodig word**, en nie toegang tot dieselfde GCP-rekening nie, aangesien die teenstander diensrekeninge en private sleutels op sy persoonlik beheer GCP-rekening kan skep.

### Skep 'n Projek om Workspace te enumerate

Deur **standaard** het Workspace **gebruikers** die toestemming om **nuwe projekte te skep**, en wanneer 'n nuwe projek geskep word, ontvang die **skepper die Eienaar rol** oor dit.

Daarom kan 'n gebruiker **'n projek skep**, **APIs** aktiveer om Workspace in sy nuwe projek te enumerate en probeer om dit te **enumerate**.

> [!CAUTION]
> Ten einde vir 'n gebruiker moontlik te wees om Workspace te enumerate, benodig hy ook genoeg Workspace toestemming (nie elke gebruiker sal in staat wees om die gids te enumerate nie).
```bash
# 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>
```
Kontroleer **meer enumerasie in**:

{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}

### Misbruik van Gcloud geloofsbriewe

U kan verdere inligting oor die `gcloud` vloei om aan te meld vind in:

{{#ref}}
../gcp-persistence/gcp-non-svc-persistence.md
{{#endref}}

Soos daar verduidelik word, kan gcloud die omvang **`https://www.googleapis.com/auth/drive`** versoek wat 'n gebruiker in staat sou stel om toegang tot die gebruiker se skyf te verkry.\
As 'n aanvaller, as u fisies die rekenaar van 'n gebruiker gecompromitteer het en die **gebruiker is steeds aangemeld** met sy rekening, kan u aanmeld deur 'n token met toegang tot die skyf te genereer met:
```bash
gcloud auth login --enable-gdrive-access
```
As 'n aanvaller die rekenaar van 'n gebruiker kompromitteer, kan hy ook die lêer `google-cloud-sdk/lib/googlecloudsdk/core/config.py` wysig en die **`CLOUDSDK_SCOPES`** die omvang **`'https://www.googleapisapis.com/auth/drive'`** byvoeg:

<figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>

> [!WARNING]
> Daarom, die volgende keer wanneer die gebruiker aanmeld, sal hy 'n **token met toegang tot drive** skep wat die aanvaller kan misbruik om toegang tot die drive te verkry. Dit is duidelik dat die blaaier sal aandui dat die gegenereerde token toegang tot drive sal hê, maar aangesien die gebruiker homself die **`gcloud auth login`** sal noem, sal hy waarskynlik **niks vermoed nie.**
>
> Om drive-lêers te lys: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**

## Van GWS na GCP

### Toegang tot bevoorregte GCP-gebruikers

As 'n aanvaller volledige toegang oor GWS het, sal hy in staat wees om toegang te verkry tot groepe met bevoorregte toegang oor GCP of selfs gebruikers, daarom is dit gewoonlik "eenvoudiger" om van GWS na GCP te beweeg net omdat **gebruikers in GWS hoë voorregte oor GCP het**.

### Google Groups Bevoorregting Escalatie

Standaard kan gebruikers **vrylik by Workspace-groepe van die Organisasie aansluit** en daardie groepe **kan GCP-toestemmings** toegeken hê (kontroleer jou groepe in [https://groups.google.com/](https://groups.google.com/)).

Deur die **google groups privesc** te misbruik, mag jy in staat wees om na 'n groep met 'n soort bevoorregte toegang tot GCP te eskaleer.

### Verwysings

- [https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover](https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover)

{{#include ../../../banners/hacktricks-training.md}}
