Azure Cosmos DB 严重漏洞曝光：一条查询可攻破所有租户数据库

作者 | Steef-Jan Wiggers

译者 | 田橙

Wiz Research 披露了 CosmosEscape，这是 Azure Cosmos DB 中的一条漏洞利用链，可获得对该服务上每个数据库的读写权限。Microsoft 已完成修复，客户无需采取任何行动。此次披露的重要性，与其说在于漏洞本身，不如说在于它揭示了从一个运行中的多租户系统里移除全局密钥需要多长时间，以及在此期间客户几乎无能为力。

这条利用链始于针对研究人员自行控制的 Gremlin 数据库发起的一条特制查询。Cosmos DB 会在旨在将查询限制于 Gremlin 操作范围内的约束条件下，把 Gremlin 查询编译成 .NET 代码，但这些限制并未充分考虑 .NET 反射。逃逸出沙箱后，攻击者便可在 DB Gateway 上执行代码。DB Gateway 是处理客户查询的多租户服务，这进而暴露了 Wiz 所称的 Cosmos Master Key：一个平台级密钥，可以获取任意 Cosmos DB 账户的主密钥，并按订阅和租户标识符筛选、枚举数据库。由于 Cosmos DB 是 Teams 和 Copilot 等服务的底层支撑，这一漏洞的影响范围还延伸到了 Microsoft 自己的后端。

CosmosEscape 攻击链

在 Hacker News 上，评论者 gtowey 对反射这一细节作出了回应：

这简直业余得令人难以置信。

Wiz 于 2025 年 11 月 20 日向 Microsoft 报告了这一问题，Microsoft 在当天予以确认，并在两天后通过热修复阻断了存在漏洞的 Gremlin 入口点。移除这一平台级密钥则一直持续到 2026 年 7 月，届时 Microsoft 才完成在所有区域推出新的凭据模型。

从业者的反应主要分为几个方面，但没有一个聚焦于漏洞利用本身。在 Reddit 上，评论者 TerrificAbsence 概括了这条利用链令人不安之处，称这是一次残酷的权限升级，并指出其利用方式极其简洁：

通过一条 Gremlin 查询实现 RCE，再到完全攻破租户密钥，这是一条残酷的权限升级链。真正超级吓人的是它的简单性，因为只需一条查询，不需要任何特殊工具，就能直达主密钥。

第一场争论围绕共同责任模型展开。评论者 ConsequenceLast6569 表示：

这种漏洞不会出现在任何共同责任模型示意图中。作为 Cosmos DB 客户，我们不可能采取任何不同的措施来阻止它；它完全存在于 Microsoft 的基础设施中。

评论者 godofpumpkins 换了一个角度，询问不存在任何客户侧缓解措施是否意味着，按照定义，该漏洞：

……完全属于共同责任模型示意图中的云服务提供商一侧。

这段交锋才是有价值的部分。该模型将平台划归服务提供商负责，因此租户隔离被突破恰恰属于服务提供商一侧的问题。令人不安的是随之而来的结果：修复过程对客户不可见，客户只能相信服务提供商所说的修复已经奏效。评论者 dointheatl 在 Hacker News 的讨论中直接表达了这种怀疑：

我不接受这个前提：谁说他们正确地修复了它？

第二场争论围绕六个月的时间间隔展开。有人抱怨修复进展缓慢，但也有人提出了实质性的反驳，强调应将热修复与架构重建区分开来。评论者 phatskat 指出，网关此前使用主密钥获取每个账户的私有密钥，然后再转发请求，因此移除主密钥意味着需要重建一项连 Microsoft 自己都依赖的服务的凭据模型。另一位评论者 delfinom 也从规模角度提出了同样的观点：

这是 Microsoft 自己和数以万计客户使用的一项重要服务；你不可能一夜之间凭感觉编程，给自己弄出一个新的数据库查询执行引擎。

第三场讨论重新审视了集中化风险。评论者 WantDebianThanks 表示，多年来，他一直主张将关键数据备份到另一家服务提供商或本地环境，但始终未能成功。评论者 maceinjar 反驳称，虚拟机监控程序的代码库并不会少一些缺陷，而且大多数组织的补丁管理还不如超大规模云服务提供商，但他也承认这种不对称性：

问题在于，超大规模云服务提供商一旦出问题，就真的会出大问题。

随后，评论者 LLMsMustUpvoteThis 进一步缩小了比较范围，指出典型的本地环境不会将其管理 API 暴露在互联网上，也不存在跨租户横向移动的风险：

不过，这是不同的威胁模型。

公开记录中没有包含以下三项内容：

• 没有 CVE 标识符，也没有 CVSS 评分，这对于一个被描述为严重级别的漏洞而言并不常见。

• 没有 MSRC 公告，与同一服务中 2021 年的 ChaosDB 和 2022 年的 CosMiss 不同，Microsoft 的立场仅存在于其向 Wiz 和记者提供的声明中。

• 没有说明暴露时间窗口，因为 Wiz 和 Microsoft 都没有说明存在漏洞的引擎和签名密钥路径于何时进入生产环境，也没有说明访问日志审查涵盖了哪个时间段。因此，“没有证据表明客户受到影响”这一保证的分母并不明确。

对于平台团队而言，实际启示并不是要应用某个补丁，而是应当向任何托管式多租户服务提出一个问题：平台在哪里保存着一个可以跨越多个租户的凭据，移除它需要付出什么代价？

Microsoft 在这起事件中给出的答案是：先用两天时间完成阻断，再用六个月时间在幕后重建架构。完整的漏洞利用链计划在 Black Hat USA 大会上公开演示。

https://www.infoq.com/news/2026/08/cosmosescape-master-key/

声明：本文为 InfoQ 翻译，未经许可禁止转载。