GatewayToHeaven Finding a Cross-Tenant Vulnerability in GCP'...

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
+<AssignMessage name="strip-xff">
+  <Remove>
+    <Headers>
+      <Header name="X-Forwarded-For"/>
+    </Headers>
+  </Remove>
+  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
+</AssignMessage>
+```
+
+### 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 <tenant-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 <tenant-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/<api|mint>/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}}