Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Basic Information

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

Altri modi per supportare HackTricks:

Gerarchia delle risorse

Google Cloud utilizza una Gerarchia delle risorse che è concettualmente simile a quella di un filesystem tradizionale. Questo fornisce un flusso logico genitore/figlio con punti di attacco specifici per le policy e le autorizzazioni.

A un livello elevato, appare così:

Organization
--> Folders
--> Projects
--> Resources

Un'istanza virtuale (chiamata un'istanza di calcolo) è una risorsa. Una risorsa risiede in un progetto, probabilmente insieme ad altre istanze di calcolo, bucket di archiviazione, ecc.

Migrazione dei Progetti

È possibile migrare un progetto senza alcuna organizzazione in un'organizzazione con i permessi roles/resourcemanager.projectCreator e roles/resourcemanager.projectMover. Se il progetto è all'interno di un'altra organizzazione, è necessario contattare il supporto GCP per spostarli fuori dall'organizzazione prima. Per ulteriori informazioni consulta questo.

Politiche dell'Organizzazione

Consentono di centralizzare il controllo sulle risorse cloud della tua organizzazione:

  • Centralizza il controllo per configurare restrizioni su come le risorse dell'organizzazione possono essere utilizzate.

  • Definire ed istituire vincoli per i team di sviluppo per rimanere entro i limiti della conformità.

  • Aiutare i proprietari dei progetti e i loro team a muoversi rapidamente senza preoccuparsi di violare la conformità.

Queste politiche possono essere create per influenzare l'intera organizzazione, cartelle o progetti. I discendenti del nodo gerarchico delle risorse mirate ereditano la politica dell'organizzazione.

Per definire una politica dell'organizzazione, si sceglie un vincolo, che è un particolare tipo di restrizione contro un servizio Google Cloud o un gruppo di servizi Google Cloud. Si configura quel vincolo con le restrizioni desiderate.

Casi d'uso comuni

  • Limitare la condivisione delle risorse in base al dominio.

  • Limitare l'uso degli account di servizio Identity and Access Management.

  • Limitare la posizione fisica delle risorse di nuova creazione.

  • Disabilitare la creazione di account di servizio.

Ci sono molti altri vincoli che ti danno un controllo dettagliato sulle risorse della tua organizzazione. Per ulteriori informazioni, consulta l' elenco di tutti i vincoli del servizio Politica dell'Organizzazione.

Politiche dell'Organizzazione Predefinite

Queste sono le politiche che Google aggiungerà per impostazione predefinita durante la configurazione dell'organizzazione GCP:

Politiche di Gestione degli Accessi

  • Contatti limitati dal dominio: Impedisce di aggiungere utenti ai Contatti Essenziali al di fuori dei domini specificati. Questo limita i Contatti Essenziali a consentire solo identità utente gestite nei domini selezionati a ricevere notifiche della piattaforma.

  • Condivisione limitata dal dominio: Impedisce di aggiungere utenti alle policy IAM al di fuori dei domini specificati. Questo limita le policy IAM a consentire solo identità utente gestite nei domini selezionati ad accedere alle risorse all'interno di questa organizzazione.

  • Prevenzione dell'accesso pubblico: Impedisce ai bucket di Cloud Storage di essere esposti al pubblico. Ciò garantisce che un sviluppatore non possa configurare i bucket di Cloud Storage per avere accesso a Internet non autenticato.

  • Accesso uniforme a livello di bucket: Impedisce i controlli degli accessi a livello di oggetto (ACL) nei bucket di Cloud Storage. Ciò semplifica la gestione degli accessi applicando in modo coerente le policy IAM su tutti gli oggetti nei bucket di Cloud Storage.

  • Richiedi l'accesso al sistema operativo: Le VM create in nuovi progetti avranno l'accesso al sistema operativo abilitato. Questo consente di gestire l'accesso SSH alle istanze utilizzando IAM senza la necessità di creare e gestire singole chiavi SSH.

Politiche di sicurezza aggiuntive per gli account di servizio

  • Disabilita i permessi IAM automatici: Impedisce che gli account di servizio predefiniti di App Engine e Compute Engine vengano automaticamente concessi il ruolo IAM Editor su un progetto alla creazione. Ciò garantisce che gli account di servizio non ricevano ruoli IAM eccessivamente permissivi alla creazione.

  • Disabilita la creazione di chiavi di account di servizio: Impedisce la creazione di chiavi di account di servizio pubbliche. Ciò aiuta a ridurre il rischio di esporre credenziali persistenti.

  • Disabilita il caricamento di chiavi di account di servizio: Impedisce il caricamento di chiavi di account di servizio pubbliche. Ciò aiuta a ridurre il rischio di materiale chiave esposto o riutilizzato.

