GCP - KMS Enum

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

KMS

The Cloud Key Management Service służy jako bezpieczne repozytorium dla cryptographic keys, które są niezbędne do operacji takich jak encrypting and decrypting sensitive data. Klucze te są zorganizowane w key rings, co pozwala na uporządkowane zarządzanie. Dodatkowo kontrola dostępu może być precyzyjnie skonfigurowana, zarówno na poziomie pojedynczego klucza, jak i całego key ring, zapewniając, że uprawnienia są dokładnie dopasowane do wymagań bezpieczeństwa.

KMS key rings są domyślnie tworzone jako globalne, co oznacza, że klucze wewnątrz takiego key ring są dostępne z dowolnego regionu. Jednak możliwe jest tworzenie konkretnych key rings w określonych regionach.

Key Protection Level

  • Software keys: Klucze programowe są tworzone i zarządzane przez KMS całkowicie w oprogramowaniu. Te klucze nie są chronione przez żaden hardware security module (HSM) i mogą być używane do testów i celów deweloperskich. Klucze programowe nie są zalecane do użytku produkcyjnego, ponieważ zapewniają niższy poziom bezpieczeństwa i są podatne na ataki.
  • Cloud-hosted keys: Klucze hostowane w chmurze są tworzone i zarządzane przez KMS w chmurze z wykorzystaniem wysoko dostępnej i niezawodnej infrastruktury. Te klucze są chronione przez HSMy, ale HSMy nie są dedykowane dla konkretnego klienta. Klucze hostowane w chmurze są odpowiednie dla większości zastosowań produkcyjnych.
  • External keys: Klucze zewnętrzne są tworzone i zarządzane poza KMS, a następnie importowane do KMS w celu użycia w operacjach kryptograficznych. Klucze zewnętrzne mogą być przechowywane w hardware security module (HSM) lub w bibliotece programowej, w zależności od preferencji klienta.

Key Purposes

  • Symmetric encryption/decryption: Używane do szyfrowania i odszyfrowywania danych przy użyciu jednego klucza do obu operacji. Klucze symetryczne są szybkie i wydajne przy szyfrowaniu i odszyfrowywaniu dużych ilości danych.
  • Supported: cryptoKeys.encrypt, cryptoKeys.decrypt
  • Asymmetric Signing: Używane do bezpiecznej komunikacji między dwiema stronami bez udostępniania klucza. Klucze asymetryczne występują w parach, składających się z klucza publicznego i prywatnego. Klucz publiczny jest udostępniany innym, natomiast klucz prywatny jest utrzymywany w tajemnicy.
  • Supported: cryptoKeyVersions.asymmetricSign, cryptoKeyVersions.getPublicKey
  • Asymmetric Decryption: Używane do weryfikacji autentyczności wiadomości lub danych. Podpis cyfrowy jest tworzony przy użyciu klucza prywatnego i może być zweryfikowany przy użyciu odpowiadającego klucza publicznego.
  • Supported: cryptoKeyVersions.asymmetricDecrypt, cryptoKeyVersions.getPublicKey
  • MAC Signing: Używane do zapewnienia integralności i autentyczności danych poprzez tworzenie message authentication code (MAC) za pomocą tajnego klucza. HMAC jest powszechnie stosowany do uwierzytelniania wiadomości w protokołach sieciowych i aplikacjach.
  • Supported: cryptoKeyVersions.macSign, cryptoKeyVersions.macVerify

Rotation Period & Programmed for destruction period

Domyślnie okres rotacji wynosi 90 dni, ale można go łatwo i całkowicie dostosować.

Okres “Programmed for destruction” to czas od momentu, gdy użytkownik zażądał usunięcia klucza, do momentu faktycznego usunięcia klucza. Nie można go zmienić po utworzeniu klucza (domyślnie 1 dzień).

Primary Version

Każdy klucz KMS może mieć kilka wersji; jedna z nich musi być wersją domyślną — to ona będzie używana, gdy wersja nie jest określona podczas operacji na kluczu KMS.

CMEK permission model

Gdy obiekty w Cloud Storage są zaszyfrowane za pomocą CMEK, wywołania decrypt/encrypt do KMS są wykonywane przez projektowego Cloud Storage service agent (jego e-mail to service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com), a nie bezpośrednio przez końcowego użytkownika czytającego obiekt.

Oznacza to, że aby odczytać coś zaszyfrowanego przy użyciu CMEK:

  • Projektowy cloud storage service agent musi mieć uprawnienia KMS do używanego klucza KMS (zwykle roles/cloudkms.cryptoKeyEncrypterDecrypter).
  • Użytkownik potrzebuje tylko uprawnień do odczytu obiektu (np. storage.objects.get). Nie potrzebuje uprawnień do klucza KMS.

To oznacza, że aby kontrolować dostęp do danych zaszyfrowanych przy użyciu klucza KMS, trzeba dodać/usunąć uprawnienia KMS dla agenta usługi Cloud Storage projektu.

Zauważ, że wiązanie na poziomie projektu takie jak roles/cloudkms.cryptoKeyEncrypterDecrypter dla agenta usługi Storage nadal pozwoli na odszyfrowanie kluczy w tym samym projekcie.

Enumeration

Mając permissions to list the keys, oto jak możesz uzyskać do nich dostęp:

# 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

Źródła

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks