CosmosEscape 差点拿到所有 Azure 数据库钥匙：云隔离不能把平台主密钥放进租户执行路径
作者：韩启明｜OC 政策与安全编辑
韩启明
据安全公司 Wiz 披露，其研究人员发现 Azure Cosmos DB 的 Gremlin API 存在一条被称为 CosmosEscape 的攻击链。研究者从自有数据库提交特制查询，突破 Gremlin 执行沙箱，在后端网关取得代码执行，并接触到可换取任意 Cosmos DB 账户主密钥的平台级秘密。
一句话结论：最危险的不是某个查询语言出现沙箱逃逸，而是承载租户输入的共享网关同时拥有跨租户取钥能力；一旦执行边界失守，网络隔离、私有端点和单账户密钥都可能被平台权限绕过。
Cosmos DB 支持 SQL、MongoDB、Cassandra、Gremlin 等多种 API。Gremlin 用于图查询，服务端会把查询转换为可执行逻辑并在限制环境中运行。Wiz 称，其限制没有充分阻止 .NET 反射，研究者因此构造出文件读写和任意代码执行能力。
代码运行在 DB Gateway 上。这个共享网关负责接收客户查询并连接实际数据库，本来就需要某种方式获取账户凭据。研究者发现，网关可访问一个平台级签名秘密，能够请求任何租户、区域和 API 类型的账户主密钥。他们将其称为“Cosmos Master Key”。
攻击链还可访问 Config Store，其中包含账户名、订阅 ID、租户 ID、网络设置和标签等目录信息。攻击者理论上可以先枚举目标组织的数据库，再获取对应主密钥，完成读写控制。由于网关位于网络隔离的执行路径内，私有 Cosmos DB 也未必能依靠外部防火墙阻止这种平台内攻击。
Wiz 于 2025 年 11 月向微软报告问题。微软表示在 48 小时内封堵 Gremlin API 入口，随后完成长期架构整改、移除相关平台主密钥并增加认证和网络防护。双方均称未发现研究活动之外的利用或客户数据访问，微软表示客户无需操作。这一点与 2021 年 ChaosDB 事件不同，当时部分客户需要轮换密钥。
“无需客户操作”不等于企业什么都不必学。托管云服务会把大量安全责任交给平台，客户无法自行修补网关，但可以减少长期主密钥使用，采用托管身份和最小权限，记录异常数据访问，并为关键数据库准备跨账户或跨云备份。平台故障不应成为业务无法恢复的单点。
关键事实
- 来源：Wiz 技术披露及文内微软回应
- 涉及服务：Azure Cosmos DB，入口为 Gremlin API
- 攻击链：沙箱逃逸、网关代码执行、平台取钥秘密、账户目录枚举
- 修复状态：微软称已完成缓解和长期整改，未发现研究之外利用，客户无需操作
OC 判断
这不是普通客户配置错误，而是云平台控制面的架构问题。多租户服务必须假设租户输入最终能突破某一层沙箱，因此承载输入的执行环境不应持有全局凭据。平台级密钥把便利集中成单点失败，正确修复不是再加一条过滤规则，而是缩小凭据范围并拆断跨租户取钥路径。
为什么重要
- 对开发者：在 Cosmos DB 中优先使用托管身份和细粒度 RBAC，减少应用直接持有主密钥。
- 对企业：云服务修复后仍应核对日志、备份和恢复方案，理解哪些风险只能由平台控制。
- 对云厂商：任何运行租户代码或查询的共享服务都应被视为敌对环境，不能靠单层沙箱保护全局秘密。
评论
围绕这篇文章补充信息、提出问题或分享观察。