# GCP <--> Workspace Pivoting

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

## **Da GCP a GWS**

### **Nozioni di base sulla delega a livello di dominio**

La delega a livello di dominio di Google Workspace consente a un oggetto identità, sia un **app esterna** dal Google Workspace Marketplace che un **Account di Servizio GCP** interno, di **accedere ai dati attraverso il Workspace per conto degli utenti**.

> [!NOTE]
> Questo significa fondamentalmente che gli **account di servizio** all'interno dei progetti GCP di un'organizzazione potrebbero essere in grado di **impostare l'identità degli utenti di Workspace** della stessa organizzazione (o anche di un'altra).

Per ulteriori informazioni su come funziona esattamente, controlla:

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

### Compromettere la delega esistente

Se un attaccante **ha compromesso alcuni accessi su GCP** e **conosce un'email valida di un utente di Workspace** (preferibilmente **super admin**) dell'azienda, potrebbe **enumerare tutti i progetti** a cui ha accesso, **enumerare tutti gli SA** dei progetti, controllare a quali **account di servizio ha accesso** e **ripetere** tutti questi passaggi con ciascun SA che può impersonare.\
Con un **elenco di tutti gli account di servizio** a cui ha **accesso** e l'elenco delle **email di Workspace**, l'attaccante potrebbe provare a **impostare l'identità dell'utente con ciascun account di servizio**.

> [!CAUTION]
> Nota che quando si configura la delega a livello di dominio non è necessario alcun utente di Workspace, quindi basta sapere che **uno valido è sufficiente e richiesto per l'impostazione dell'identità**.\
> Tuttavia, i **privilegi dell'utente impersonato saranno utilizzati**, quindi se è Super Admin potrai accedere a tutto. Se non ha alcun accesso, questo sarà inutile.

#### [GCP Genera Token di Delega](https://github.com/carlospolop/gcp_gen_delegation_token)

Questo semplice script **genererà un token OAuth come utente delegato** che puoi poi utilizzare per accedere ad altre API di Google con o senza `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)

Basato sul seguente strumento DeleFriend, ma con alcune aggiunte come la possibilità di enumerare il dominio, l'unità, gmail, il calendario e eseguire altre operazioni.

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

Questo è uno strumento che può eseguire l'attacco seguendo questi passaggi:

1. **Enumerare i progetti GCP** utilizzando l'API Resource Manager.
2. Iterare su ciascuna risorsa del progetto e **enumerare le risorse degli account di servizio GCP** a cui l'utente IAM iniziale ha accesso utilizzando _GetIAMPolicy_.
3. Iterare su **ciascun ruolo dell'account di servizio** e trovare ruoli incorporati, di base e personalizzati con il permesso _**serviceAccountKeys.create**_ sulla risorsa dell'account di servizio target. Va notato che il ruolo di Editor possiede intrinsecamente questo permesso.
4. Creare una **nuova chiave privata `KEY_ALG_RSA_2048`** per ciascuna risorsa dell'account di servizio che è stata trovata con il permesso rilevante nella policy IAM.
5. Iterare su **ciascun nuovo account di servizio e creare un oggetto `JWT`** per esso composto dalle credenziali della chiave privata SA e da un ambito OAuth. Il processo di creazione di un nuovo oggetto _JWT_ **itererà su tutte le combinazioni esistenti di ambiti OAuth** dalla lista **oauth_scopes.txt**, al fine di trovare tutte le possibilità di delega. La lista **oauth_scopes.txt** è aggiornata con tutti gli ambiti OAuth che abbiamo trovato rilevanti per abusare delle identità di Workspace.
6. Il metodo `_make_authorization_grant_assertion` rivela la necessità di dichiarare un **utente workspace target**, riferito come _subject_, per generare JWT sotto DWD. Anche se questo può sembrare richiedere un utente specifico, è importante rendersi conto che **DWD influisce su ogni identità all'interno di un dominio**. Di conseguenza, creare un JWT per **qualsiasi utente di dominio** influisce su tutte le identità in quel dominio, coerente con il nostro controllo di enumerazione delle combinazioni. In parole semplici, un utente Workspace valido è sufficiente per procedere.\
Questo utente può essere definito nel file _config.yaml_ di DeleFriend. Se un utente workspace target non è già noto, lo strumento facilita l'identificazione automatica di utenti workspace validi scansionando gli utenti di dominio con ruoli sui progetti GCP. È fondamentale notare (ancora) che i JWT sono specifici per il dominio e non generati per ogni utente; pertanto, il processo automatico mira a un'unica identità unica per dominio.
7. **Enumerare e creare un nuovo token di accesso bearer** per ciascun JWT e convalidare il token contro l'API tokeninfo.

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

Gitlab ha creato [questo script Python](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) che può fare due cose: elencare la directory degli utenti e creare un nuovo account amministrativo indicando un json con le credenziali SA e l'utente da impersonare. Ecco come lo utilizzeresti:
```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
```
### Crea una nuova delega (Persistenza)

È possibile **controllare le deleghe a livello di dominio in** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**

Un attaccante con la capacità di **creare account di servizio in un progetto GCP** e **privilegi di super amministratore su GWS potrebbe creare una nuova delega che consente agli SAs di impersonare alcuni utenti GWS:**

1. **Generazione di un nuovo account di servizio e del relativo paio di chiavi:** Su GCP, nuove risorse di account di servizio possono essere prodotte sia interattivamente tramite la console che programmaticamente utilizzando chiamate API dirette e strumenti CLI. Questo richiede il **ruolo `iam.serviceAccountAdmin`** o qualsiasi ruolo personalizzato dotato del **permesso `iam.serviceAccounts.create`**. Una volta creato l'account di servizio, procederemo a generare un **paio di chiavi correlate** (**permesso `iam.serviceAccountKeys.create`**).
2. **Creazione di una nuova delega**: È importante comprendere che **solo il ruolo di Super Admin ha la capacità di impostare la delega globale a livello di dominio in Google Workspace** e la delega a livello di dominio **non può essere impostata programmaticamente,** può essere creata e regolata **manualmente** tramite la **console** di Google Workspace.
- La creazione della regola può essere trovata nella pagina **Controlli API → Gestisci delega a livello di dominio nella console di amministrazione di Google Workspace**.
3. **Attaccare i privilegi degli ambiti OAuth**: Quando si configura una nuova delega, Google richiede solo 2 parametri, l'ID client, che è l'**ID OAuth della risorsa dell'account di servizio GCP**, e gli **ambiti OAuth** che definiscono quali chiamate API richiede la delega.
- L'**elenco completo degli ambiti OAuth** può essere trovato [**qui**](https://developers.google.com/identity/protocols/oauth2/scopes), ma qui c'è una raccomandazione: `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. **Agire per conto dell'identità target:** A questo punto, abbiamo un oggetto delegato funzionante in GWS. Ora, **utilizzando la chiave privata dell'account di servizio GCP, possiamo eseguire chiamate API** (nell'ambito definito nel parametro dell'ambito OAuth) per attivarlo e **agire per conto di qualsiasi identità esistente in Google Workspace**. Come abbiamo appreso, l'account di servizio genererà token di accesso secondo le proprie necessità e in base ai permessi che ha per le applicazioni REST API.
- Controlla la **sezione precedente** per alcuni **strumenti** da utilizzare con questa delega.

