我本可访问 17 万亿条 Microsoft 记录

# 我本可以访问微软的 17 万亿条记录 来源：https://blog.faav.net/how-i-couldve-accessed-17-trillion-microsoft-records 2026 年 9 月 25 日 **微软各类数据集中，估计约有 17.3 万亿行已存储的数据行可以通过一个内部分析服务访问到，原因仅仅是该服务从未校验登录令牌上的签名。这个漏洞让我得以冒充管理员身份，在没有任何真实凭据的情况下提交未经授权的 SQL 查询。我只使用了表描述、元数据以及有限的样本行来了解潜在的影响范围。** 先说两点说明。我所描述的影响是假设性的。它指的是攻击者利用这种访问权限本来可以做到的事，但幸运的是，是我发现了这个漏洞、进行了上报，并且从未接触过任何客户数据或 PII。另外出于透明起见：微软对本文有编辑控制权，在发布前删减了部分内容和数据，并调整了对影响范围的描述方式。 微软就这一发现发表了如下声明： > “我们感谢有机会调查 Faav 报告的这些发现。他们的提交和协调漏洞披露帮助我们通过加固服务来更好地保护客户。我们重视并认可在 Microsoft Bug Bounty 计划条款下进行的安全研究，期待未来继续与 Faav 合作。” 大家好！我是 Faav。一年多前，我 15 岁的时候，发表了我第一篇关于微软的分析报告《*黑进微软任何一栋大楼：在 Microsoft Guest Check-In 中泄露 PII*》。我现在 16 岁了，而这篇的规模要大得多。 从那以后，我全身心投入到了漏洞赏金领域。这一年里，我一边上学一边零散地研究微软，在 Amazon、Google、Adobe 和其他一堆公司找到了各种漏洞。我还开始把 AI 引入我的漏洞挖掘流程，为此开发了 Antares，我专属的 AI 黑客机器人。 这个漏洞最初只是 Antares 无法跟进完的一个自动化线索。十天之后，在上完一个周五的课业、熬到深夜的一次直觉驱使下，它变成了我所发现过的最大的微软漏洞。 ## 发现 Titan API 2026 年 8 月 25 日，Antares 识别出一个名为 Titan 的微软内部服务。它的 Web 界面位于一个**VPN REQUIRED**页面之后，只有微软员工才能访问，所以前端是够不着的。但话说回来，一扇锁着的大门什么时候拦住过谁？ 图片 *非员工访问 Titan 前端时看到的“VPN REQUIRED”页面。* API 在前端没有出现在任何链接中，于是 Antares 搜索了微软的子域名，找到一个独立的端点，它解析到一个 Azure Cloud Services 主机。它的公开 Swagger 文件列出了四条路由： ``` /GetConfiguration /GetOnboardedTables /v2/Query /v2/Insert ``` Swagger 文档规定其中三条路由需要 Azure AD Bearer 认证。唯一的例外是 `/v2/Query`，而它恰好也是接受原生 SQL 的那一条。所以理所当然地，我就从那里开始试探。 这个查询需要一个 `tableName`，而 Swagger 没有给出任何示例值。我从 Wayback Machine 拉取了 Titan 登录页和隐私页的 2023 年快照，阅读其中存档的 Superset 配置后，恢复出了 56 个表定义，其中包含一个名为 `TestData` 的路由值。 图片 *当前 VPN 限制生效之前的 Titan 界面存档。* 我把这个值拿去对线上 API 测试： ``` POST /v2/Query HTTP/1.1 Host: [已脱敏] Content-Type: application/json {"query":"SELECT 1","tableName":"TestData","rowLimit":1} ``` 在没有 Authorization 头的情况下，它返回了 `401 Unauthorized`，于是 Antares 开始探测它是如何校验 JWT 的。 ## 破解 JWT 在接下来的十天里，当我还在处理另外几百个线索时，Antares 一直在回来研究 Titan，一次一个错误地逐层破解它的 JWT 校验。 它从我外部 Entra 测试租户中拿到的一个令牌开始，那是几个月前创建的，我一直在用来测试。Titan 返回了一个租户错误。把租户改成微软的之后，又出现了受众（audience）错误。改受众之后是应用白名单错误。最后改了应用 ID，才终于进入用户查找环节。 载荷（payload）一直在变，而签名却始终一模一样，Titan 却始终接受这些新的声明（claims），就像一个保安只核对每张身份证上的名字，却从不看照片。这就是它没有验证签名的第一个重大线索。 在我使用 AI 之前，我就手工利用过未签名的 JWT 绕过漏洞，所以我立刻认出了这个模式。 接下来，我用一个合成的 JWT 完全替换了原来的令牌，使用了这个头部： ``` {"alg":"none","typ":"JWT"} ``` 一个正常的已签名 JWT 有三个填满的部分：`header.payload.signature`。我的这个以一个单独的句号结尾，因为第三部分是空的： ``` base64url(header).base64url(payload). ``` Titan 根本没有校验签名。 载荷中使用的是 Titan 期望的值，但 `upn` 是我控制的： ``` { "aud": "[已脱敏]", "tid": "[已脱敏]", "appid": "[已脱敏]", "upn": "[email protected]", "oid": "00000000-0000-0000-0000-000000000000" } ``` 这通过了租户、受众和应用检查，然后返回了： Antares 当时正在这个线索上使用 Codex 和 Claude。因为 UPN 通常是邮件格式的 Entra 身份，这两个模型一直在测试占位符、公开的服务别名以及微软员工样式的地址。 这个未签名的令牌已经能够进入 Titan 的本地用户查找环节。Antares 只是找不到一个 Titan 认识的 UPN，所以它没有可用的查询，也无法展示影响，这个发现就停留在了线索阶段。 ### 尝试 `admin` 那个周五我都在做课业。等到 Titan 这条线索再次冒出来、我决定自己再看一眼的时候，已经是 9 月 5 日周六凌晨 1 点多了。 我试了几个看起来像有效 UPN 的值，也全部失败了。于是我不再猜测，开始思考后端到底拿这个声明做了什么。如果它是用 `upn` 去查本地的应用用户名呢？我把未签名令牌中的 `upn` 从邮件格式的身份改成了 `admin`。 结果只有数字 `1`，但在经历了十天的认证错误之后，这个 `1` 非常有意思。我终于以 Titan 管理员的身份执行了 SQL。 图片 *Titan 接受了这个未签名的管理员身份，并执行了该 SQL 查询。* 有意思的是，`admin` 显而易见，但显然不是一个有效的 UPN。正因为如此，Antares 从来不会猜到它。我之所以试它，是因为我不再把字段名照单全收，而是去想开发者在后端可能会怎么做。 Titan 把未签名的 `upn` 声明当作本地用户名使用。`admin` 解析到了本地用户 ID 1，该用户拥有 `Admin` 角色，SQL 也就跑起来了。有时候答案真的就是 `admin`。 ## 进入数据库内部 我首先试了 `TestData`，假设里面只会有假数据，结果也确实如此：测试数据库里的测试用例。但 `SHOW DATABASES` 显示出了其余的部分，其中包括 Titan 的平台元数据库。从那里我可以直接查询应用表。 元数据库里才是真正的数据。我首先发现的是一张活跃应用用户账户的表，包含姓名、电子邮箱地址和登录历史。在整个平台元数据中： - 约 25,000 条账户与邮箱记录。 - 17,990 条员工邮箱记录。 - 15,001 条员工组织记录。 - 355 个数据库配置。 - 20,979 条虚拟数据集 SQL 定义。 - 24,569 个仪表盘、425,891 张图表和 27,347 个数据集定义。 图片 *一条应用用户记录，包含身份识别信息和登录活动。密码字段存放的是 Superset 本地用户模型中的占位哈希值，并非真实的微软凭据。敏感值已脱敏。* Titan 的用户与使用情况目录暴露了与 Titan 相关员工的详细信息，如职位、部门和管理层级。这些数据只覆盖了微软员工的一个子集，而非完整的员工目录。它本可以帮攻击者策划有针对性的社会工程尝试，尽管我从未测试或演示过这一点。 到那一刻，这些员工数据看起来像是这个发现的主体。接着我注意到了一个独立的 Bing 分析数据源。 ## 验证一个有界的 Bing 分析样本 我从最新可用的 Bing 分析分区中请求了一行数据。第二次的单行查询返回了来自同一分区的另一条记录。这些有界的样本表明，Bing 的搜索分析数据可以通过该服务访问到。我把测试限定在两次单行样本之内。Bing 只是通过这种方式可达的数据库之一。 图片 *一条包含搜索、标识符和粗粒度位置字段的分析记录。我的查询只取了少数几个可用字段。请注意，位置值并不包含精确的用户位置，而是来自反向 IP 的国家或州一级信息。敏感值已脱敏。* 由于 MUID 出现在多个数据集中，跨服务关联用户活动是有可能的，尽管我实际上从未这样做。我没有识别出任何人、没有跨数据集关联记录，也没有基于我的样本构建任何画像。 在发现这些员工记录后，我立刻开始起草给 MSRC 的报告。看到 Bing 数据后，我立即就上报了。 ## 17.3 万亿行 总体规模是我最后才搞清楚的。 我用 `SELECT 1` 测试了存档配置中的全部 56 个路由值。其中 30 个仍然有效。每个路由值指向一个后端配置，每个配置包含一个或多个数据库，因此这 30 个有效值通过 24 个配置解析到了 17 个连接的分析数据库，涵盖 9,863 个唯一的表名。 没有一个方便的总计数。我手头有来自 17 个 ClickHouse 数据库的独立元数据计数，于是我把它们交给 AI 去求和，同时我去核查每个 `Distributed` 表是如何映射到其支撑集群的。我按每个分片一个副本来计数，并通过两条元数据路径验证总数：`system.tables.total_rows` 和活跃的 `system.parts`。 求和结果返回时没有格式化： 我不得不按三位一组拆开才读得出来： 十七万亿——这是一个基于元数据的存储估算，很可能包含了历史的、重复的以及派生的数据，但这个数字依然相当惊人。这就是通过这个绕过漏洞在技术上可达的环境的估计规模。 我的第一反应是副本被重复计算了，或者多打了一两个零。我又检查了一遍。并没有。两条路径返回的数字完全一致。 当时是凌晨 2 点。我想大喊一声，或者至少说出声来，但我父母已经睡了。于是我只能坐在那里盯着 `17,333,335,124,315`，又把数学核了一遍。 ## 结语 我从这次经历中得到两点收获。 第一，AI 与人类直觉在这里产生了叠加效应。Antares 完成了十天的工作，让我不必再去做：枚举子域名、一个字段一个字段地啃 JWT 错误消息、绘制整个攻击面，以及让这个未签名的令牌通过四层校验。它做不到的是意识到 `upn` 其实根本不是一个 UPN。回过头看，那个 `User not found` 错误本该是线索。那个构造出来的 JWT 已经通过了 Titan 的认证检查，它只是在尝试把 `upn` 匹配到它自己的某个用户而已。Antares 单靠自己走不到这一步，我也一样。是它的坚持不懈，加上人类的一次直觉，才让这个发现成为可能。 第二，关于这个漏洞本身。Titan 校验了 JWT 的内容（租户、受众、应用 ID、用户），但从未验证签名——而签名是任何认证检查中最关键的部分。这些认证检查感觉就像一家酒店，每扇门都配有能正常工作的门禁读卡器，但任何一张房卡都能打开任何房间。尽管应用里所有访问控制逻辑都存在，唯独缺失的这一环让它们全都失去了意义。如果你是读到这里的开发者（或编码代理），这篇文章最重要的启示就是：在构建认证功能时，务必要把签名验证放在首位。 ## 时间线 - 2026/08/25 - Antares 发现了 Titan 的公开 API，并将其保存为一条线索。我从 Wayback Machine 恢复了存档的 Superset 配置及其 56 个表定义。 - 2026/08/25–2026/09/05 - Antares 反复尝试突破 Titan 的 JWT 校验，并测试邮件格式的 UPN。 - 2026/09/05 - 我重新回到这个请求，把 `upn` 改成 `admin`，让 SQL 查询成功执行。 - 2026/09/05 - 在未导出底层记录的情况下确认可以访问 30 个有效的路由目标和 17 个连接的分析数据库，随后将该漏洞上报给 MSRC。案件编号 144051 于当天建立。 - 2026/09/06–2026/09/08 - MSRC 要求我停止测试，并索取我的 IP 地址，以确认除安全研究之外没有其他活动。他们确认该问题已被列为优先处理事项。 - 2026/09/09 - API 端点已被限制访问。MSRC 表示，该报告促成了立即的调查与修复，以消除剩余的暴露。 - 2026/09/17 - 获得 5,000 美元奖励。 - 2026/09/22 - 与微软会面，讨论该发现并协调披露事宜。 - 2026/09/22–2026/09/24 - 应微软要求重新修改本篇文章，在发布前对影响的措辞进行了调整，并删除了部分章节和数据。