Translated ['', 'src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-

2026-03-12 21:22:57 -07:00 · 2026-03-04 11:27:12 +00:00
parent 784378e3d9
commit 318fb1173b
2 changed files with 64 additions and 37 deletions
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md
@@ -1,4 +1,4 @@
-# GCP - KMS Post Exploitation
+# GCP - KMS Post-eksploatacja

 {{#include ../../../banners/hacktricks-training.md}}

@@ -12,7 +12,7 @@ Znajdź podstawowe informacje o KMS w:

 ### `cloudkms.cryptoKeyVersions.destroy`

-An attacker z tym uprawnieniem mógłby zniszczyć wersję KMS. Aby to zrobić najpierw musisz wyłączyć klucz, a następnie go zniszczyć:
+Atakujący posiadający to uprawnienie może zniszczyć wersję KMS. Aby to zrobić, najpierw musisz wyłączyć klucz, a następnie go zniszczyć:

 <details>

@@ -65,24 +65,38 @@ destroy_key_version(project_id, location_id, key_ring_id, key_id, key_version)

 ### KMS Ransomware

-W AWS można całkowicie **ukraść klucz KMS** przez modyfikację polityki zasobów KMS i umożliwienie użycia klucza wyłącznie kontu atakującego. Ponieważ takie polityki zasobów nie istnieją w GCP, nie jest to możliwe.
+W AWS można całkowicie **steal a KMS key** poprzez modyfikację KMS resource policy i zezwolenie jedynie kontu atakującego na użycie klucza. Ponieważ te resource policies nie istnieją w GCP, nie jest to możliwe.

 Jednak istnieje inny sposób przeprowadzenia globalnego KMS Ransomware, który obejmowałby następujące kroki:

- Utworzyć nową **wersję klucza z materiałem klucza** zaimportowanym przez atakującego
+- Utworzyć nową **version of the key with a key material** zaimportowaną przez atakującego
 ```bash
 gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
 ```
 - Ustaw ją jako **domyślną wersję** (dla przyszłych danych, które będą szyfrowane)
- **Ponownie zaszyfruj starsze dane**, zaszyfrowane poprzednią wersją, przy użyciu nowej wersji.
+- **Ponownie zaszyfruj starsze dane** zaszyfrowane poprzednią wersją nową wersją.
 - **Usuń klucz KMS**
- Teraz tylko atakujący, który posiada oryginalny materiał klucza, będzie w stanie odszyfrować zaszyfrowane dane
+- Teraz tylko atakujący, który posiada oryginalny materiał klucza, będzie mógł odszyfrować zaszyfrowane dane

-#### Oto kroki, aby zaimportować nową wersję i wyłączyć/usuń starsze dane:
+#### Cloud Storage + CMEK model uprawnień
+
+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.
+
+This means that to read something encrypted by a CMEK:
+
+- Agent usługi Cloud Storage projektu musi mieć uprawnienia KMS do używanego klucza KMS (zazwyczaj `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 zaszyfrowanych danych za pomocą klucza KMS, trzeba dodać/usunąć uprawnienia KMS dla agenta usługi Cloud Storage projektu.
+
+Note that there is a project-level binding like `roles/cloudkms.cryptoKeyEncrypterDecrypter` for the Storage service agent will still allow decrypt with the keys in the same project.
+
+
+#### Oto kroki, aby zaimportować nową wersję i wyłączyć/usunąć starsze dane:

 <details>

-<summary>Zaimportuj nową wersję klucza i usuń starą wersję</summary>
+<summary>Importuj nową wersję klucza i usuń starą wersję</summary>
 ```bash
 # Encrypt something with the original key
 echo "This is a sample text to encrypt" > /tmp/my-plaintext-file.txt
@@ -162,7 +176,7 @@ gcloud kms keys versions destroy \

 <details>

-<summary>Szyfruj dane kluczem symetrycznym (Python)</summary>
+<summary>Szyfrowanie danych przy użyciu klucza symetrycznego (Python)</summary>
 ```python
 from google.cloud import kms
 import base64
@@ -243,7 +257,7 @@ print('Signature:', signature)

 <details>

-<summary>Zweryfikuj podpis przy użyciu klucza asymetrycznego (Python)</summary>
+<summary>Weryfikacja podpisu za pomocą klucza asymetrycznego (Python)</summary>
 ```python
 from google.cloud import kms
 import hashlib
@@ -271,7 +285,7 @@ verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key
 print('Verified:', verified)
 ```
 ### `cloudkms.cryptoKeyVersions.restore`
-Uprawnienie `cloudkms.cryptoKeyVersions.restore` pozwala tożsamości na przywrócenie wersji klucza, która została wcześniej zaplanowana do zniszczenia lub wyłączona w Cloud KMS, przywracając ją do stanu aktywnego i używalnego.
+Uprawnienie `cloudkms.cryptoKeyVersions.restore` umożliwia tożsamości przywrócenie wersji klucza, która była wcześniej zaplanowana do zniszczenia lub wyłączona w Cloud KMS, przywracając ją do stanu aktywnego i użytecznego.
 ```bash
 gcloud kms keys versions restore <VERSION_ID> \
 --key=<KEY_NAME> \
@@ -280,7 +294,7 @@ gcloud kms keys versions restore <VERSION_ID> \
 --project=<PROJECT_ID>
 ```
 ### `cloudkms.cryptoKeyVersions.update`
-Uprawnienie `cloudkms.cryptoKeyVersions.update` pozwala tożsamości modyfikować atrybuty lub stan konkretnej wersji klucza w Cloud KMS, na przykład włączając lub wyłączając ją.
+Uprawnienie `cloudkms.cryptoKeyVersions.update` pozwala tożsamości modyfikować atrybuty lub stan konkretnej wersji klucza w Cloud KMS, na przykład poprzez jej włączenie lub wyłączenie.
 ```bash
 # Disable key
 gcloud kms keys versions disable <VERSION_ID> \
--- a/src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md
+++ b/src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md
@@ -4,40 +4,53 @@

 ## KMS

-[**Cloud Key Management Service**](https://cloud.google.com/kms/docs/) służy jako bezpieczne miejsce do przechowywania **kluczy kryptograficznych**, które są niezbędne do operacji takich jak **szyfrowanie i deszyfrowanie wrażliwych danych**. Klucze te są zorganizowane w obręby kluczy, co umożliwia strukturalne zarządzanie. Ponadto, kontrola dostępu może być starannie skonfigurowana, zarówno na poziomie pojedynczego klucza, jak i dla całego obrębu kluczy, zapewniając, że uprawnienia są precyzyjnie dostosowane do wymagań bezpieczeństwa.
+The [**Cloud Key Management Service**](https://cloud.google.com/kms/docs/) 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.

-Obręby kluczy KMS są domyślnie tworzone jako globalne, co oznacza, że klucze wewnątrz tego obrębu są dostępne z dowolnego regionu. Możliwe jest jednak tworzenie specyficznych obrębów kluczy w **konkretnych regionach**.
+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**.

-### Poziom ochrony kluczy
+### Key Protection Level

- **Klucze programowe**: Klucze programowe są **tworzone i zarządzane przez KMS całkowicie w oprogramowaniu**. Klucze te **nie są chronione przez żaden moduł bezpieczeństwa sprzętowego (HSM)** i mogą być używane do **testowania i celów rozwojowych**. Klucze programowe **nie są zalecane do użytku produkcyjnego**, ponieważ zapewniają niskie bezpieczeństwo i są podatne na ataki.
- **Klucze hostowane w chmurze**: Klucze hostowane w chmurze są **tworzone i zarządzane przez KMS** w chmurze przy użyciu wysoko dostępnej i niezawodnej infrastruktury. Klucze te są **chronione przez HSM**, ale HSM **nie są dedykowane dla konkretnego klienta**. Klucze hostowane w chmurze są odpowiednie dla większości przypadków użycia w produkcji.
- **Klucze zewnętrzne**: Klucze zewnętrzne są **tworzone i zarządzane poza KMS** i są importowane do KMS do użycia w operacjach kryptograficznych. Klucze zewnętrzne **mogą być przechowywane w module bezpieczeństwa sprzętowego (HSM) lub w bibliotece oprogramowania, w zależności od preferencji klienta**.
+- **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**.

-### Cele kluczy
+### Key Purposes

- **Szyfrowanie/deszyfrowanie symetryczne**: Używane do **szyfrowania i deszyfrowania danych za pomocą jednego klucza dla obu operacji**. Klucze symetryczne są szybkie i efektywne w szyfrowaniu i deszyfrowaniu dużych ilości danych.
- **Obsługiwane**: [cryptoKeys.encrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/encrypt), [cryptoKeys.decrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/decrypt)
- **Podpisywanie asymetryczne**: Używane do bezpiecznej komunikacji między dwiema stronami bez dzielenia się kluczem. Klucze asymetryczne występują w parze, składającej się z **klucza publicznego i klucza prywatnego**. Klucz publiczny jest udostępniany innym, podczas gdy klucz prywatny jest zachowywany w tajemnicy.
- **Obsługiwane:** [cryptoKeyVersions.asymmetricSign](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricSign), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey)
- **Deszyfrowanie asymetryczne**: Używane do weryfikacji autentyczności wiadomości lub danych. Podpis cyfrowy jest tworzony za pomocą klucza prywatnego i może być weryfikowany za pomocą odpowiadającego klucza publicznego.
- **Obsługiwane:** [cryptoKeyVersions.asymmetricDecrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricDecrypt), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey)
- **Podpisywanie MAC**: Używane do zapewnienia **integralności i autentyczności danych poprzez tworzenie kodu uwierzytelniającego wiadomość (MAC) za pomocą klucza tajnego**. HMAC jest powszechnie używane do uwierzytelniania wiadomości w protokołach sieciowych i aplikacjach oprogramowania.
- **Obsługiwane:** [cryptoKeyVersions.macSign](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macSign), [cryptoKeyVersions.macVerify](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macVerify)
+- **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](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/encrypt), [cryptoKeys.decrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.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](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricSign), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.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](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricDecrypt), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.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](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macSign), [cryptoKeyVersions.macVerify](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macVerify)

-### Okres rotacji i okres zaplanowany do zniszczenia
+### Rotation Period & Programmed for destruction period

-Domyślnie każdy **90 dni**, ale może być **łatwo** i **całkowicie dostosowany.**
+Domyślnie okres rotacji wynosi **90 dni**, ale można go **łatwo** i **całkowicie** dostosować.

-Okres "zaplanowany do zniszczenia" to **czas od momentu, gdy użytkownik poprosi o usunięcie klucza**, aż do momentu, gdy klucz zostanie **usunięty**. Nie można go zmienić po utworzeniu klucza (domyślnie 1 dzień).
+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ń).

-### Wersja główna
+### Primary Version

-Każdy klucz KMS może mieć kilka wersji, jedna z nich musi być **domyślną**, która będzie używana, gdy **wersja nie jest określona podczas interakcji z kluczem KMS**.
+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.

-### Enumeracja
+### CMEK permission model

-Mając **uprawnienia do wylistowania kluczy**, oto jak możesz uzyskać do nich dostęp:
+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:
 ```bash
 # List the global keyrings available
 gcloud kms keyrings list --location global
@@ -61,19 +74,19 @@ gcloud kms decrypt --ciphertext-file=[INFILE] \
 --keyring [KEYRING] \
 --location global
 ```
-### Eskalacja Uprawnień
+### Privilege Escalation

 {{#ref}}
 ../gcp-privilege-escalation/gcp-kms-privesc.md
 {{#endref}}

-### Po Eksploatacji
+### Post Exploitation

 {{#ref}}
 ../gcp-post-exploitation/gcp-kms-post-exploitation.md
 {{#endref}}

-## Odniesienia
+## Źródła

 - [https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/#reviewing-stackdriver-logging](https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/#reviewing-stackdriver-logging)