GCP - KMS Enum

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

KMS

The Cloud Key Management Service funge da archivio sicuro per le chiavi crittografiche, essenziali per operazioni come cifratura e decifratura di dati sensibili. Queste chiavi sono organizzate all’interno di key rings, permettendo una gestione strutturata. Inoltre, il controllo degli accessi può essere configurato in modo dettagliato, sia a livello di singola key sia per l’intero key ring, garantendo che i permessi siano allineati ai requisiti di sicurezza.

KMS key rings are by default created as global, il che significa che le chiavi all’interno di quel key ring sono accessibili da qualsiasi regione. Tuttavia, è possibile creare key rings specifici in regioni specifiche.

Key Protection Level

  • Software keys: Le software keys sono create e gestite interamente da KMS in software. Queste chiavi non sono protette da alcun hardware security module (HSM) e possono essere usate per test e sviluppo. Le software keys non sono raccomandate per l’uso in produzione perchĂŠ offrono una sicurezza ridotta e sono suscettibili ad attacchi.
  • Cloud-hosted keys: Le cloud-hosted keys sono create e gestite da KMS nel cloud utilizzando un’infrastruttura altamente disponibile e affidabile. Queste chiavi sono protette da HSM, ma gli HSM non sono dedicati a un cliente specifico. Le cloud-hosted keys sono adatte per la maggior parte dei casi d’uso in produzione.
  • External keys: Le external keys sono create e gestite al di fuori di KMS, e vengono importate in KMS per l’uso nelle operazioni crittografiche. Le external keys possono essere memorizzate in un hardware security module (HSM) o in una libreria software, a seconda della preferenza del cliente.

Key Purposes

  • Symmetric encryption/decryption: Usato per cifrare e decifrare dati usando una singola chiave per entrambe le operazioni. Le symmetric keys sono veloci ed efficienti per cifrare e decifrare grandi volumi di dati.
  • Supported: cryptoKeys.encrypt, cryptoKeys.decrypt
  • Asymmetric Signing: Usato per comunicazioni sicure tra due parti senza condividere la chiave. Le asymmetric keys sono in coppia, composte da una chiave pubblica e una chiave privata. La chiave pubblica viene condivisa, mentre la chiave privata viene mantenuta segreta.
  • Supported: cryptoKeyVersions.asymmetricSign, cryptoKeyVersions.getPublicKey
  • Asymmetric Decryption: Usato per verificare l’autenticitĂ  di un messaggio o dato. Una firma digitale viene creata usando una chiave privata e può essere verificata con la corrispondente chiave pubblica.
  • Supported: cryptoKeyVersions.asymmetricDecrypt, cryptoKeyVersions.getPublicKey
  • MAC Signing: Usato per garantire l’integritĂ  e l’autenticitĂ  dei dati creando un message authentication code (MAC) usando una chiave segreta. HMAC è comunemente usato per l’autenticazione dei messaggi in protocolli di rete e applicazioni software.
  • Supported: cryptoKeyVersions.macSign, cryptoKeyVersions.macVerify

Rotation Period & Programmed for destruction period

Per default, ogni 90 giorni, ma può essere facilmente e completamente personalizzato.

Il periodo “Programmed for destruction” è il tempo che intercorre da quando l’utente richiede la cancellazione della key fino a quando la key è eliminata. Non può essere modificato dopo la creazione della key (default 1 giorno).

Primary Version

Ogni KMS key può avere diverse versioni; una di queste deve essere quella predefinita (default), che sarà quella utilizzata quando una versione non viene specificata durante l’interazione con la KMS key.

CMEK permission model

Quando gli oggetti in Cloud Storage sono crittografati con CMEK, le chiamate di decrypt/encrypt verso KMS sono effettuate dall’agent di servizio Cloud Storage del progetto, il cui indirizzo email è service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com, non direttamente dall’utente finale che legge l’oggetto.

Questo significa che per leggere qualcosa criptato con una CMEK:

  • L’agent di servizio Cloud Storage del progetto deve avere permessi KMS sulla KMS key usata (tipicamente roles/cloudkms.cryptoKeyEncrypterDecrypter).
  • L’utente ha bisogno solo dei permessi di lettura sull’oggetto (per esempio storage.objects.get). Non ha bisogno di permessi sulla KMS key.

Questo implica che per controllare l’accesso ai dati crittografati con la KMS key è necessario aggiungere/rimuovere i permessi KMS all’agent di servizio Cloud Storage del progetto.

Nota che un binding a livello di progetto come roles/cloudkms.cryptoKeyEncrypterDecrypter per lo Storage service agent consentirĂ  comunque la decryption con le chiavi nello stesso progetto.

Enumeration

Avere i permessi per elencare le chiavi — ecco come puoi accedervi:

# List the global keyrings available
gcloud kms keyrings list --location global
gcloud kms keyrings get-iam-policy <KEYRING>

# List the keys inside a keyring
gcloud kms keys list --keyring <KEYRING> --location <global/other_locations>
gcloud kms keys get-iam-policy <KEY>

# Encrypt a file using one of your keys
gcloud kms encrypt --ciphertext-file=[INFILE] \
--plaintext-file=[OUTFILE] \
--key [KEY] \
--keyring [KEYRING] \
--location global

# Decrypt a file using one of your keys
gcloud kms decrypt --ciphertext-file=[INFILE] \
--plaintext-file=[OUTFILE] \
--key [KEY] \
--keyring [KEYRING] \
--location global

Privilege Escalation

GCP - KMS Privesc

Post Exploitation

GCP - KMS Post Exploitation

Riferimenti

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks