GCP <--> Workspace Pivoting
Da GCP a GWS
Concetti di Delega su Larga Scala di Dominio
La delega su larga scala di dominio di Google Workspace consente a un oggetto di 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 questo, controlla:
GCP - Understanding Domain-Wide DelegationCompromissione della delega esistente
Se un attaccante ha compromesso alcuni accessi su GCP e conosce un'email utente valida di Workspace (preferibilmente super admin) 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 su larga scala 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 Admin sarai in grado di accedere a tutto. Se non ha alcun accesso, ciò sarà inutile.
Questo semplice script genererà un token OAuth come utente delegato che potrai poi utilizzare per accedere ad altre API Google con o senza gcloud
:
Questo è uno strumento che può eseguire l'attacco seguendo questi passaggi:
Enumerare i progetti GCP utilizzando l'API del Gestore delle risorse.
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.
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.
Creare una nuova chiave privata
KEY_ALG_RSA_2048
per ciascuna risorsa dell'account di servizio trovata con il permesso rilevante nella policy IAM.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 trovato rilevanti per abusare delle identità di Workspace.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, creare 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 scansionando gli 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.Enumerare e creare un nuovo token di accesso bearer per ciascun JWT e convalidare il token con l'API tokeninfo.
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:
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:
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'autorizzazioneiam.serviceAccounts.create
. Una volta creato l'account di servizio, procederemo a generare una coppia di chiavi correlata (autorizzazioneiam.serviceAccountKeys.create
).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.
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
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 (nello scope definito nel parametro di 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 REST API.
Controlla la sezione precedente per alcuni strumenti per utilizzare questa delega.
Delega tra organizzazioni incrociate
L'ID OAuth dell'account di servizio è globale e può essere utilizzato per deleghe tra organizzazioni incrociate. 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).
Controlla ulteriore enumerazione in:
GCP - IAM, Principals & Org Policies EnumAbuso di Gcloud
Puoi trovare ulteriori informazioni sul flusso gcloud
per effettuare il login in:
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:
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 a 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 google groups privesc potresti essere in grado di scalare a un gruppo con qualche tipo di accesso privilegiato a GCP.
Riferimenti
Last updated