# 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}}

