mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 06:30:35 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -26,9 +26,9 @@ Con un **elenco di tutti gli account di servizio** a cui ha **accesso** e l'elen
|
||||
> 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 Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
#### [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 Google con o senza `gcloud`:
|
||||
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>
|
||||
@@ -36,20 +36,24 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
# 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 dell'account di servizio GCP** a cui l'utente IAM iniziale ha accesso utilizzando _GetIAMPolicy_.
|
||||
3. Iterare su **ogni ruolo dell'account di servizio** e trovare ruoli predefiniti, 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.
|
||||
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 **ogni 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, in linea 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 vengono generati per ogni utente; pertanto, il processo automatico mira a un'unica identità unica per dominio.
|
||||
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.
|
||||
|
||||
#### [Script Python di Gitlab](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
#### [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
|
||||
@@ -77,28 +81,28 @@ pip install --upgrade --user oauth2client
|
||||
|
||||
È 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 SA di impersonare alcuni utenti GWS:**
|
||||
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, le 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`**).
|
||||
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 **ambiti OAuth** che definiscono quali chiamate API richiede la delega.
|
||||
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à di avere solo 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.
|
||||
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.
|
||||
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 sufficienti permessi di Workspace (non tutti gli utenti saranno in grado di enumerare la directory).
|
||||
> 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
|
||||
@@ -135,12 +139,12 @@ Come attaccante, se hai compromesso **fisicamente** il computer di un utente e l
|
||||
```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'`**:
|
||||
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 si chiamerà **`gcloud auth login`**, probabilmente **non sospetterà nulla.**
|
||||
> 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"`**
|
||||
|
||||
@@ -152,7 +156,7 @@ Se un attaccante ha accesso completo a GWS, sarà in grado di accedere a gruppi
|
||||
|
||||
### Escalation dei privilegi di Google Groups
|
||||
|
||||
Per impostazione predefinita, gli utenti possono **unirsi liberamente ai gruppi Workspace dell'Organizzazione** e quei gruppi **potrebbero avere permessi GCP** assegnati (controlla i tuoi gruppi in [https://groups.google.com/](https://groups.google.com/)).
|
||||
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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user