Politiche di configurazione della rete VPC sicura

  • Definisci gli IP esterni consentiti per le istanze VM: Impedisce la creazione di istanze di calcolo con un IP pubblico, che potrebbe esporle al traffico Internet.

  • Disabilita la virtualizzazione nidificata delle VM: Impedisce la creazione di VM nidificate su VM di Compute Engine. Ciò riduce il rischio di sicurezza di avere VM nidificate non monitorate.

  • Disabilita la porta seriale VM: Impedisce l'accesso alla porta seriale delle VM di Compute Engine. Ciò impedisce l'input a una porta seriale del server utilizzando l'API di Compute Engine.

  • Limita le reti autorizzate sulle istanze Cloud SQL: Impedisce a intervalli di reti pubbliche o non interne di accedere ai database Cloud SQL.

  • Limita l'inoltro del protocollo in base al tipo di indirizzo IP: Impedisce l'inoltro del protocollo VM per gli indirizzi IP esterni.

  • Limita l'accesso IP pubblico alle istanze Cloud SQL: Impedisce la creazione di istanze Cloud SQL con un IP pubblico, che potrebbe esporle al traffico Internet.

  • Limita la rimozione del vincolo del progetto VPC condiviso: Impedisce l'eliminazione accidentale dei progetti host VPC condivisi.

  • Imposta l'impostazione DNS interno per i nuovi progetti su Zonal DNS Only: Impedisce l'uso di un'impostazione DNS legacy che riduce la disponibilità del servizio.

  • Salta la creazione predefinita della rete: Impedisce la creazione automatica della rete VPC predefinita e delle risorse correlate. Ciò evita regole del firewall predefinite eccessivamente permissive.

  • Disabilita l'uso di IPv6 esterno VPC: Impedisce la creazione di subnet IPv6 esterne, che potrebbero essere esposte all'accesso a Internet non autorizzato.

Ruoli IAM

Sono simili alle policy IAM in AWS poiché ogni ruolo contiene un insieme di permessi.

Tuttavia, a differenza di AWS, non esiste un repository centralizzato di ruoli. Invece, le risorse assegnano ruoli di accesso X a principali Y, e l'unico modo per scoprire chi ha accesso a una risorsa è utilizzare il metodo get-iam-policy su quella risorsa. Questo potrebbe essere un problema perché ciò significa che l'unico modo per scoprire quali permessi ha un principale è chiedere a ogni risorsa a chi sta concedendo i permessi, e un utente potrebbe non avere i permessi per ottenere i permessi da tutte le risorse.

Ci sono tre tipi di ruoli in IAM:

  • Ruoli di base/primitivi, che includono i ruoli Proprietario, Editore e Visualizzatore che esistevano prima dell'introduzione di IAM.

  • Ruoli predefiniti, che forniscono accesso granulare per un servizio specifico e sono gestiti da Google Cloud. Ci sono molti ruoli predefiniti, puoi vederli tutti con i privilegi che hanno qui.

  • Ruoli personalizzati, che forniscono accesso granulare in base a un elenco di permessi specificato dall'utente.

Ci sono migliaia di permessi in GCP. Per verificare se un ruolo ha un permesso puoi cercare il permesso qui e vedere quali ruoli lo hanno.

Puoi anche cercare qui i ruoli predefiniti offerti da ciascun prodotto. Nota che alcuni ruoli non possono essere assegnati agli utenti e solo agli SA a causa di alcuni permessi che contengono. Inoltre, nota che i permessi avranno effetto solo se sono assegnati al servizio rilevante.

Oppure verifica se un ruolo personalizzato può utilizzare un permesso specifico qui.

pageGCP - IAM, Principals & Org Policies Enum

Utenti

Nella console di GCP non vi è alcuna gestione degli Utenti o Gruppi, che viene gestita in Google Workspace. Tuttavia è possibile sincronizzare un diverso fornitore di identità in Google Workspace.

È possibile accedere agli utenti e gruppi di Workspace su https://admin.google.com.

L'MFA può essere impostato per gli utenti di Workspace, tuttavia, un attaccante potrebbe utilizzare un token per accedere a GCP tramite CLI senza protezione MFA (sarà protetto da MFA solo quando l'utente effettua l'accesso per generarlo: gcloud auth login).

Gruppi

Quando viene creata un'organizzazione, è fortemente consigliato creare diversi gruppi. Se gestisci uno di essi, potresti compromettere tutto o una parte importante dell'organizzazione:

Gruppo

Funzione

gcp-organization-admins (account gruppo o individuale richiesto per la checklist)

Amministrazione di qualsiasi risorsa che appartiene all'organizzazione. Assegna questo ruolo con parsimonia; gli amministratori dell'organizzazione hanno accesso a tutte le risorse di Google Cloud. In alternativa, poiché questa funzione è molto privilegiata, considera l'uso di account individuali anziché creare un gruppo.

gcp-network-admins (richiesto per la checklist)

Creazione di reti, subnet, regole del firewall e dispositivi di rete come Cloud Router, Cloud VPN e bilanciatori di carico cloud.

gcp-billing-admins (richiesto per la checklist)

Configurazione degli account di fatturazione e monitoraggio del loro utilizzo.

gcp-developers (richiesto per la checklist)

Progettazione, codifica e test di applicazioni.

gcp-security-admins

Stabilire e gestire le politiche di sicurezza per l'intera organizzazione, inclusa la gestione degli accessi e le politiche di vincolo dell'organizzazione. Consulta la guida alle fondamenta della sicurezza di Google Cloud per ulteriori informazioni sulla pianificazione dell'infrastruttura di sicurezza di Google Cloud.

