Merge pull request #254 from HackTricks-wiki/update_GatewayToHeaven__Finding_a_Cross-Tenant_Vulnerabil_20260203_185749

GatewayToHeaven Finding a Cross-Tenant Vulnerability in GCP'...
This commit is contained in:
SirBroccoli
2026-02-12 14:10:09 +01:00
committed by GitHub
3 changed files with 76 additions and 1 deletions

View File

@@ -85,6 +85,7 @@
- [GCP - Federation Abuse](pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md)
- [GCP - Permissions for a Pentest](pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md)
- [GCP - Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/README.md)
- [GCP - Apigee Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-apigee-post-exploitation.md)
- [GCP - App Engine Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-app-engine-post-exploitation.md)
- [GCP - Artifact Registry Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-artifact-registry-post-exploitation.md)
- [GCP - Bigtable Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-bigtable-post-exploitation.md)

View File

@@ -1,4 +1,3 @@
# GCP - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,75 @@
# GCP - Apigee Post Exploitation
{{#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}}