Translated ['', 'src/pentesting-cloud/gcp-security/gcp-post-exploitation

2026-03-12 21:22:57 -07:00 · 2026-03-04 11:27:11 +00:00
parent 605c04b425
commit eb52555276
2 changed files with 61 additions and 34 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 Exploitation

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

@@ -12,7 +12,7 @@ Grundlegende Informationen zu KMS finden Sie in:

 ### `cloudkms.cryptoKeyVersions.destroy`

-Ein Angreifer mit dieser Berechtigung könnte eine KMS-Version zerstören. Um dies zu tun, müssen Sie zuerst den Schlüssel deaktivieren und ihn dann zerstören:
+Ein Angreifer mit dieser Berechtigung könnte eine KMS-Version zerstören. Dazu müssen Sie zuerst den Schlüssel deaktivieren und ihn dann zerstören:

 <details>

@@ -67,18 +67,32 @@ destroy_key_version(project_id, location_id, key_ring_id, key_id, key_version)

 In AWS ist es möglich, vollständig **steal a KMS key** zu erreichen, indem man die KMS resource policy ändert und nur dem attackers account erlaubt, den Schlüssel zu verwenden. Da diese resource policies in GCP nicht existieren, ist das nicht möglich.

-Es gibt jedoch einen anderen Weg, ein globales KMS Ransomware durchzuführen, der die folgenden Schritte umfassen würde:
+Es gibt jedoch eine andere Möglichkeit, globales KMS Ransomware durchzuführen, die die folgenden Schritte umfassen würde:

 - Erstelle eine neue **version of the key with a key material** imported by the attacker
 ```bash
 gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
 ```
- Setze es als **Standardversion** (für zukünftig verschlüsselte Daten)
- **Ältere Daten erneut verschlüsseln**, die mit der vorherigen Version verschlüsselt wurden, mit der neuen Version.
- **Lösche den KMS-Schlüssel**
- Nun könnte nur noch der attacker, der das ursprüngliche Schlüsselmaterial besitzt, die verschlüsselten Daten entschlüsseln
+- Setze es als **Standardversion** (für zukünftige zu verschlüsselnde Daten)
+- **Ältere Daten mit der neuen Version neu verschlüsseln**
+- **Den KMS-Schlüssel löschen**
+- Nun könnte nur noch der Angreifer, der das ursprüngliche Schlüsselmaterial besitzt, in der Lage sein, die verschlüsselten Daten zu entschlüsseln

-#### Hier sind die Schritte, um eine neue Version zu importieren und die älteren Daten zu deaktivieren/löschen:
+#### Cloud Storage + CMEK Berechtigungsmodell
+
+Wenn Objekte in Cloud Storage mit CMEK verschlüsselt sind, werden die Decrypt/Encrypt-Aufrufe an KMS vom Projekt-**Cloud Storage service agent whose email is service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com)** ausgeführt, nicht direkt vom Endbenutzer, der das Objekt liest.
+
+Das bedeutet, dass man, um etwas zu lesen, das mit CMEK verschlüsselt wurde:
+
+- Der cloud storage service agent des Projekts muss KMS-Berechtigungen für den verwendeten KMS-Schlüssel haben (typischerweise `roles/cloudkms.cryptoKeyEncrypterDecrypter`).
+- Der Benutzer benötigt nur Objekt-Lese-Berechtigungen (z. B. `storage.objects.get`). Er benötigt keine Berechtigungen für den KMS-Schlüssel.
+
+Das bedeutet, dass zur Kontrolle des Zugriffs auf verschlüsselte Daten mit dem KMS-Schlüssel KMS-Berechtigungen für den cloud storage service agent des Projekts hinzugefügt/entfernt werden müssen.
+
+Beachte, dass eine projektweite Bindung wie `roles/cloudkms.cryptoKeyEncrypterDecrypter` für den Storage service agent weiterhin das Entschlüsseln mit Schlüsseln im selben Projekt ermöglicht.
+
+
+#### Hier sind die Schritte, um eine neue Version zu importieren und ältere Daten zu deaktivieren/löschen:

 <details>