gcp-devops

Creazione o gestione di pipeline end-to-end che supportano integrazione e distribuzione continue, monitoraggio e provisioning di sistemi.

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer (non più di default)

Monitoraggio delle spese nei progetti. I membri tipici fanno parte del team finanziario.

gcp-platform-viewer (non più di default)

Revisione delle informazioni sulle risorse in tutta l'organizzazione Google Cloud.

gcp-security-reviewer (non più di default)

Revisione della sicurezza cloud.

gcp-network-viewer (non più di default)

Revisione delle configurazioni di rete.

grp-gcp-audit-viewer (non più di default)

Visualizzazione dei log di audit.

gcp-scc-admin (non più di default)

Amministrazione del Security Command Center.

gcp-secrets-admin (non più di default)

Gestione dei segreti in Secret Manager.

Politica Password Predefinita

  • Imporre password sicure

  • Tra 8 e 100 caratteri

  • Nessun riutilizzo

  • Nessuna scadenza

  • Se le persone accedono a Workspace tramite un provider terzo, questi requisiti non vengono applicati.

Account di servizio

Questi sono i principali che le risorse possono avere associati e accedere per interagire facilmente con GCP. Ad esempio, è possibile accedere al token di autenticazione di un Account di Servizio associato a una VM nei metadati. È possibile incontrare alcuni conflitti quando si utilizzano sia IAM che access scopes. Ad esempio, il tuo account di servizio potrebbe avere il ruolo IAM di compute.instanceAdmin ma l'istanza che hai violato è stata limitata con la limitazione dello scope di https://www.googleapis.com/auth/compute.readonly. Ciò ti impedirebbe di apportare modifiche utilizzando il token OAuth assegnato automaticamente alla tua istanza.

È simile ai ruoli IAM di AWS. Ma a differenza di AWS, qualsiasi account di servizio può essere associato a qualsiasi servizio (non è necessario consentirlo tramite una policy).

Molti degli account di servizio che troverai sono effettivamente generati automaticamente da GCP quando inizi a utilizzare un servizio, come:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Tuttavia, è anche possibile creare e collegare alle risorse account di servizio personalizzati, che avranno questo aspetto:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Ambiti di accesso

Gli ambiti di accesso sono associati ai token OAuth generati per accedere ai punti di API di GCP. Essi limitano i permessi del token OAuth. Ciò significa che se un token appartiene a un Proprietario di una risorsa ma non ha nell'ambito del token l'accesso a quella risorsa, il token non può essere utilizzato per (ab)usare quei privilegi.

Google effettivamente raccomanda di non utilizzare gli ambiti di accesso e di fare affidamento totalmente su IAM. Il portale di gestione web effettivamente impone questo, ma gli ambiti di accesso possono comunque essere applicati alle istanze utilizzando account di servizio personalizzati in modo programmato.

È possibile vedere quali ambiti sono assegnati tramite interrogazione:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Gli ambiti precedenti sono quelli generati per impostazione predefinita utilizzando gcloud per accedere ai dati. Questo perché quando si utilizza gcloud si crea prima un token OAuth, e poi lo si utilizza per contattare i punti di contatto.

L'ambito più importante tra quelli potenzialmente disponibili è cloud-platform, che significa fondamentalmente che è possibile accedere a qualsiasi servizio in GCP.

È possibile trovare un elenco di tutti gli ambiti possibili qui.

Se si dispone di credenziali del browser gcloud, è possibile ottenere un token con altri ambiti, facendo qualcosa del genere:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Politiche IAM di Terraform, Associazioni e Appartenenze

Come definito da terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam utilizzando terraform con GCP ci sono diversi modi per concedere l'accesso a un principale su una risorsa:

  • Appartenenze: Imposti principali come membri di ruoli senza restrizioni sul ruolo o sui principali. Puoi mettere un utente come membro di un ruolo e poi mettere un gruppo come membro dello stesso ruolo e anche impostare quei principali (utente e gruppo) come membri di altri ruoli.

  • Associazioni: Diversi principali possono essere associati a un ruolo. Quei principali possono ancora essere associati o essere membri di altri ruoli. Tuttavia, se un principale che non è associato al ruolo viene impostato come membro di un ruolo associato, la prossima volta che viene applicata l'associazione, l'appartenenza scomparirà.

  • Politiche: Una politica è autoritativa, indica ruoli e principali e quindi, quei principali non possono avere più ruoli e quei ruoli non possono avere più principali a meno che quella politica non venga modificata (neanche in altre politiche, associazioni o appartenenze). Pertanto, quando un ruolo o principale è specificato nella politica tutti i suoi privilegi sono limitati da quella politica. Ovviamente, questo può essere aggirato nel caso in cui al principale venga data l'opzione di modificare la politica o i permessi di escalation dei privilegi (come creare un nuovo principale e associargli un nuovo ruolo).

Riferimenti

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

Altri modi per supportare HackTricks:

PreviousGCP PentestingNextGCP - Federation Abuse

Last updated