diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 928d54295..c7b4bb5fe 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -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) 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 a2c2a1c8b..b16f7d106 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md @@ -1,74 +1,3 @@ # GCP - 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 - - - -
- - - 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}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-apigee-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-apigee-post-exploitation.md new file mode 100644 index 000000000..3df77629a --- /dev/null +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-apigee-post-exploitation.md @@ -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 + + + +
+ + + 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}} +