@@ -271,7 +285,7 @@ verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key
 print('Verified:', verified)
 ```
 ### `cloudkms.cryptoKeyVersions.restore`
-Die Berechtigung `cloudkms.cryptoKeyVersions.restore` erlaubt einer Identität, eine zuvor zur Zerstörung vorgemerkte oder in Cloud KMS deaktivierte Schlüsselversion wiederherzustellen und in einen aktiven, nutzbaren Zustand zurückzuführen.
+Die `cloudkms.cryptoKeyVersions.restore`-Berechtigung erlaubt einer Identität, eine Schlüsselversion wiederherzustellen, die zuvor zur Zerstörung geplant oder in Cloud KMS deaktiviert wurde, und sie in einen aktiven und nutzbaren Zustand zurückzuversetzen.
 ```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`
-Die `cloudkms.cryptoKeyVersions.update`-Berechtigung erlaubt einer Identität, die Attribute oder den Zustand einer bestimmten Schlüsselversion in Cloud KMS zu ändern, zum Beispiel indem sie diese aktiviert oder deaktiviert.
+Die `cloudkms.cryptoKeyVersions.update`-Berechtigung erlaubt einer Identität, die Attribute oder den Zustand einer bestimmten Schlüsselversion in Cloud KMS zu ändern, z. B. durch Aktivieren oder Deaktivieren.
 ```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

