GCP - KMS Enum

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

KMS

The Cloud Key Management Service слугує безпечним сховищем для криптографічних ключів, які необхідні для операцій, таких як шифрування та дешифрування конфіденційних даних. Ці ключі організовані в key rings, що дозволяє впорядковано ними керувати. Крім того, контроль доступу можна тонко налаштувати як на рівні окремого ключа, так і для всього key ring, забезпечуючи точне відповідність прав вимогам безпеки.

KMS key rings за замовчуванням створюються як global, що означає, що ключі всередині такого key ring доступні з будь-якого регіону. Проте можна створювати key rings у конкретних регіонах.

Key Protection Level

  • Software keys: Software keys створюються та керуються KMS повністю в програмному забезпеченні. Ці ключі не захищені жодним hardware security module (HSM) і можуть використовуватись для тестування та розробки. Software keys не рекомендовані для production через низький рівень захисту та вразливість до атак.
  • Cloud-hosted keys: Cloud-hosted keys створюються та керуються KMS у хмарі з використанням високодоступної та надійної інфраструктури. Ці ключі захищені HSM, але HSM не виділені для конкретного клієнта. Cloud-hosted keys підходять для більшості production-випадків.
  • External keys: External keys створюються та керуються поза KMS, і імпортуються в KMS для використання у криптографічних операціях. External keys можуть зберігатися в hardware security module (HSM) або в програмній бібліотеці, залежно від уподобань клієнта.

Key Purposes

  • Symmetric encryption/decryption: Використовується для шифрування та дешифрування даних одним і тим же ключем для обох операцій. Симетричні ключі швидкі та ефективні для шифрування великих обсягів даних.
  • Supported: cryptoKeys.encrypt, cryptoKeys.decrypt
  • Asymmetric Signing: Використовується для безпечної комунікації між двома сторонами без обміну приватним ключем. Асиметричні ключі поставляються парою: публічний ключ і приватний ключ. Публічний ключ передається іншим, а приватний зберігається в секреті.
  • Supported: cryptoKeyVersions.asymmetricSign, cryptoKeyVersions.getPublicKey
  • Asymmetric Decryption: Використовується для перевірки автентичності повідомлення або даних. Цифровий підпис створюється приватним ключем і може бути перевірений відповідним публічним ключем.
  • Supported: cryptoKeyVersions.asymmetricDecrypt, cryptoKeyVersions.getPublicKey
  • MAC Signing: Використовується для забезпечення цілісності та автентичності даних шляхом створення message authentication code (MAC) за допомогою секретного ключа. HMAC часто застосовується для автентифікації повідомлень у мережевих протоколах та програмних додатках.
  • Supported: cryptoKeyVersions.macSign, cryptoKeyVersions.macVerify

Rotation Period & Programmed for destruction period

За замовчуванням — кожні 90 днів, але цей період можна легко і повністю настроїти.

Період “Programmed for destruction” — це час від того моменту, коли користувач запитує видалення ключа, до того моменту, коли ключ видаляється. Його неможливо змінити після створення ключа (за замовчуванням 1 день).

Primary Version

Кожен KMS ключ може мати декілька версій; одна з них має бути версією за замовчуванням — саме ця версія використовуватиметься, коли версія не вказана під час взаємодії з KMS key.

CMEK permission model

Коли об’єкти в Cloud Storage шифруються за допомогою CMEK, виклики decrypt/encrypt до KMS виконуються агентом сервісу Cloud Storage проекту (його email — service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com), а не безпосередньо кінцевим користувачем, який читає об’єкт.

Це означає, що для читання даних, зашифрованих CMEK:

  • агента сервісу Cloud Storage проекту має бути надано дозволи KMS на використаний KMS ключ (зазвичай roles/cloudkms.cryptoKeyEncrypterDecrypter);
  • користувачу достатньо мати права на читання об’єкта (наприклад, storage.objects.get). Він не потребує прав на сам KMS ключ.

Це означає, що для контролю доступу до зашифрованих даних через KMS ключ потрібно додавати/видаляти KMS дозволи для агента сервісу Cloud Storage проекту.

Зверніть увагу, що прив’язка на рівні проекту, наприклад roles/cloudkms.cryptoKeyEncrypterDecrypter для агента сервісу Storage, все одно дозволить дешифрування за допомогою ключів у тому ж проекті.

Enumeration

Маючи permissions to list the keys, ось як ви можете отримати до них доступ:

# 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

Підвищення привілеїв

GCP - KMS Privesc

Постексплуатація

GCP - KMS Post Exploitation

Посилання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks