# GCP - Apigee Post Exploitation

{{#include ../../../banners/hacktricks-training.md}}

## Apigee metadata SSRF -> Dataflow cross-tenant pivot

Een enkele Apigee tenant-projek kan misbruik word om die Message Processor metadata server te bereik, sy service account te steel, en te pivot na 'n gedeelde Dataflow analytics pipeline wat cross-tenant buckets lees/skryf.

### Maak die metadata server deur Apigee sigbaar

- Stel 'n Apigee proxy target in op `http://169.254.169.254` en versoek tokens vanaf `/computeMetadata/v1/instance/service-accounts/default/token` met `Metadata-Flavor: Google`.
- GCP metadata verwerp versoeke wat `X-Forwarded-For` bevat; Apigee voeg dit standaard by. Verwyder dit met `AssignMessage` voordat jy dit proxy:
```xml
<AssignMessage name="strip-xff">
<Remove>
<Headers>
<Header name="X-Forwarded-For"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
### Enumereer die gesteelde Apigee diensrekening

- Die leaked SA (Google-managed onder `gcp-sa-apigee`) kan met gereedskap soos [gcpwn](https://github.com/NetSPI/gcpwn) geënumerer word om vinnig toestemmings te toets.
- Waargeneem kragtige toestemmings het ingesluit **Compute disk/snapshot admin**, **GCS read/write across tenant buckets**, en **Pub/Sub topic publish**. Basiese ontdekking:
```bash
gcloud compute disks list --project <tenant-project>
```
### Snapshot exfiltration for opake bestuurde dienste

Met disk/snapshot regte kan jy bestuurde runtimes aflyn inspekteer selfs as jy nie in die tenant project kan aanmeld nie:

1. Skep 'n snapshot van 'n target disk in die tenant project.
2. Kopieer/migreer die snapshot na jou project.
3. Hercreëer 'n disk vanaf die snapshot en koppel dit aan jou VM.
4. Mount en inspekteer logs/configs om interne bucket name, service accounts, en pipeline opsies te herstel.

### Dataflow dependency replacement via skryfbare staging bucket

- Analytics workers het JARs vanaf 'n GCS staging bucket by opstart gehaal. Omdat die Apigee SA bucket write gehad het, laai die JAR af en patch dit (bv. met Recaf) om `http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token` aan te roep en die **Dataflow worker** token te steel.
- Dataflow workers het geen internet egress gehad nie; exfiltrate deur die token in 'n attacker-controlled GCS bucket te skryf met behulp van die in-cluster GCP APIs.

### Force malicious JAR execution by abusing autoscaling

Bestaande workers sal vervangde artifacts nie herlaai nie. Flood die pipeline input om nuwe workers te trigger:
```bash
for i in {1..5000}; do
gcloud pubsub topics publish apigee-analytics-notifications \
--message "flood-$i" --project <tenant-project>
done
```
Nuut voorsiene instansies haal die gepatchte JARs en leak die Dataflow SA token.

### Kruis-tenant bucket-ontwerpfout

Gedecompileerde Dataflow-kode het cache-paadjies getoon soos `revenue/edge/<api|mint>/tenant2TenantGroupCacheDir` onder 'n gedeelde metadata-bucket, sonder enige tenant-spesifieke komponent. Met die Dataflow token kan jy lees/skryf:

- `tenantToTenantGroup` caches wat ander tenants se projek- en omgewingname openbaar.
- `customFields` en `datastores` vouers wat per-versoek analytics bevat (insluitend eindgebruiker-IP's en platte-tekst toegangstokens) oor alle tenants.
- Skryftoegang impliseer potensiële analytics-manipulasie/vergiftiging.

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