gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -07:00
Code Issues Packages Projects Releases Wiki Activity

f

Browse Source
This commit is contained in:
Carlos Polop
2026-03-04 12:21:21 +01:00
parent 53d29a8805
commit 9e39e77d6e
2 changed files with 27 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md
View File

@@ -82,6 +82,20 @@ gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_
- **Delete the KMS key**
- Now only the attacker, who has the original key material could be able to decrypt the encrypted data
#### Cloud Storage + 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.
This means that to read something encrypted by a CMEK:
- The project's cloud storage service agent must have KMS permissions over the used KMS key (typically `roles/cloudkms.cryptoKeyEncrypterDecrypter`).
- The user only needs object read permissions (for example `storage.objects.get`). He doesn't need permissions over the KMS key.
Thsi means that to control acces to encrypted data with the KMS key it's needed to add/rmeove KMS permissions to the projects cloud storage service agent.
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.
#### Here are the steps to import a new version and disable/delete the older data:
<details>
@@ -317,4 +331,3 @@ gcloud kms keys versions enable <VERSION_ID> \
{{#include ../../../banners/hacktricks-training.md}}

13
src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum.md
View File

@@ -35,6 +35,19 @@ The "Programmed for destruction" period is the **time since the user ask for del
Each KMS key can have several versions, one of them must be the **default** one, this will be the one used when a **version is not specified when interacting with the KMs key**.
### 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.
This means that to read something encrypted by a CMEK:
- The project's cloud storage service agent must have KMS permissions over the used KMS key (typically `roles/cloudkms.cryptoKeyEncrypterDecrypter`).
- The user only needs object read permissions (for example `storage.objects.get`). He doesn't need permissions over the KMS key.
Thsi means that to control acces to encrypted data with the KMS key it's needed to add/rmeove KMS permissions to the projects cloud storage service agent.
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.
### Enumeration
Having **permissions to list the keys** this is how you can access them: