GCP - KMS Enumération

Tip

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

Soutenez HackTricks

KMS

The Cloud Key Management Service sert de stockage sécurisé pour les clés cryptographiques, qui sont essentielles pour des opérations telles que chiffrer et déchiffrer des données sensibles. Ces clés sont organisées au sein de key rings, permettant une gestion structurée. De plus, le contrôle d’accès peut être configuré de manière précise, soit au niveau d’une clé individuelle, soit pour l’ensemble du key ring, garantissant que les permissions sont parfaitement alignées avec les exigences de sécurité.

Les key rings KMS sont créés par défaut en tant que globaux, ce qui signifie que les clés à l’intérieur de ce key ring sont accessibles depuis n’importe quelle région. Cependant, il est possible de créer des key rings dans des régions spécifiques.

Key Protection Level

  • Software keys : Les software keys sont créées et gérées par KMS entièrement en logiciel. Ces clés ne sont pas protégées par un hardware security module (HSM) et peuvent être utilisées pour des tests et du développement. Les software keys ne sont pas recommandées pour la production car elles offrent une sécurité faible et sont susceptibles d’être attaquées.
  • Cloud-hosted keys : Les cloud-hosted keys sont créées et gérées par KMS dans le cloud en utilisant une infrastructure hautement disponible et fiable. Ces clés sont protégées par des HSM, mais les HSM ne sont pas dédiés à un client spécifique. Les cloud-hosted keys conviennent à la plupart des cas d’utilisation en production.
  • External keys : Les external keys sont créées et gérées en dehors de KMS, et sont importées dans KMS pour être utilisées dans des opérations cryptographiques. Les external keys peuvent être stockées dans un hardware security module (HSM) ou une bibliothèque logicielle, selon la préférence du client.

Key Purposes

  • Symmetric encryption/decryption : Utilisé pour chiffrer et déchiffrer des données en utilisant une seule clé pour les deux opérations. Les clés symétriques sont rapides et efficaces pour chiffrer et déchiffrer de grands volumes de données.
  • Supported : cryptoKeys.encrypt, cryptoKeys.decrypt
  • Asymmetric Signing : Utilisé pour une communication sécurisée entre deux parties sans partage de la clé. Les clés asymétriques viennent par paire, constituées d’une clé publique et d’une clé privée. La clé publique est partagée, tandis que la clé privée reste secrète.
  • Supported: cryptoKeyVersions.asymmetricSign, cryptoKeyVersions.getPublicKey
  • Asymmetric Decryption : Utilisé pour vérifier l’authenticité d’un message ou de données. Une signature numérique est créée à l’aide d’une clé privée et peut être vérifiée avec la clé publique correspondante.
  • Supported: cryptoKeyVersions.asymmetricDecrypt, cryptoKeyVersions.getPublicKey
  • MAC Signing : Utilisé pour garantir l’intégrité et l’authenticité des données en créant un message authentication code (MAC) à l’aide d’une clé secrète. HMAC est couramment utilisé pour l’authentification des messages dans les protocoles réseau et les applications logicielles.
  • Supported: cryptoKeyVersions.macSign, cryptoKeyVersions.macVerify

Rotation Period & Programmed for destruction period

Par défaut, tous les 90 jours, mais cela peut être facilement et entièrement personnalisé.

La période “Programmed for destruction” est le temps écoulé depuis la demande de suppression de la clé jusqu’à la suppression effective de la clé. Elle ne peut pas être modifiée après la création de la clé (valeur par défaut : 1 jour).

Primary Version

Chaque clé KMS peut avoir plusieurs versions ; l’une d’entre elles doit être la version par défaut, qui sera utilisée lorsqu’une version n’est pas spécifiée lors des interactions avec la clé KMS.

CMEK permission model

When objects in Cloud Storage are encrypted with CMEK, the decrypt/encrypt calls to KMS are done by the project’s Cloud Storage service agent whose email is service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com), not directly by the end user reading the object.

Cela signifie que, pour lire quelque chose chiffré par un CMEK :

  • L’agent de service Cloud Storage du projet doit avoir des permissions KMS sur la clé KMS utilisée (typiquement roles/cloudkms.cryptoKeyEncrypterDecrypter).
  • L’utilisateur n’a besoin que des permissions de lecture d’objet (par exemple storage.objects.get). Il n’a pas besoin de permissions sur la clé KMS.

Cela signifie que pour contrôler l’accès aux données chiffrées avec la clé KMS, il est nécessaire d’ajouter/supprimer des permissions KMS à l’agent de service Cloud Storage du projet.

Notez qu’un binding au niveau du projet comme roles/cloudkms.cryptoKeyEncrypterDecrypter pour l’agent de service Storage permettra toujours le déchiffrement avec les clés du même projet.

Enumeration

Having permissions to list the keys this is how you can access them:

# 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

Escalade de privilèges

GCP - KMS Privesc

Post-exploitation

GCP - KMS Post Exploitation

Références

Tip

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

Soutenez HackTricks