CosmosEscape：接管Azure Cosmos DB中的所有数据库

# CosmosEscape: 掌控 Azure Cosmos DB 中的每一个数据库 来源：https://www.wiz.io/blog/cosmosescape-taking-over-every-database-in-azure-cosmos-db Wiz Research 发现了一个名为 **CosmosEscape** 的关键漏洞，该漏洞存在于 Azure 旗舰数据库服务 Azure Cosmos DB 的 Gremlin API 中。该漏洞可能被利用来危害该服务中的所有数据库，包括微软自身的内部数据库，从而可能引发跨服务攻击。 通过 CosmosEscape，攻击者可以获得我们称之为 **Cosmos Master Key**（宇宙主密钥）的密钥——这是一个平台级的秘密，赋予了两个极其强大的能力： 1. **接管** —— 按需检索任何 Cosmos DB 账户的主密钥，从而获得完全的读写访问权限。 2. **枚举** —— 列出该服务中的所有数据库，并能够按订阅 ID 和租户 ID 等特定组织标识符进行筛选。 结合使用这些能力，可以在平台范围内实现精确攻击：从识别特定组织的数据库到入侵它们，所有操作均通过公开可访问的端点完成。 Cosmos DB 在微软内部被广泛使用，例如 **Microsoft Entra ID**（https://www.infoq.com/presentations/azure-cosmos-db-scalability/）、**Microsoft Teams**（https://learn.microsoft.com/en-us/purview/edisc-search-teams#where-teams-content-is-stored）和 **Microsoft Copilot**（https://devblogs.microsoft.com/cosmosdb/how-microsoft-copilot-scales-to-millions-of-users-with-azure-cosmos-db/）都将数据存储在 Cosmos DB 中。它们的数据库可能因该漏洞而可被访问。 微软现已完全修复了此问题，包括移除了 Cosmos Master Key。微软还为 Cosmos DB 引入了新的防护措施，以防止类似攻击。 图 1：CosmosEscape 的影响此项研究得到了早期版本的 **Atlas**（https://www.wiz.io/blog/atlas-ai-vulnerability-researcher）（我们的人工智能漏洞研究员）的协助。更多关于 Atlas 的消息即将发布。 ## 必要操作 微软已完全修复此问题。**无需客户执行任何操作。** 微软进行了彻底调查，未发现除本博客所述研究之外的利用该漏洞的证据。 ## 从一次查询到解锁所有数据库 Cosmos DB 支持多种查询 API，其中包含 **Gremlin**（https://tinkerpop.apache.org/gremlin.html），一种流行的图查询语言： 在针对 Cosmos DB 运行 Gremlin 查询时，我们注意到一个可疑的 .NET 异常。由于大多数开源 Gremlin 栈基于 JVM，该异常表明 Cosmos DB 使用的是 **自定义 Gremlin 引擎**。这很有趣——与标准 SQL 不同，标准 SQL 引擎将查询映射到一组固定的内置操作，而 Gremlin 服务器通常将查询编译为可执行代码并在受限环境中运行。从历史上看，这些沙箱的防护效果并不理想（https://www.vicarius.io/vsociety/posts/remote-code-execution-vulnerability-in-apache-hugegraph-server-cve-2024-27348）。我们怀疑 Cosmos DB 的 Gremlin 沙箱也可能存在漏洞。 确实如此。Cosmos DB 的引擎将 Gremlin 查询转换为 .NET 代码，并实施了一系列旨在防止查询范围超出 Gremlin 操作的限制。然而，这些限制并未充分考虑 .NET 反射——这使我们能够开发文件读取、写入，最终实现任意代码执行的基本操作，所有这些都通过针对我们自己数据库的查询完成。 下图展示了针对我们的数据库运行精心构造的 Gremlin 查询的输出，结果是在 Cosmos DB 后端执行了 `hostname` 命令： 图 2：通过 Gremlin API 在 Cosmos DB 后端执行 hostname。查看我们即将在 BlackHat USA 演讲中的完整查询。通过绕过 Gremlin 沙箱，我们在 **DB Gateway**（数据库网关）上获得了代码执行权限。该网关代表客户执行查询，运行在多租户 Service Fabric 集群上。 检查后发现，客户数据库并不托管在这些集群上，但 DB Gateway 必须以某种方式访问它们。事实证明，它像任何 Cosmos DB 客户端一样——使用目标账户的 **主密钥**（https://learn.microsoft.com/en-us/rest/api/cosmos-db/access-control-on-cosmosdb-resources#master-key-tokens）进行访问，该密钥授予对账户数据库的完全读写权限。 但 DB Gateway 如何能够检索我们 Cosmos DB 账户的主密钥呢？ ## Cosmos Master Key（宇宙主密钥） 通过集群上可用的凭据，DB Gateway 访问了一个签名密钥，该密钥可以检索所请求账户的主密钥。 我们很快发现该签名密钥 **并非局限于单个账户**。它跨租户、区域甚至 API 类型（SQL、MongoDB、Cassandra 和 Gremlin）都有效。**它是一个平台级的密钥，能够通过公开可访问的端点检索该服务中任何 Cosmos DB 账户的主密钥。** 我们将其称为 Cosmos Master Key。 ## Config Store——Cosmos DB 的账户目录 Master Key 还解锁了 **Config Store**（配置存储）：一个包含每个 Cosmos DB 账户信息的区域注册表——包括账户名称、订阅 ID、租户 ID、网络设置、标签等。DB Gateway 依赖它来获取账户设置，例如允许访问数据库的 IP 地址。 Config Store 本身也是一个 Cosmos DB 数据库，这意味着可以使用 Cosmos DB SQL 引擎的全部灵活性对其进行查询。这也意味着 Cosmos Master Key 可以检索其主密钥——从而使利用 CosmosEscape 的攻击者能够列出某个区域的所有账户，或按特定租户 ID 查询以识别特定组织的数据库。 ## 影响 Cosmos Master Key 和 Config Store 共同构成了一个强大的攻击链： 1. 查询 Config Store 以枚举某个区域的所有 Cosmos DB 账户，或按租户或订阅过滤以针对特定组织。 2. 使用 Cosmos Master Key 检索目标的主密钥，从而获得对其所有数据库的完全读写访问权限。 这不仅影响客户数据库。Cosmos DB 是许多 Microsoft 和 Azure 服务的基础设施——这意味着微软自身的内部数据库同样暴露在风险中。 图 3：CosmosEscape 的攻击链CosmosEscape 还影响了私有和网络隔离的 Cosmos DB 账户。由于 DB Gateway 负责实施网络隔离，入侵它可以直接访问私有数据库。此外，对 Config Store 的写入权限表明攻击者可能能够覆盖网络隔离设置。 ## 结论 云平台是分层构建的。像 Cosmos DB 这样的服务位于基础设施层——为 Microsoft Teams、Microsoft Entra ID 和 Microsoft Copilot 等更高级别的服务提供支持。此层的漏洞可能向上级联，威胁到在其上构建的服务。 多租户云服务需要至少一个围绕租户控制执行的强隔离边界——该边界仅暴露一个狭小且经过严格审计的攻击面。该边界内的所有内容都应被视为租户控制且不可信。理想情况下，边界应紧密围绕租户环境划定：包含的资源越少，就越容易确保特权凭据、内部 API 和跨租户路径无法触及。 我们负责任地向微软披露了此漏洞，微软已完全修复。微软迅速部署了热修复，此后 Cosmos DB 团队昼夜不停地进行了大规模迁移，转向更优越、更坚固的架构。我们感谢 MSRC 和 Cosmos DB 团队在此问题上的合作与持续伙伴关系。 有关完整的利用链、深入分析以及一些惊喜，请参加我们在 Black Hat USA 的演讲：**《One Key to Rule Them All: Taking Over a Flagship Cloud Service》**（https://blackhat.com/us-26/briefings/schedule/index.html#one-key-to-rule-them-all-taking-over-a-flagship-cloud-service-53889）。 ## 供应商声明 微软感谢有机会根据 **协调漏洞披露（CVD）**（https://www.microsoft.com/en-us/msrc/cvd?msockid=3b9bf875336a6b431548eeb032096a8c）调查 Wiz 报告的研究发现。微软对访问日志进行了广泛审查，未发现除研究人员测试活动之外的任何未经授权的活动证据，也没有客户数据被访问。无需客户采取任何操作。 问题报告后，微软工程和安全响应团队迅速调查并针对 Azure Cosmos DB Gremlin API 中的此漏洞制定了即时缓解措施，并在 48 小时内部署了该缓解措施以阻止此攻击媒介的入口点。微软进行了广泛的渗透测试以寻找类似的攻击媒介，未发现其他攻击途径。 微软实施了额外的平台加固措施，旨在增强底层认证架构并进一步改善整体安全态势。这些增强措施加强了服务间认证，并引入了进一步的网络保护、监控和检测能力，以改善 Azure Cosmos DB 的安全态势，同时保持可靠性、可用性和性能。 微软将继续加固平台，重申我们解决这些问题并加强客户保护的承诺。 ## 负责任的披露时间线 **2025 年 11 月 20 日** —— Wiz Research 向微软报告了该漏洞。 **2025 年 11 月 20 日** —— 微软确认收到。 **2025 年 11 月 22 日** —— 微软部署了热修复，并开始着手长期架构修复。 **2026 年 7 月** —— 微软完成所有区域的长期修复部署。 **2026 年 7 月 30 日** —— 公开披露。 ## 保持联系！ 大家好！我们是来自 Wiz Research 团队（@wiz_io（https://x.com/wiz_io））的 Yuval Avrahami（@yuvalavra（https://x.com/yuvalavra））、Sagi Tzadik（@sagitz_（https://x.com/sagitz_））、Nir Ohfeld（@nirohfeld（https://x.com/nirohfeld））、Ronen Shustin（@ronenshh（https://x.com/ronenshh））、Hillai Ben-Sasson（@hillai（https://x.com/hillai））和 Noam Malron（@noamsec（https://x.com/noamsec））。我们是一群资深白帽黑客，只有一个目标：让云成为对所有人都更安全的地方。我们主要专注于发现云中的新型攻击媒介，并揭示云供应商和服务提供商中的隔离问题。我们期待您的来信！欢迎通过 X（Twitter）或 [email protected] 与我们联系。