Last updated
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Per un'introduzione su cosa sia un account di servizio, controlla:
GCP - Basic InformationUn account di servizio appartiene sempre a un progetto:
Per un'introduzione su come funzionano gli Utenti e i Gruppi in GCP, controlla:
GCP - Basic InformationCon i permessi serviceusage.services.enable e serviceusage.services.use è possibile abilitare i servizi in un progetto e utilizzarli.
Nota che per impostazione predefinita, gli utenti di Workspace ricevono il ruolo di Creatore di Progetti, concedendo loro accesso per creare nuovi progetti. Quando un utente crea un progetto, gli viene assegnato il ruolo di owner su di esso. Quindi, potrebbe abilitare questi servizi sul progetto per poter enumerare Workspace.
Tuttavia, nota che è anche necessario avere sufficienti permessi in Workspace per poter chiamare queste API.
Se puoi abilitare il servizio admin e se il tuo utente ha sufficienti privilegi in workspace, potresti enumerare tutti i gruppi e gli utenti con le seguenti righe.
Anche se dice identity groups, restituisce anche utenti senza alcun gruppo:
Negli esempi precedenti, il parametro --labels è richiesto, quindi viene utilizzato un valore generico (non è richiesto se si utilizza direttamente l'API come fa PurplePanda qui.
Anche con il servizio admin abilitato, è possibile che si verifichi un errore nell'enumerarli perché l'utente compromesso del tuo workspace non ha abbastanza permessi:
Controlla questo per informazioni di base su IAM.
Dai documenti: Quando viene creato una risorsa dell'organizzazione, a tutti gli utenti nel tuo dominio vengono concessi i ruoli di Creatore di Conto di Fatturazione e Creatore di Progetto per impostazione predefinita. Questi ruoli predefiniti consentono ai tuoi utenti di iniziare a utilizzare Google Cloud immediatamente, ma non sono destinati all'uso nell'operazione regolare della risorsa della tua organizzazione.
Questi ruoli concedono i permessi:
billing.accounts.create e resourcemanager.organizations.get
resourcemanager.organizations.get e resourcemanager.projects.create
Inoltre, quando un utente crea un progetto, gli viene automaticamente concesso il ruolo di proprietario di quel progetto secondo i documenti. Pertanto, per impostazione predefinita, un utente sarà in grado di creare un progetto e eseguire qualsiasi servizio su di esso (miner? enumerazione di Workspace? ...)
Il privilegio più alto in un'Organizzazione GCP è il ruolo di Amministratore dell'Organizzazione.
Nella maggior parte dei servizi sarai in grado di modificare i permessi su una risorsa utilizzando il metodo add-iam-policy-binding o set-iam-policy. La principale differenza è che add-iam-policy-binding aggiunge un nuovo binding di ruolo alla policy IAM esistente, mentre set-iam-policy elimina i permessi precedentemente concessi e imposta solo quelli indicati nel comando.
Ci sono diversi modi per controllare tutti i permessi di un utente in diverse risorse (come organizzazioni, cartelle, progetti...) utilizzando questo servizio.
Il permesso cloudasset.assets.searchAllIamPolicies può richiedere tutte le politiche iam all'interno di una risorsa.
Il permesso cloudasset.assets.analyzeIamPolicy può richiedere tutte le politiche iam di un principale all'interno di una risorsa.
Il permesso cloudasset.assets.searchAllResources consente di elencare tutte le risorse di un'organizzazione, cartella o progetto. Risorse relative a IAM (come i ruoli) incluse.
Il permesso cloudasset.assets.analyzeMove potrebbe essere utile anche per recuperare le politiche che influenzano una risorsa come un progetto.
Suppongo che il permesso cloudasset.assets.queryIamPolicy potrebbe anche dare accesso per trovare i permessi dei principali
Se non puoi accedere alle informazioni IAM utilizzando i metodi precedenti e sei in un Red Team. Potresti utilizzare lo strumento https://github.com/carlospolop/bf_my_gcp_perms per forzare le tue attuali autorizzazioni.
Tuttavia, nota che il servizio cloudresourcemanager.googleapis.com deve essere abilitato.
Nella pagina seguente puoi controllare come abuse IAM permissions to escalate privileges:
GCP - IAM PrivescSe hai privilegi elevati potresti:
Creare nuovi SAs (o utenti se in Workspace)
Dare ai principi controllati da te più autorizzazioni
Dare più privilegi a SAs vulnerabili (SSRF in vm, vuln Cloud Function…)
…
Per un'introduzione su cosa sono le Org Policies controlla:
GCP - Basic InformationLe politiche IAM indicano le autorizzazioni che i principi hanno sulle risorse tramite ruoli, che sono assegnati con autorizzazioni granulari. Le politiche di organizzazione limitano come quei servizi possono essere utilizzati o quali funzionalità sono disabilitate. Questo aiuta a migliorare il principio del minor privilegio per ciascuna risorsa nell'ambiente GCP.
Nella pagina seguente puoi controllare come abuse org policies permissions to escalate privileges:
GCP - Orgpolicy PrivescLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
