微软 Titan 跳过 JWT 签名校验：16岁研究员靠 admin 直达 17 万亿行数据

导语：自称 Faav 的 16 岁安全研究员于 9 月 22 日公开披露：微软内部数据分析服务 Titan 在 JWT 校验中完全跳过签名验证，仅凭一份伪造 token 即可拿到管理员身份并直接执行 SQL，相关接口可触达 17 个 ClickHouse 数据库、约 17.3 万亿行记录。微软已于 9 月 9 日封堵该接口。

事件背景

Faav 是 2025 年起活跃在多家厂商漏洞赏金平台上的安全研究员，这次发现借助了他自研的 AI 工具 Antares。8 月 25 日，Antares 扫描微软子域名时锁定了一个 Azure Cloud Services 下的内部接口 Titan。其前端被 VPN REQUIRED 页面保护，但配套的 Swagger 文档意外暴露在公网，列出了 /GetConfiguration、/GetOnboardedTables、/v2/Query、/v2/Insert 四个路由。其中 /v2/Query 是唯一接受原始 SQL 的入口，也是唯一未标注 Azure AD 鉴权的接口。

研究人员通过 Wayback Machine 找到了 Titan 旧版 Superset 配置的 56 个表定义，其中一个名为 TestData 的 routing 值成为突破口。

签名验证缺失：从异常到 admin

Titan 对 JWT 的处理出现反常：替换 audience、tenant、appid 时返回的错误信息逐层变化，但签名段从未参与判定。Faav 随后将 token 完全替换为一份手工构造的 JWT：

{"alg":"none","typ":"JWT"}

后续 payload 采用“base64url(header).base64url(payload)”外加一个空段的格式，第三段——本应最关键的签名——被留空。Titan 完整接受了它。

更关键的一步是跳出 AI 的常规猜测。Antares 连续十天尝试邮箱形式的 UPN 都没有成功；9 月 5 日凌晨，Faav 人工介入后把 upn 改为字符串 admin，绕过了本应是邮件格式的约束，直接命中后端本地用户 admin（ID 为 1），取得 Admin 角色，并返回 SELECT 1 的结果。

admin 这个值在 UPN 字段中过于“显眼”，但也正因为它不符合常规邮箱猜测模式，才被 AI 一直忽略。研究员最终明确：Titan 把 upn 当作本地用户名查询，而不是交给 Entra 解析用户身份。

数据规模与暴露面

拿到管理员身份后，SHOW DATABASES 列出了 Titan 的全部后端资源。30 个有效的 routing 值映射到 24 个配置、17 个相互连通的 ClickHouse 数据库，共计 9863 个独立表。Faav 通过 system.tables.total_rows 与 system.parts 两条元数据路径交叉验证，得出总量约为 17,333,335,124,315 行——17.3 万亿级别。

可触达的数据范围包括：

• 平台元数据库中的约 25000 条账户与邮箱记录
• 17990 条微软员工邮箱记录
• 15001 条员工组织架构数据
• 24569 个仪表盘、425891 个图表、27347 个数据集定义
• Bing 搜索分析分区中的样本行（含 MUID 等标识符）

其中包含 Bing 搜索分析的样本，Bing 是 Titan 可达的多个数据源之一。研究员强调，他只请求了两条单行样本以确认可达性，并未读取任何客户数据或 PII，也未尝试跨数据集关联分析。

漏洞处置与披露时间线

• 08/25 — Antares 锁定 Titan 公开 API，Wayback Machine 恢复 56 个表定义
• 08/25–09/05 — Antares 反复试探 JWT 字段，AI 工具持续受困于 UPN 格式假设
• 09/05 — Faav 改为 admin 字符串，触发可执行 SQL，验证 30 个 routing 值后当晚报告 MSRC，工单号 144051
• 09/06–09/08 — MSRC 要求停止测试并请求研究员 IP 用于回溯，确认仅有授权范围内的研究行为
• 09/09 — API 接口被封堵
• 09/17 — 颁发 5000 美元赏金
• 09/22 — 双方共同重排披露稿件，部分细节与图表被删减后发布

微软对本次披露给出官方回应：感谢 Faav 的提交与协同披露，认为相关研究帮助其强化服务，并期待未来继续合作。

技术启示

这个漏洞的本质，是认证链条上最致命的一环被忽略：签名校验。Titan 对 tenant、audience、application、user 四类 claim 都做了完整比对，却唯独跳过了签名这个锚点。研究员在文末的比喻相当直接：一栋酒店每扇门都装了读卡器，但任意一张门卡都能打开任意房间，再复杂的门禁逻辑也因此失效。

对于开发者与正在编写认证逻辑的智能体而言，这一案例的提示非常明确：

• 永远优先校验签名，再处理其他 claim
• 不要把“看起来合法的字段值”等同于“通过认证的身份”
• 内部服务即便前端受 VPN 保护，也必须假设 API 端点会被独立发现
• AI 代理在枚举阶段有优势，但在跳出字段名“显然含义”上仍需要人介入

而对于企业一方，17 万亿行这个数字本身也在提醒：当一个内部分析平台同时承载 Bing 数据与员工目录时，签名验证这种基础缺陷的代价会被无限放大。