文章总结： 本文分析AWSBedrockAgentCore沙盒化代码解释器中全局S3访问功能被滥用于建立命令与控制通道的安全风险。研究显示攻击者可利用预签名URL通过外部S3存储桶实现与沙盒环境的双向通信，并提供了开源PoC工具进行验证。文章强调这并非漏洞而是功能特性，建议使用VPC模式和网关端点配合严格策略来缓解风险。 综合评分： 85 文章分类： 云安全,漏洞分析,解决方案,安全工具,渗透测试
全局S3：AgentCore代码解释器的另一条C2通道
Dubito Dubito
云原生安全指北
2026年4月29日 08:36 江苏
在小说阅读器读本章
去阅读
注：本文翻译自 Sonrai Security 的文章《Global S3: Another C2 Channel for AgentCore Code Interpreters》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
基于最近一项识别出沙盒模式 AgentCore 代码解释器中基于 DNS 数据外泄风险的研究，我发现全局 S3 访问（global S3 access）是沙盒化代码解释器的另一个命令与控制（C2）通道。与已完全缓解的基于 DNS 的泄露不同，S3 访问是 AgentCore 代码解释器一项实用且文档完备的功能，但仍然存在安全风险。本文将分析代码解释器对 S3 的固有访问权限如何被用于出站通信，介绍一个PoC工具，演示如何将此行为变为通向沙盒化解释器的完整反弹 Shell，并讨论可用于缓解相关风险的策略。
二、背景
Amazon Bedrock AgentCore 代码解释器（ Code Interpreters）长期以来一直是云安全研究人员关注的对象。由于它提供的执行环境中，远程代码执行是功能而非漏洞，一旦攻击者将代码注入调用这些解释器的工作流，就可能引发大量问题。
去年，我深入研究了这项新技术，分析了拥有失陷 AWS 凭证的攻击者如何利用代码解释器进行权限提升（参见文章一[2]、文章二[3]（译文详见：沙盒隔离形同虚设？最新研究揭露AWS代码解释器中的凭证窃取路径）），并且这已被 Datadog[4] 的 pathfinding.cloud[5] 等资源文档化——参见此处[6]。
然而，代码解释器固有的风险不仅限于权限问题。考虑到这些解释器能够运行任意代码，且可能正在处理敏感信息，Amazon 推出了带有沙盒模式（Sandbox mode）的代码解释器，用以限制解释器对公共互联网的访问。
BeyondTrust Phantom Labs[7] 的 Kinnaird McQuade[8] 近期对该网络模式的先前局限进行了深入分析[9]。他在文章中指出，当时这种网络模式可以借助出站 DNS 查询作为双向通信通道被有效绕过。为直观展示这一风险的严重程度，他还发布了一款开源工具[10]，演示了如何利用这一流量过滤的缺口建立通向沙盒化代码解释器的完整反弹 Shell。Palo Alto 的 Unit 42[11] 后续的研究[11]也证实了这一发现。
所幸，AWS 已正式修复了此问题（正如 Kinnaird 的文章所强调的[9]）。目前，面向非 S3 端点的 DNS 查询已不再被解析：
（有关如何向代码解释器直接传入 Shell 命令的详细信息，请参阅我之前的代码解释器研究[2]）
但阻止出站 DNS 查询并不能完全消除数据外泄风险。在本文中，我将以 Kinnaird 的研究为基础，展示沙盒化 AgentCore 代码解释器中另一种形式的允许列表流量（allow-listed traffic）也能被用于命令与控制[12]（Command & Control，C2）：S3 请求。
这不是 Bedrock 的一项漏洞；相反，我们只是以代码解释器既定的设计方式来使用其 S3 连接。具体而言，我们将借助对 S3 端点的访问权限，在一个沙盒化代码解释器中建立 C2 通道，然后讨论如何缓解相关风险。该 C2 通道也已被添加到 Kinnaird 的开源工具[10]中，供其他安全专业人士进行实验。
三、沙盒化代码解释器的 S3 访问
针对 BeyondTrust 对基于 DNS 的数据外泄风险的负责任披露，Amazon 更新了其对沙盒模式的描述，以强调“无外部流量”规则的例外情况：
关于 DNS 的说明回应了现已得到缓解的数据外泄风险——但他们也提到了 S3。这并不意外，因为官方文档[13]自发布以来就表明，即使是沙盒模式的代码解释器也可以使用其执行角色（execution role）来访问 S3。但从外部网络访问的角度来看，这确实引出了一个有趣的问题：解释器内部能够执行的 S3 数据操作是否存在限制？
答案似乎是否定的。初步测试表明，代码解释器内允许进行跨组织的存储桶访问。不仅如此——代码解释器在访问外部存储桶时甚至不需要执行角色。如果存储桶配置为公开访问，解释器内就可以使用未签名请求（unsigned request）来读取。读写操作均可以：
Gets（读取）：
Puts（写入）：
四、构建C2通道
由于 S3 访问是全局性的，相比基于 DNS 的利用方式，将该服务转变为有效的双向通信通道显得轻而易举。简而言之，步骤如下：
- 1. 搭建一个外部（跨账户、跨组织）S3 存储桶。
- 2. 编写一个客户端脚本，轮询该 S3 存储桶，在子进程中运行其找到的任何 Shell 脚本，然后将输出写回存储桶。
- 3. 将该客户端传入代码解释器。
- 4. 将 Shell 命令上传到存储桶，然后等待响应出现。
还有一个细节需要厘清：如何确保只有我们和代码解释器能够访问这个外部存储桶？进一步调查揭示，除了访问公开的外部存储桶外，代码解释器还可以通过传入的预签名 URL[14]（pre-signed URLs）来访问非公开的外部存储桶。
因此，与其使用公开读取，我们可以在客户端负载中嵌入一个对外部 C2 存储桶具有读取权限的预签名 URL。然后，在向代码解释器传入每条 Shell 命令时，我们也传入一个预签名 URL，允许解释器将响应以 PUT 方式写入到特定的对象键（object key）。我们使用序列号来帮助客户端跟踪存储桶中哪些命令已被执行，同时也可以将序列号作为存储桶键的一部分来写入结果：
命令文件结构（上传至 s3://{bucket}/sessions/{id}/cmd）：
{
"seq": <序列号>,
"cmd": "<Shell 命令>",
"response_put_url": "<s3://{bucket}/sessions/{id}/out/{seq} 的预签名 PUT URL>"
}
协议示意图：
注：示意图中文译版
注：原文章示意图
五、反弹 Shell 测试
我没有从零开始构建概念验证（Proof-of-Concept, PoC），而是与 Kinnaird McQuade[8] 合作，在其基于 DNS 的 C2 概念验证工具[10]基础上，扩展了以 S3 作为辅助 C2 通道的功能。通过将一个包含客户端负载的恶意文件传入一台易受提示注入攻击的 AI 驱动 Web 服务器，我们可以让该客户端 Payload 运行在沙盒化代码解释器上。
客户端就绪后，我们即可连接到 S3 存储桶并开始发送命令。该 PoC 包含一个攻击者客户端，可连接到存储桶并将会话状态作为反向 Shell 自动管理：
六、影响与启示
再次强调，这不是 Bedrock 的一项漏洞。代码解释器的全局 S3 访问是预期行为，我们只是恰巧以非常规方式使用了它。基于这种行为，有一些重要的要点值得关注：
● 尽可能使用 VPC 模式（VPC mode） ● 在需要 S3 访问时，使用网关端点（Gateway Endpoints）并配合严格的端点策略（Endpoint Policies）
使用 VPC 模式而非沙盒模式以获得更细粒度的网络功能控制，这是 AWS 在回应 BeyondTrust[15] 和 Palo Alto[16] 研究时给出的建议。虽然 DNS 问题正在得到缓解，但仍应遵循此建议以应对基于 S3 的数据外泄风险。
除了在使用 VPC 模式时能够控制域名解析之外，你还可以控制流向 AWS 端点的出站流量。如果确实需要 S3 访问，使用网关端点[17]（Gateway Endpoints）来实现这一目的，可以最大限度地控制允许哪些 S3 访问。代码解释器通常只需要访问特定的存储桶。端点策略[18]可以用来确保任何超出此范围的 S3 数据操作都将失败。
七、结论
沙盒化代码解释器的设计初衷是仍然能够访问 S3 资源。Amazon 无从知晓哪些存储桶需要被访问，而现在增加范围限制又可能会破坏现有的合法工作流。遗憾的是，这种全局 S3 访问确实提供了一种绕过网络隔离的机制。
当 DNS 数据外泄（已得到缓解）成为问题时，AWS 曾建议使用 VPC 模式代码解释器以实现完整的网络隔离；本次研究表明，这一预防措施依然必要。此外，当使用此网络模式需要 S3 访问时，本文描述的 S3 C2 通道进一步强调了我们不仅需要锁定 VPC 中的 DNS，还需要锁定 S3 访问机制。这意味着要使用网关端点并配合严格的端点策略，将访问限制到特定的 S3 存储桶。
如果这让你产生兴趣，或者你希望在自己的环境中尝试这些测试，请查看该PoC[10]。
引用链接
[1] 《Global S3: Another C2 Channel for AgentCore Code Interpreters》: https://sonraisecurity.com/blog/global-s3-another-c2-channel-for-agentcore-code-interpreters/
[2] 文章一: https://sonraisecurity.com/blog/aws-agentcore-privilege-escalation-bedrock-scp-fix/
[3] 文章二: https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/
[4] Datadog: https://www.datadoghq.com/
[5] pathfinding.cloud: https://pathfinding.cloud/
[6] 此处: https://pathfinding.cloud/paths/bedrock-001
[7] BeyondTrust Phantom Labs: https://www.beyondtrust.com/channel/phantom-labs
[8] Kinnaird McQuade: https://www.linkedin.com/in/kmcquade3/
[9] 深入分析: https://www.beyondtrust.com/blog/entry/pwning-aws-agentcore-code-interpreter
[10] 开源工具: https://github.com/BeyondTrust/pwning-agentcore-code-interpreter
[11] Palo Alto 的 Unit 42: https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/
[12] 命令与控制: https://attack.mitre.org/tactics/TA0011/
[13] 官方文档: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/code-interpreter-s3-integration.html
[14] 预签名 URL: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
[15] BeyondTrust: https://www.beyondtrust.com/blog/entry/pwning-aws-agentcore-code-interpreter#public-statement-from-aws
[16] Palo Alto: https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/#mitigation-and-collaboration-with-aws:~:text=our%20own%20environments.-,Mitigation%20and%20Collaboration%20With%20AWS,-After%20we%20shared
[17] 网关端点: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
[18] 端点策略: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#edit-vpc-endpoint-policy-s3
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito Dubito《全局S3：AgentCore代码解释器的另一条C2通道》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论