GCP <--> Workspace Pivoting

Reading time: 11 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

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:

GCP - Understanding Domain-Wide Delegation

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

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

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

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

Gitlab ha creato questo script Python 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.

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.
  1. 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, 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
  1. 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:

GCP - IAM, Principals & Org Policies Enum

Abuso delle credenziali Gcloud

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

GCP - Token Persistence

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':

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/).

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

Riferimenti

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks