Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 in tutto il Workspace per conto degli utenti.
Questo significa fondamentalmente che gli account di servizio all'interno dei progetti GCP di un'organizzazione potrebbero essere in grado di fingere di essere utenti di Workspace della stessa organizzazione (o anche di un'altra).
Per ulteriori informazioni su come funziona esattamente, controlla:
GCP - Understanding Domain-Wide DelegationSe 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 impersonare l'utente con ciascun account di servizio.
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'impersonificazione. Tuttavia, i privilegi dell'utente impersonato saranno utilizzati, quindi se è Super Admin potrai accedere a tutto. Se non ha alcun accesso, questo sarà inutile.
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 è uno strumento che può eseguire l'attacco seguendo questi passaggi:
Enumerare i progetti GCP utilizzando l'API Resource Manager.
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 ogni 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.
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 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.
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 (di nuovo) 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.
Enumerare e creare un nuovo token di accesso bearer per ogni JWT e convalidare il token contro 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 mentre indica un json con le credenziali SA e l'utente da impersonare. Ecco come lo utilizzeresti:
È 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 SA di impersonare alcuni utenti GWS:
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).
Creazione di una nuova delega: È importante comprendere che solo il ruolo di Super Admin possiede 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.
Collegamento dei 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
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.
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 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.
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.
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).
Controlla ulteriore enumerazione in:
GCP - IAM, Principals & Org Policies EnumPuoi trovare ulteriori informazioni sul flusso gcloud per effettuare il login in:
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:
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':
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.
Per elencare i file di drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Se un attaccante ha accesso completo su 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.
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/).
Sfruttando il google groups privesc, potresti essere in grado di scalare a un gruppo con qualche tipo di accesso privilegiato a GCP.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
