# GCP - Apigee Post Exploitation

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

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

単一の Apigee テナントプロジェクトを悪用することで、Message Processor の metadata server に到達し、その service account を盗み、クロステナントのバケットを読み書きする共有 Dataflow analytics pipeline へ pivot できます。

### Expose the metadata server through Apigee

- Apigee の proxy target を `http://169.254.169.254` に設定し、`Metadata-Flavor: Google` を付けて `/computeMetadata/v1/instance/service-accounts/default/token` からトークンを要求します。
- GCP metadata は `X-Forwarded-For` を含むリクエストを拒否します；Apigee はデフォルトでこれを追加します。proxy する前に `AssignMessage` でこれを除去してください:
```xml
<AssignMessage name="strip-xff">
<Remove>
<Headers>
<Header name="X-Forwarded-For"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
### 盗まれた Apigee サービスアカウントの列挙

- The leaked SA (Google-managed under `gcp-sa-apigee`) は [gcpwn](https://github.com/NetSPI/gcpwn) のようなツールで列挙でき、権限を素早くテストできます。
- 観測された強力な権限には **Compute disk/snapshot admin**, **GCS read/write across tenant buckets**, **Pub/Sub topic publish** が含まれていました。基本的な調査:
```bash
gcloud compute disks list --project <tenant-project>
```
### Snapshot exfiltration for opaque managed services

disk/snapshot rights があれば、tenant project にログインできない場合でも managed runtimes をオフラインで調査できます:

1. tenant project 内のターゲット disk の snapshot を作成する。
2. snapshot を自分の project にコピー/マイグレートする。
3. snapshot から disk を再作成し、それを VM にアタッチする。
4. ログ/設定をマウントして調べ、内部の bucket 名、service accounts、pipeline オプションを回収する。

### writable staging bucket 経由での Dataflow 依存置換

- Analytics workers は起動時に GCS staging bucket から JAR を取得していた。Apigee SA に bucket 書き込み権限があったため、JAR をダウンロードしてパッチ（例: Recaf）し、`http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token` を呼び出して **Dataflow worker** トークンを盗む。
- Dataflow workers はインターネット egress を持たなかった；クラスタ内の GCP APIs を使ってトークンを attacker-controlled GCS bucket に書き込み、exfiltrate する。

### autoscaling を悪用して malicious JAR を強制実行

既存の workers は置き換えた artifacts をリロードしない。pipeline の入力を氾濫させて新しい workers を起動させる：
```bash
for i in {1..5000}; do
gcloud pubsub topics publish apigee-analytics-notifications \
--message "flood-$i" --project <tenant-project>
done
```
新しくプロビジョニングされたインスタンスはパッチ済みの JAR を取得し、Dataflow SA token を leak する。

### テナント間バケットの設計上の欠陥

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 読み取り/書き込み:

- `tenantToTenantGroup` キャッシュは他テナントの project+environment 名を露出する。
- `customFields` と `datastores` フォルダは全テナントのリクエスト単位の解析データ（エンドユーザーの IP や平文のアクセス トークンを含む）を保持している。
- 書き込み権限は解析データの改ざん/汚染の可能性を意味する。

## 参考資料

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