AWS Bedrock沙箱逃逸：当云巨头说这是预期行为，安全界炸了
AWS Bedrock沙箱逃逸：当云巨头说”这是预期行为”，安全界炸了
安全研究员们发现了AWS Bedrock AgentCore Code Interpreter的一个严重漏洞——通过DNS解析可以绕过沙箱隔离，实现凭证窃取、S3存储桶枚举甚至C2通信。漏洞严重程度？CVSS 7.5（高）。
AWS的回应？”这是预期行为。”
这四个字在安全社区引发的震荡，比漏洞本身还要剧烈。
漏洞的技术本质
要理解这个漏洞为什么重要，先需要理解AWS Bedrock AgentCore Code Interpreter的设计目的。
当企业使用Bedrock构建AI Agent时，Agent经常需要执行代码——分析数据、调用API、处理文件。Code Interpreter提供了一个”沙箱”环境来运行这些代码，理论上将Agent的代码执行与底层基础设施隔离开来。
沙箱的安全承诺是：即使Agent执行了恶意代码（无论是因为提示注入还是其他原因），代码只能在沙箱内部运行，无法触及外部系统。
但研究人员发现了一个致命的缝隙：DNS解析没有被沙箱隔离。
具体的攻击链条如下：
- DNS查询绕过： 沙箱内的代码可以自由发起DNS查询。这看似无害——DNS只是”查名字”嘛。但DNS查询可以被精心构造，将任意数据编码在查询的子域名中。
- 数据外泄： 通过DNS隧道，沙箱内的代码可以将窃取的数据（如AWS凭证、环境变量）编码在DNS请求中，发送到攻击者控制的DNS服务器。
- S3枚举： 利用沙箱内可用的AWS SDK和环境凭证，攻击者可以枚举该账户下的S3存储桶列表。
- C2通信： 更进一步，通过DNS over HTTPS (DoH) 或编码在DNS TXT记录中的指令，攻击者可以建立一个完整的Command & Control通信通道——沙箱变成了一个持久的攻击据点。
“预期行为”的荒谬
AWS将这个漏洞归类为”预期行为”，理由是：DNS解析是Code Interpreter的正常功能需求，沙箱设计时就允许了DNS访问。
这个回应在安全社区引发了猛烈的批评：
“按这个逻辑，如果我在银行的保险柜里发现一个通往下水道的通道，银行告诉我’下水道管道是建筑的正常部分’——这能接受吗？”一位安全研究员在推特上写道。
问题的核心在于安全承诺与实际边界的不匹配。当AWS宣传Bedrock Code Interpreter的”沙箱隔离”能力时，用户的合理预期是：沙箱内的代码无法与外部世界通信。DNS隧道破坏了这个预期。
更令人担忧的是CVE-2026-4269——Bedrock AgentCore Starter Toolkit v0.1.13之前版本缺少S3所有权验证，可能导致构建过程中的远程代码注入，CVSS评分同样是7.5。两个高危漏洞叠加，构成了一个令人不安的画面：AWS的Agent安全基础设施可能并不像宣传的那样可靠。
对AI Agent安全的系统性影响
这不仅仅是一个AWS的问题。它暴露了整个AI Agent生态系统在安全设计上的一个根本性盲点：Agent的工具调用环境如何安全隔离？
每一个需要执行代码的AI Agent——无论是运行在AWS、Azure还是GCP上——都面临类似的设计挑战：
网络隔离的粒度。 完全断网的沙箱限制了Agent的实用性（很多任务需要网络访问）。但允许任何形式的网络访问都可能成为数据外泄的通道。DNS只是最容易被忽略的一种——还有ICMP、NTP等”基础设施协议”同样可以被用于隧道通信。
凭证管理的矛盾。 Agent需要凭证来访问企业系统（这是它的工作）。但这些凭证在沙箱内的存在，意味着一旦沙箱被突破，凭证就暴露了。理想方案是”零驻留凭证”——Agent每次需要访问时实时申请临时凭证，用完即销毁。但这会显著增加延迟和复杂度。
监控的缺失。 目前大多数AI Agent平台的安全监控集中在”Agent做了什么”（API调用日志），而不是”Agent的代码执行环境发生了什么”（系统级行为监控）。DNS隧道之所以能成功，正是因为DNS查询通常不在安全监控的范围内。
AWS的两难困境
公平地说，AWS的”预期行为”回应虽然在公关上是一场灾难，但在技术上反映了一个真实的两难：
如果阻断DNS： Code Interpreter将无法解析任何外部域名，大量依赖外部API的合法用例将失效。用户体验严重受损。
如果不阻断DNS： DNS隧道风险持续存在。AWS可以通过DNS过滤（只允许特定域名解析）来缓解，但这增加了配置复杂度，且可能被绕过。
最佳方案可能是分层安全——默认阻断所有出站通信，用户根据Agent的实际需求显式开放特定的网络访问（白名单模式），并对所有出站流量进行DPI（深度包检测）和异常检测。
但”最佳方案”往往意味着”更慢的开发速度”和”更差的开箱体验”——这在云服务的激烈竞争中是致命的。
给企业的安全建议
如果你的企业正在使用或计划使用Bedrock AgentCore（或任何云端AI Agent执行环境），以下是立即应采取的措施：
-
审计Agent的网络访问权限。 检查你的Agent运行环境中允许的出站通信范围。DNS、ICMP、NTP——这些”基础设施协议”是否在安全策略的覆盖范围内？
-
实施出站DNS监控。 对Agent环境的DNS查询进行日志记录和异常检测。异常高频的DNS查询、对非常用域名的解析、异常长的子域名（可能是数据编码）——这些都是DNS隧道的特征。
-
最小化Agent凭证权限。 不要给Agent”管理员”级别的AWS凭证。使用IAM策略限制Agent只能访问其任务所需的最小资源集。
-
升级AgentCore Starter Toolkit。 确保使用v0.1.13或更高版本，修复S3所有权验证漏洞。
-
制定Agent安全事件响应预案。 如果Agent的执行环境被突破，你的团队知道如何响应吗？隔离策略、取证流程、影响评估——这些需要提前准备。
结语：安全债务的利息
AWS Bedrock沙箱逃逸漏洞不是一个孤立事件。它是整个AI Agent行业在快速增长过程中积累的”安全债务”开始计息的信号。
过去两年，AI Agent的功能在飞速进化——从简单的问答到复杂的工具调用、代码执行、多Agent协作。但安全基础设施的进化速度远远跟不上功能创新的步伐。
当AWS说”这是预期行为”时，真正令人不安的不是这句话本身，而是它暗示的事实：在AI Agent的设计优先级中，功能和速度仍然排在安全前面。
这种优先级排序在行业早期可以理解。但随着企业开始将关键业务流程交给AI Agent，安全不再是”可以后补的功课”——它是”必须预装的安全气囊”。
Bedrock沙箱逃逸给整个行业敲响了警钟。问题是：有多少人会在闹钟响完之前醒来？
参考资料
- DNS Exfiltration from AWS Bedrock Sandboxed Code Interpreters — 原始漏洞披露文章
- CVE-2026-4269: Bedrock AgentCore Starter Toolkit S3 验证缺陷 — Tenable 漏洞数据库，CVSS 7.5