-Der [**Cloud Key Management Service**](https://cloud.google.com/kms/docs/) dient als sichere Speicherung für **kryptografische Schlüssel**, die für Operationen wie **Verschlüsselung und Entschlüsselung sensibler Daten** unerlässlich sind. Diese Schlüssel sind in Schlüsselringen organisiert, was eine strukturierte Verwaltung ermöglicht. Darüber hinaus kann die Zugriffskontrolle sorgfältig konfiguriert werden, entweder auf der Ebene des einzelnen Schlüssels oder für den gesamten Schlüsselring, um sicherzustellen, dass die Berechtigungen genau mit den Sicherheitsanforderungen übereinstimmen.
+Die [**Cloud Key Management Service**](https://cloud.google.com/kms/docs/) dient als sicherer Speicher für **kryptografische Schlüssel**, die für Vorgänge wie das **Verschlüsseln und Entschlüsseln sensibler Daten** notwendig sind. Diese Schlüssel sind innerhalb von key rings organisiert, was ein strukturiertes Management ermöglicht. Außerdem kann die Zugriffskontrolle präzise konfiguriert werden, entweder auf einzelner Schlüssel-Ebene oder für den gesamten key ring, sodass Berechtigungen genau den Sicherheitsanforderungen entsprechen.

-KMS-Schlüsselringe werden standardmäßig als **global** erstellt, was bedeutet, dass die Schlüssel innerhalb dieses Schlüsselrings aus jeder Region zugänglich sind. Es ist jedoch möglich, spezifische Schlüsselringe in **spezifischen Regionen** zu erstellen.
+KMS key rings werden standardmäßig als **global** erstellt, das bedeutet, dass die Schlüssel innerhalb dieses key rings aus jeder Region zugänglich sind. Es ist jedoch möglich, bestimmte key rings in **bestimmten Regionen** zu erstellen.

-### Schlüssel-Schutzstufe
+### Key Protection Level

- **Software-Schlüssel**: Software-Schlüssel werden **vollständig in Software von KMS erstellt und verwaltet**. Diese Schlüssel sind **nicht durch ein Hardware-Sicherheitsmodul (HSM)** geschützt und können für **Test- und Entwicklungszwecke** verwendet werden. Software-Schlüssel werden **nicht für die Produktion** empfohlen, da sie eine geringe Sicherheit bieten und anfällig für Angriffe sind.
- **Cloud-gehostete Schlüssel**: Cloud-gehostete Schlüssel werden **in der Cloud von KMS** unter Verwendung einer hochverfügbaren und zuverlässigen Infrastruktur erstellt und verwaltet. Diese Schlüssel sind **durch HSMs geschützt**, aber die HSMs sind **nicht einem bestimmten Kunden zugeordnet**. Cloud-gehostete Schlüssel sind für die meisten Produktionsanwendungen geeignet.
- **Externe Schlüssel**: Externe Schlüssel werden **außerhalb von KMS erstellt und verwaltet** und in KMS importiert, um in kryptografischen Operationen verwendet zu werden. Externe Schlüssel **können in einem Hardware-Sicherheitsmodul (HSM) oder einer Softwarebibliothek gespeichert werden, je nach den Vorlieben des Kunden**.
+- **Software keys**: Software keys werden **vollständig von KMS in Software erstellt und verwaltet**. Diese Schlüssel sind **nicht durch ein hardware security module (HSM)** geschützt und können für **Test- und Entwicklungszwecke** verwendet werden. Software keys werden **nicht für den Produktionseinsatz empfohlen**, da sie nur geringe Sicherheit bieten und anfällig für Angriffe sind.
+- **Cloud-hosted keys**: Cloud-hosted keys werden **von KMS in der Cloud erstellt und verwaltet** und nutzen eine hochverfügbare und zuverlässige Infrastruktur. Diese Schlüssel sind **durch HSMs geschützt**, allerdings sind die HSMs **nicht exklusiv für einen bestimmten Kunden reserviert**. Cloud-hosted keys sind für die meisten Produktionsanwendungen geeignet.
+- **External keys**: External keys werden **außerhalb von KMS erstellt und verwaltet** und in KMS für kryptografische Operationen importiert. External keys **können je nach Präferenz des Kunden in einem hardware security module (HSM) oder einer Softwarebibliothek gespeichert werden**.

-### Schlüsselzwecke
+### Key Purposes

- **Symmetrische Verschlüsselung/Entschlüsselung**: Wird verwendet, um **Daten mit einem einzigen Schlüssel für beide Operationen zu verschlüsseln und zu entschlüsseln**. Symmetrische Schlüssel sind schnell und effizient für die Verschlüsselung und Entschlüsselung großer Datenmengen.
- **Unterstützt**: [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)
- **Asymmetrische Signatur**: Wird für die sichere Kommunikation zwischen zwei Parteien verwendet, ohne den Schlüssel zu teilen. Asymmetrische Schlüssel kommen in einem Paar, bestehend aus einem **öffentlichen Schlüssel und einem privaten Schlüssel**. Der öffentliche Schlüssel wird mit anderen geteilt, während der private Schlüssel geheim gehalten wird.
- **Unterstützt:** [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)
- **Asymmetrische Entschlüsselung**: Wird verwendet, um die Authentizität einer Nachricht oder Daten zu überprüfen. Eine digitale Signatur wird mit einem privaten Schlüssel erstellt und kann mit dem entsprechenden öffentlichen Schlüssel verifiziert werden.
- **Unterstützt:** [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-Signatur**: Wird verwendet, um **Datenintegrität und Authentizität zu gewährleisten, indem ein Nachrichten-Authentifizierungscode (MAC) mit einem geheimen Schlüssel erstellt wird**. HMAC wird häufig für die Nachrichtenauthentifizierung in Netzwerkprotokollen und Softwareanwendungen verwendet.
- **Unterstützt:** [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**: Wird verwendet, um **Daten mit demselben Schlüssel für Verschlüsselung und Entschlüsselung** zu ver- bzw. entschlüsseln. Symmetric keys sind schnell und effizient beim Ver- und Entschlüsseln großer Datenmengen.
+- **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**: Wird für sichere Kommunikation zwischen zwei Parteien verwendet, ohne den privaten Schlüssel zu teilen. Asymmetric keys kommen paarweise vor — aus einem **public key und einem private key**. Der public key wird geteilt, der private key bleibt geheim.
+- **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**: Dient dazu, die Authentizität einer Nachricht oder von Daten zu überprüfen. Eine digitale Signatur wird mit einem private key erstellt und kann mit dem entsprechenden public key verifiziert werden.
+- **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**: Dient dazu, **Datenintegrität und Authentizität sicherzustellen, indem ein Message Authentication Code (MAC) mit einem geheimen Schlüssel erstellt wird**. HMAC wird häufig für Message-Authentifizierung in Netzwerkprotokollen und Softwareanwendungen verwendet.
+- **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)

-### Rotationszeitraum & Programmierte Zerstörungszeit
+### Rotation Period & Programmed for destruction period

-Standardmäßig **alle 90 Tage**, kann jedoch **einfach** und **vollständig angepasst** werden.
+Standardmäßig beträgt die Rotation **alle 90 Tage**, sie kann jedoch **einfach** und **vollständig angepasst** werden.

-Der Zeitraum "Programmiert zur Zerstörung" ist die **Zeit, seit der der Benutzer die Löschung des Schlüssels angefordert hat**, bis der Schlüssel **gelöscht** wird. Er kann nach der Erstellung des Schlüssels nicht mehr geändert werden (Standard 1 Tag).
+Der "Programmed for destruction"-Zeitraum ist die **Zeitspanne seit der Anfrage des Benutzers, den Schlüssel zu löschen**, bis der Schlüssel **gelöscht** wird. Dieser Zeitraum kann nach Erstellung des Schlüssels nicht mehr geändert werden (Standard: 1 Tag).

-### Primäre Version
+### Primary Version

-Jeder KMS-Schlüssel kann mehrere Versionen haben, eine davon muss die **Standardversion** sein, die verwendet wird, wenn **keine Version angegeben ist, wenn mit dem KMS-Schlüssel interagiert wird**.
+Jeder KMS-Schlüssel kann mehrere Versionen haben; eine davon muss die **Standard- (default) Version** sein. Diese wird verwendet, wenn bei Interaktionen mit dem KMS-Schlüssel **keine Version angegeben** wird.

-### Aufzählung
+### CMEK permission model

-Wenn Sie **Berechtigungen zum Auflisten der Schlüssel** haben, so können Sie auf diese zugreifen:
+Wenn Objekte in Cloud Storage mit CMEK verschlüsselt sind, werden die Encrypt/Decrypt-Aufrufe an KMS vom Cloud Storage service agent des Projekts ausgeführt, dessen E-Mail service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com ist), und nicht direkt vom Endnutzer, der das Objekt liest.
+
+Das bedeutet, um etwas zu lesen, das mit einer CMEK verschlüsselt wurde:
+
+- Der Cloud Storage service agent des Projekts muss KMS-Berechtigungen für den verwendeten KMS-Schlüssel haben (typischerweise `roles/cloudkms.cryptoKeyEncrypterDecrypter`).
+- Der Benutzer benötigt nur Objekt-Lese-Berechtigungen (z. B. `storage.objects.get`). Er benötigt keine Berechtigungen für den KMS-Schlüssel.
+
+Das heißt, um den Zugriff auf mit dem KMS-Schlüssel verschlüsselte Daten zu kontrollieren, muss man KMS-Berechtigungen für den Cloud Storage service agent des Projekts hinzufügen/entfernen.
+
+Beachte, dass eine projektweite Bindung wie `roles/cloudkms.cryptoKeyEncrypterDecrypter` für den Storage service agent weiterhin das Entschlüsseln mit den Schlüsseln im selben Projekt erlaubt.
+
+### Enumeration
+
+Wenn Sie die **Berechtigung haben, die Schlüssel aufzulisten**, können Sie folgendermaßen auf sie zugreifen:
 ```bash
 # List the global keyrings available
 gcloud kms keyrings list --location global
@@ -61,13 +74,13 @@ gcloud kms decrypt --ciphertext-file=[INFILE] \
 --keyring [KEYRING] \
 --location global
 ```
-### Privilegienerhöhung
+### Privilege Escalation

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

-### Nach der Ausnutzung
+### Post Exploitation

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