#### Delega inter-organizzativa

L'ID SA OAuth è globale e può essere utilizzato per **delega inter-organizzativa**. Non è stata implementata alcuna restrizione per prevenire la delega interglobale. In termini semplici, **gli account di servizio di diverse organizzazioni GCP possono essere utilizzati per configurare la delega a livello di dominio su altre organizzazioni Workspace**. Questo comporterebbe **la necessità solo di accesso da Super Admin a Workspace**, e non accesso allo stesso account GCP, poiché l'avversario può creare account di servizio e chiavi private sul proprio account GCP controllato personalmente.

### Creazione di un progetto per enumerare Workspace

Per **definizione** gli **utenti** di Workspace hanno il permesso di **creare nuovi progetti**, e quando viene creato un nuovo progetto, il **creatore ottiene il ruolo di Proprietario** su di esso.

Pertanto, un utente può **creare un progetto**, **abilitare** le **API** per enumerare Workspace nel suo nuovo progetto e provare a **enumerarlo**.

> [!CAUTION]
> Affinché un utente possa enumerare Workspace, ha anche bisogno di permessi sufficienti su Workspace (non tutti gli utenti saranno in grado di enumerare la directory).
```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>
```
Controlla **ulteriore enumerazione in**:

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

### Abuso delle credenziali Gcloud

Puoi trovare ulteriori informazioni sul flusso `gcloud` per effettuare il login in:

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

Come spiegato lì, gcloud può richiedere l'ambito **`https://www.googleapis.com/auth/drive`** che consentirebbe a un utente di accedere al drive dell'utente.\
Come attaccante, se hai compromesso **fisicamente** il computer di un utente e l'**utente è ancora connesso** con il suo account, potresti effettuare il login generando un token con accesso al drive utilizzando:
```bash
gcloud auth login --enable-gdrive-access
```
Se un attaccante compromette il computer di un utente, potrebbe anche modificare il file `google-cloud-sdk/lib/googlecloudsdk/core/config.py` e aggiungere in **`CLOUDSDK_SCOPES`** l'ambito **`'https://www.googleapis.com/auth/drive'**:

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

> [!WARNING]
> Pertanto, la prossima volta che l'utente accede, creerà un **token con accesso a drive** che l'attaccante potrebbe sfruttare per accedere al drive. Ovviamente, il browser indicherà che il token generato avrà accesso a drive, ma poiché l'utente chiamerà lui stesso **`gcloud auth login`**, probabilmente **non sospetterà nulla.**
>
> Per elencare i file di drive: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**

## Da GWS a GCP

### Accesso a utenti privilegiati di GCP

Se un attaccante ha accesso completo a GWS, sarà in grado di accedere a gruppi con accesso privilegiato su GCP o anche a utenti, quindi passare da GWS a GCP è solitamente più "semplice" solo perché **gli utenti in GWS hanno alti privilegi su GCP**.

### Escalation dei privilegi di Google Groups

Per impostazione predefinita, gli utenti possono **unirsi liberamente ai gruppi di Workspace dell'Organizzazione** e quei gruppi **potrebbero avere permessi GCP** assegnati (controlla i tuoi gruppi in [https://groups.google.com/](https://groups.google.com/)).

Sfruttando il **google groups privesc**, potresti essere in grado di scalare a un gruppo con qualche tipo di accesso privilegiato a GCP.

### Riferimenti

- [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}}
