From 3b110bdefe00b62b997cb2c7589484925d2397fe Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Tue, 3 Feb 2026 19:00:44 +0000 Subject: [PATCH] Add content from: GatewayToHeaven: Finding a Cross-Tenant Vulnerability in GCP... --- .../gcp-post-exploitation/README.md | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md index 2648d42455..a2c2a1c8b4 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md @@ -2,3 +2,73 @@ {{#include ../../../banners/hacktricks-training.md}} +## Apigee metadata SSRF -> Dataflow cross-tenant pivot + +A single Apigee tenant project can be abused to reach the Message Processor metadata server, steal its service account, and pivot into a shared Dataflow analytics pipeline that reads/writes cross-tenant buckets. + +### Expose the metadata server through Apigee + +- Set an Apigee proxy target to `http://169.254.169.254` and request tokens from `/computeMetadata/v1/instance/service-accounts/default/token` with `Metadata-Flavor: Google`. +- GCP metadata rejects requests containing `X-Forwarded-For`; Apigee adds it by default. Strip it with `AssignMessage` before proxying: + +```xml + + + +
+ + + true + +``` + +### Enumerate the stolen Apigee service account + +- The leaked SA (Google-managed under `gcp-sa-apigee`) can be enumerated with tools like [gcpwn](https://github.com/NetSPI/gcpwn) to quickly test permissions. +- Observed powerful permissions included **Compute disk/snapshot admin**, **GCS read/write across tenant buckets**, and **Pub/Sub topic publish**. Basic discovery: + +```bash +gcloud compute disks list --project +``` + +### Snapshot exfiltration for opaque managed services + +With disk/snapshot rights you can inspect managed runtimes offline even if you cannot log into the tenant project: + +1. Create a snapshot of a target disk in the tenant project. +2. Copy/migrate the snapshot to your project. +3. Recreate a disk from the snapshot and attach it to your VM. +4. Mount and inspect logs/configs to recover internal bucket names, service accounts, and pipeline options. + +### Dataflow dependency replacement via writable staging bucket + +- Analytics workers pulled JARs from a GCS staging bucket on startup. Because the Apigee SA had bucket write, download and patch the JAR (e.g., with Recaf) to call `http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token` and steal the **Dataflow worker** token. +- Dataflow workers lacked internet egress; exfiltrate by writing the token into an attacker-controlled GCS bucket using the in-cluster GCP APIs. + +### Force malicious JAR execution by abusing autoscaling + +Existing workers will not reload replaced artifacts. Flood the pipeline input to trigger new workers: + +```bash +for i in {1..5000}; do + gcloud pubsub topics publish apigee-analytics-notifications \ + --message "flood-$i" --project +done +``` + +Newly provisioned instances fetch the patched JARs and leak the Dataflow SA token. + +### Cross-tenant bucket design flaw + +Decompiled Dataflow code showed cache paths like `revenue/edge//tenant2TenantGroupCacheDir` under a shared metadata bucket, without any tenant-specific component. With the Dataflow token you can read/write: + +- `tenantToTenantGroup` caches exposing other tenants' project+environment names. +- `customFields` and `datastores` folders holding per-request analytics (including end-user IPs and plaintext access tokens) across all tenants. +- Write access implies potential analytics tampering/poisoning. + +## References + +- [GatewayToHeaven: Finding a Cross-Tenant Vulnerability in GCP's Apigee](https://omeramiad.com/posts/gatewaytoheaven-gcp-cross-tenant-vulnerability/) +- [AssignMessage policy - header removal](https://cloud.google.com/apigee/docs/api-platform/reference/policies/assign-message-policy) + +{{#include ../../../banners/hacktricks-training.md}}