Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Impara l'hacking di AWS da zero a esperto con htARTE (Esperto Red Team di HackTricks AWS)!

Altri modi per supportare 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 o un Account di servizio GCP interno, di accedere ai dati in tutta l'organizzazione a nome degli utenti.

Questo significa essenzialmente che gli account di servizio all'interno dei progetti GCP di un'organizzazione potrebbero essere in grado di impersonare gli utenti di Workspace della stessa organizzazione (o anche di un'altra).

Per ulteriori informazioni su come funziona esattamente, controlla:

pageGCP - Understanding Domain-Wide Delegation

Compromissione della delega esistente

Se un attaccante ha compromesso alcuni accessi su GCP e conosce un'email utente valida di Workspace (preferibilmente super amministratore) dell'azienda, potrebbe enumerare tutti i progetti a cui ha accesso, enumerare tutti gli Account di servizio dei progetti, controllare a quali account di servizio ha accesso, e ripetere tutti questi passaggi con ciascun Account di servizio 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 impersonare l'utente con ciascun account di servizio.

Nota che quando si configura la delega a livello di dominio non è necessario un utente di Workspace, quindi conoscere uno valido è sufficiente e necessario per l'impersonificazione. Tuttavia, verranno utilizzati i privilegi dell'utente impersonato, quindi se è un Super Amministratore sarai in grado di accedere a tutto. Se non ha alcun accesso, ciò sarà inutile.

Genera Token di Delega GCP

Questo semplice script genererà un token OAuth come utente delegato che potrai poi utilizzare per accedere ad altre API di Google con o senza gcloud:

# 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"

DeleFriend

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

  1. Enumerare i progetti GCP utilizzando l'API del Gestore delle risorse.

  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 di destinazione. Va notato che il ruolo di Editor possiede inherentemente questo permesso.

  4. Creare una nuova chiave privata KEY_ALG_RSA_2048 per ciascuna risorsa dell'account di servizio 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 uno scope OAuth. Il processo di creazione di un nuovo oggetto JWT itererà su tutte le combinazioni esistenti di scope OAuth dalla lista oauth_scopes.txt, al fine di trovare tutte le possibilità di delega. La lista oauth_scopes.txt viene aggiornata con tutti gli scope OAuth che abbiamo ritenuto rilevanti per abusare delle identità di Workspace.

  6. Il metodo _make_authorization_grant_assertion rivela la necessità di dichiarare un utente di Workspace di destinazione, denominato subject, per generare JWT sotto DWD. Anche se potrebbe sembrare necessario un utente specifico, è importante capire che DWD influenza ogni identità all'interno di un dominio. Di conseguenza, la creazione di un JWT per qualsiasi utente di dominio influisce su tutte le identità in quel dominio, coerentemente con il nostro controllo di enumerazione delle combinazioni. In poche parole, un singolo utente valido di Workspace è sufficiente per procedere. Questo utente può essere definito nel file config.yaml di DeleFriend. Se un utente di Workspace di destinazione non è già noto, lo strumento facilita l'identificazione automatica degli utenti di Workspace validi eseguendo la scansione degli utenti di dominio con ruoli nei progetti GCP. È importante notare (ancora una volta) che i JWT sono specifici del dominio e non vengono generati per ogni utente; quindi, 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 con l'API tokeninfo.

Script Python di Gitlab

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 si utilizzerebbe:

# 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

Creare una nuova delega (Persistenza)

È possibile verificare 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 consentendo agli account di servizio di impersonare alcuni utenti di GWS:

  1. Generazione di un nuovo account di servizio e coppia di chiavi corrispondente: Su GCP, nuove risorse di account di servizio possono essere prodotte interattivamente tramite la console o programmaticamente utilizzando chiamate API dirette e strumenti CLI. Ciò richiede il ruolo iam.serviceAccountAdmin o qualsiasi ruolo personalizzato dotato dell'autorizzazione iam.serviceAccounts.create. Una volta creato l'account di servizio, procederemo a generare una coppia di chiavi correlata (autorizzazione iam.serviceAccountKeys.create).

  2. Creazione di una nuova delega: È importante comprendere che solo il ruolo di Super Amministratore possiede la capacità di configurare la delega globale a livello di dominio in Google Workspace e la delega a livello di dominio non può essere configurata in modo programmato, può solo essere creata e regolata manualmente tramite la console di Google Workspace.

  • La creazione della regola può essere trovata nella pagina Controlli API → Gestisci la delega a livello di dominio in Google Workspace Admin console.

  1. Attivazione del privilegio degli ambiti OAuth: Quando si configura una nuova delega, Google richiede solo 2 parametri, l'ID client, che è l'ID OAuth 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 ecco 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 a nome dell'identità target: A questo punto, abbiamo un oggetto delegato funzionante in GWS. Ora, utilizzando la chiave privata dell'account di servizio GCP, possiamo effettuare chiamate API (nel ambito definito nel parametro ambito OAuth) per attivarlo e agire a nome di qualsiasi identità esistente in Google Workspace. Come abbiamo appreso, l'account di servizio genererà token di accesso secondo le sue esigenze e in base all'autorizzazione che ha per le applicazioni API REST.

  • Controlla la sezione precedente per alcuni strumenti per utilizzare questa delega.

Delega tra organizzazioni

L'ID SA OAuth è globale e può essere utilizzato per deleghe tra organizzazioni. Non è stata implementata alcuna restrizione per impedire la delega globale incrociata. In parole semplici, gli account di servizio di diverse organizzazioni GCP possono essere utilizzati per configurare la delega a livello di dominio su altre organizzazioni di Workspace. Ciò comporterebbe il bisogno solo di accesso Super Amministratore a Workspace, e non l'accesso allo stesso account GCP, poiché l'avversario può creare Account di Servizio e chiavi private sul suo account GCP personalmente controllato.

Creazione di un Progetto per enumerare Workspace

Per default 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.

Affinché un utente possa enumerare Workspace ha anche bisogno di abbastanza permessi di Workspace (non tutti gli utenti saranno in grado di enumerare la directory).

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

pageGCP - IAM, Principals & Org Policies Enum

Abuso di Gcloud

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

pageGCP - Non-svc Persistance

Come spiegato lì, gcloud può richiedere lo scope 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:

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 nello CLOUDSDK_SCOPES lo scope 'https://www.googleapis.com/auth/drive':

Pertanto, la prossima volta che l'utente effettuerà l'accesso, verrà creato 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 eseguirà il comando 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 agli utenti privilegiati di GCP

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

Escalation dei privilegi dei Google Groups

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

Sfruttando la privilege escalation dei google groups potresti essere in grado di passare a un gruppo con qualche tipo di accesso privilegiato a GCP.

Riferimenti

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousGCP - Storage EnumNextGCP - Understanding Domain-Wide Delegation

Last updated