# GCP - Network Docker Escape

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

## 初期状態

この手法が記載されている両方の報告では、攻撃者はホストネットワークにアクセスできる GCP 管理下の **Docker** コンテナ内で **root** 権限を取得しました（およびケーパビリティ **`CAP_NET_ADMIN`** および **`CAP_NET_RAW`**）。

## 攻撃の説明

Google Compute Engine インスタンスでは、ネットワークトラフィックを監視すると、`169.254.169.254` の **metadata instance** への多数の **plain HTTP requests** が定期的に確認されます。オープンソースのサービスである [**Google Guest Agent**](https://github.com/GoogleCloudPlatform/guest-agent) は、そのようなリクエストを頻繁に行います。

このエージェントは **metadata の変更を監視する** よう設計されています。特に、metadata には **SSH 公開鍵用のフィールド** が含まれています。新しい公開 SSH キーが metadata に追加されると、エージェントはそれを `.authorized_key` ファイルに自動的に **登録（authorize）** します。必要に応じて **新しいユーザーを作成** し、そのユーザーを **sudoers** に追加することもあります。

エージェントは、すべての metadata 値を再帰的に取得するリクエスト（`GET /computeMetadata/v1/?recursive=true`）を送信することで変更を監視します。このリクエストは、前回取得時から metadata に変更があった場合にのみメタデータサーバーがレスポンスを返すよう設計されており、Etag（`wait_for_change=true&last_etag=`）で識別されます。さらに、**timeout** パラメータ（`timeout_sec=`）も含まれます。指定したタイムアウト内に変更がなければ、サーバーは **変更なしの値（unchanged values）** を返します。

このプロセスにより、構成の変更がない場合には **IMDS** (Instance Metadata Service) が **60 秒** 後に応答することが可能となり、guest agent に対して偽の構成レスポンスを注入するための潜在的な **ウィンドウ** が生まれます。

攻撃者はこれを悪用して **Man-in-the-Middle (MitM) attack** を実行し、IMDS サーバーからのレスポンスを偽装して **新しい公開鍵を挿入** することができます。これによりホストへの不正な SSH アクセスが可能になる可能性があります。

### エスケープ手法

Google Compute Engine のネットワーク上では ARP spoofing は無効ですが、[**Ezequiel**](https://www.ezequiel.tech/2020/08/dropping-shell-in.html) が開発した [**modified version of rshijack**](https://github.com/ezequielpereira/rshijack) を通信のパケット注入に使用して SSH ユーザーを挿入することができます。

このバージョンの rshijack は ACK と SEQ 番号をコマンドライン引数として入力できるため、実際の Metadata サーバーのレスポンスより前にレスポンスを偽装しやすくなります。さらに、[**small Shell script**](https://gist.github.com/ezequielpereira/914c2aae463409e785071213b059f96c#file-fakedata-sh) を使って **特別に作成されたペイロード（specially crafted payload）** を返します。このペイロードは Google Guest Agent に対して `.authorized_keys` ファイルに指定した公開鍵で **ユーザー `wouter` を作成（create a user `wouter`）** させます。

スクリプトは同じ ETag を使用して、Metadata サーバーがすぐに Google Guest Agent に異なる metadata 値を通知するのを防ぎ、レスポンスを遅延させます。

spoofing を実行するには、次の手順を実行します。

1. **Metadata server へのリクエストを監視する**（**tcpdump** を使用）:

<details>
<summary>tcpdump で metadata サーバーへのリクエストを監視</summary>
```bash
tcpdump -S -i eth0 'host 169.254.169.254 and port 80' &
```
</details>

次のような行を探してください:

<details>
<summary>tcpdump の出力行の例</summary>
```
<TIME> IP <LOCAL_IP>.<PORT> > 169.254.169.254.80: Flags [P.], seq <NUM>:<TARGET_ACK>, ack <TARGET_SEQ>, win <NUM>, length <NUM>: HTTP: GET /computeMetadata/v1/?timeout_sec=<SECONDS>&last_etag=<ETAG>&alt=json&recursive=True&wait_for_change=True HTTP/1.1
```
</details>

2. 正しい ETAG を使って偽のメタデータを rshijack に送信する:

<details>
<summary>偽のメタデータを送信してホストに SSH する</summary>
```bash
fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <LOCAL_IP>:<PORT> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
```
</details>

この手順は公開鍵を承認し、対応する秘密鍵でのSSH接続を可能にします。

## 参考文献

- [https://www.ezequiel.tech/2020/08/dropping-shell-in.html](https://www.ezequiel.tech/2020/08/dropping-shell-in.html)
- [https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities)

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