GCP - KMS Enum

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

KMS

The Cloud Key Management Service sirve como un almacenamiento seguro para cryptographic keys, que son esenciales para operaciones como encrypting and decrypting sensitive data. Estas claves están organizadas dentro de key rings, lo que permite una gestión estructurada. Además, el control de acceso puede configurarse meticulosamente, ya sea a nivel de clave individual o para todo el key ring, asegurando que los permisos estén alineados con los requisitos de seguridad.

KMS key rings son por defecto creados como globales, lo que significa que las claves dentro de ese key ring son accesibles desde cualquier región. Sin embargo, es posible crear key rings específicos en regiones concretas.

Key Protection Level

  • Claves de software: Las claves de software son creadas y gestionadas por KMS completamente en software. Estas claves no están protegidas por ningún hardware security module (HSM) y pueden usarse para pruebas y desarrollo. No se recomiendan para uso en producción porque ofrecen baja seguridad y son susceptibles a ataques.
  • Cloud-hosted keys: Las cloud-hosted keys son creadas y gestionadas por KMS en la nube usando una infraestructura altamente disponible y fiable. Estas claves están protegidas por HSMs, pero los HSMs no están dedicados a un cliente específico. Las cloud-hosted keys son adecuadas para la mayoría de casos de uso en producción.
  • External keys: Las external keys son creadas y gestionadas fuera de KMS, e importadas a KMS para su uso en operaciones criptográficas. Las external keys pueden almacenarse en un hardware security module (HSM) o en una librería de software, según la preferencia del cliente.

Key Purposes

  • Symmetric encryption/decryption: Usadas para encrypt and decrypt data using a single key for both operations. Las symmetric keys son rápidas y eficientes para cifrar y descifrar grandes volúmenes de datos.
  • Supported: cryptoKeys.encrypt, cryptoKeys.decrypt
  • Asymmetric Signing: Usada para comunicación segura entre dos partes sin compartir la clave. Las asymmetric keys vienen en pares, consistiendo en una public key y una private key. La public key se comparte con otros, mientras que la private key se mantiene secreta.
  • Supported: cryptoKeyVersions.asymmetricSign, cryptoKeyVersions.getPublicKey
  • Asymmetric Decryption: Usada para verificar la autenticidad de un mensaje o dato. Una firma digital se crea usando una private key y puede verificarse usando la public key correspondiente.
  • Supported: cryptoKeyVersions.asymmetricDecrypt, cryptoKeyVersions.getPublicKey
  • MAC Signing: Usada para asegurar la integridad y autenticidad de los datos creando un message authentication code (MAC) usando una secret key. HMAC se usa comúnmente para la autenticación de mensajes en protocolos de red y aplicaciones de software.
  • Supported: cryptoKeyVersions.macSign, cryptoKeyVersions.macVerify

Rotation Period & Programmed for destruction period

Por defecto, cada 90 días, pero puede ser fácil y completamente personalizado.

El periodo “Programmed for destruction” es el tiempo desde que el usuario solicita eliminar la clave hasta que la clave es eliminada. No puede cambiarse después de crear la clave (por defecto 1 día).

Primary Version

Cada clave de KMS puede tener varias versiones; una de ellas debe ser la de defecto, que será la que se use cuando no se especifique una versión al interactuar con la clave KMS.

CMEK permission model

Cuando los objetos en Cloud Storage están cifrados con CMEK, las llamadas de decrypt/encrypt a KMS las realiza el Cloud Storage service agent del proyecto cuyo correo es service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com, no directamente el usuario final que lee el objeto.

Esto significa que para leer algo cifrado con un CMEK:

  • El cloud storage service agent del proyecto debe tener permisos de KMS sobre la clave KMS usada (típicamente roles/cloudkms.cryptoKeyEncrypterDecrypter).
  • El usuario solo necesita permisos de lectura del objeto (por ejemplo storage.objects.get). No necesita permisos sobre la clave KMS.

Esto quiere decir que para controlar el acceso a datos cifrados con la clave KMS es necesario añadir/eliminar permisos de KMS al cloud storage service agent del proyecto.

Ten en cuenta que un binding a nivel de proyecto como roles/cloudkms.cryptoKeyEncrypterDecrypter para el Storage service agent seguirá permitiendo el decrypt con las claves en el mismo proyecto.

Enumeración

Teniendo permisos para listar las claves, así es como puedes acceder a ellas:

# 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

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks