# GCP - Apigee Post Exploitation

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

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

Un singolo progetto tenant Apigee può essere abusato per raggiungere il server metadata del Message Processor, rubare il suo service account e pivotare in una pipeline analytics Dataflow condivisa che legge/scrive bucket cross-tenant.

### Esporre il metadata server tramite Apigee

- Imposta un Apigee proxy target su `http://169.254.169.254` e richiedi token da `/computeMetadata/v1/instance/service-accounts/default/token` con `Metadata-Flavor: Google`.
- Il metadata di GCP rifiuta le richieste che contengono `X-Forwarded-For`; Apigee lo aggiunge di default. Rimuovilo con `AssignMessage` prima dell'inoltro:
```xml
<AssignMessage name="strip-xff">
<Remove>
<Headers>
<Header name="X-Forwarded-For"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
### Enumerare il service account Apigee rubato

- The leaked SA (gestita da Google sotto `gcp-sa-apigee`) può essere enumerata con strumenti come [gcpwn](https://github.com/NetSPI/gcpwn) per testare rapidamente i permessi.
- Sono stati osservati permessi potenti, tra cui **Compute disk/snapshot admin**, **GCS read/write across tenant buckets**, e **Pub/Sub topic publish**. Scoperta di base:
```bash
gcloud compute disks list --project <tenant-project>
```
### Esfiltrazione di snapshot per servizi gestiti opachi

Con diritti su disk/snapshot puoi ispezionare i managed runtimes offline anche se non puoi accedere al tenant project:

1. Crea uno snapshot di un target disk nel tenant project.
2. Copia/migra lo snapshot nel tuo progetto.
3. Ricrea un disk dallo snapshot e attaccalo alla tua VM.
4. Monta e ispeziona logs/config per recuperare nomi di bucket interni, service accounts e opzioni della pipeline.

### Sostituzione delle dipendenze di Dataflow tramite staging bucket scrivibile

- Gli analytics workers scaricavano JAR da un GCS staging bucket all'avvio. Poiché l'Apigee SA aveva write sul bucket, scarica e patcha il JAR (e.g., con Recaf) per chiamare `http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token` e rubare il **Dataflow worker** token.
- I Dataflow workers non avevano internet egress; esfiltra scrivendo il token in un GCS bucket controllato dall'attaccante usando le in-cluster GCP APIs.

### Forzare l'esecuzione di JAR malevoli abusando dell'autoscaling

I worker esistenti non ricaricheranno gli artefatti sostituiti. Inonda l'input della pipeline per far partire nuovi worker:
```bash
for i in {1..5000}; do
gcloud pubsub topics publish apigee-analytics-notifications \
--message "flood-$i" --project <tenant-project>
done
```
Le istanze appena provisionate scaricano i JAR patchati e leakano il Dataflow SA token.

### Difetto di progettazione del bucket cross-tenant

Il codice Dataflow decompilato mostrava percorsi di cache come `revenue/edge/<api|mint>/tenant2TenantGroupCacheDir` sotto un metadata bucket condiviso, senza alcun componente specifico per tenant. Con il Dataflow token puoi leggere/scrivere:

- `tenantToTenantGroup` caches esponendo i nomi project+environment di altri tenant.
- `customFields` and `datastores` folders che contengono analytics per richiesta (inclusi end-user IPs e plaintext access tokens) per tutti i tenant.
- L'accesso in scrittura implica potenziale manomissione/poisoning delle analytics.

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