滥用 Entra OAuth：趣味探索与内部 Microsoft 应用访问

一名安全研究员发现，由于微软 Entra ID 中的多租户应用程序未能正确验证访问令牌的颁发者（issuer），导致存在严重的配置错误。通过利用此漏洞，研究员使用自己的租户账户成功登录并访问了超过 22 个微软内部服务，包括工程门户、安全情报平台和媒体创建服务。这一发现揭示了当应用程序逻辑依赖错误的认证授权方时所带来的巨大风险。

意外的发现

起初，研究员只是偶然尝试用自己的微软账户登录微软内部的短链接服务 aka.ms，但以失败告终。然而，这个过程中的一次跳转将他引向了另一个域名 eng.ms，这是一个工程门户。

这次他惊奇地发现，系统弹出了一个授权请求，允许该应用访问他的基本个人信息。在同意后，尽管页面显示服务器错误，但这暗示他或许可以访问这个应用。

    • 通过进一步的子域名枚举，他找到了 rescue.eng.ms。
    • 这一次，他使用自己的 Microsoft 365 账户成功登录了该门户。
    • 这个名为 “Engineering Hub” 的门户是为微软工程师设计的内部平台。一次简单的 “password” 搜索就返回了超过 13,000 条结果，证明了他不应拥有访问权限。

在意识到问题的严重性后，研究员立即停止了探索，并向微软安全响应中心（MSRC）报告了此问题。

漏洞原理：多租户应用的认证缺陷

要理解这个漏洞，需要了解 Entra ID 如何处理多租户应用的认证。

    • 单租户应用： 只接受在应用注册的租户内的用户。
    • 多租户应用： 接受来自任何租户的用户登录。

开发者在配置应用时，需要指定认证服务器的地址。多租户应用通常使用 https://login.microsoftonline.com/common 作为端点，这允许任何租户的用户进行认证。

问题在于，被攻破的 “Engineering Hub” 被错误地配置为多租户应用。这导致了以下认证流程：

    • 研究员使用自己的账户登录。
    • 系统将他重定向到 /common 端点，并针对他自己的租户进行认证。
    • 认证成功后，他的租户颁发了一个访问令牌。
    • 该应用的后端逻辑没有检查令牌的颁发者（iss 声明）或租户 ID（tid 声明），错误地接受了这个由外部租户颁发的令牌，从而授予了访问权限。

简而言之，应用被配置为信任任何地方的认证，却没有验证这个“地方”是否是它应该信任的微软内部租户。

扩大攻击面

为了验证此问题是否普遍存在，研究员对微软旗下的多个域名（如 microsoft.com, azure.com, office.com 等）进行了大规模的子域名枚举，并分析了使用 Entra ID 认证的应用。

    • 共发现 1,406 个使用 Entra ID 认证的应用。
    • 其中 176 个被配置为多租户应用。

研究员发现，可以通过修改认证请求，强制一个原本设计为单租户登录流程的应用（使用 /<tenantid> 端点）去使用 /common 端点，从而利用自己的租户进行认证。通过编写脚本和一些绕过技巧（如直接创建服务主体以跳过授权同意流程），他得以系统性地测试这些多租户应用。

访问内部应用

最终，研究员发现 22 个微软内部应用存在此漏洞，并暴露了敏感的内部数据和功能。

关键应用示例

  • Security Intelligence Platform:

    一个包含安全情报数据集的平台。虽然访问数据集需要管理员批准，但研究员能够在该平台中搜索微软的整个租户，查找服务主体名称和用户账户。他还发现了一个包含用户登录授权码的日志文件。

  • Media Creation Service:

    一个用于构建“媒体”的服务，日志文件暗示这可能与 Windows 操作系统的构建有关。研究员甚至发现了一个可能用于生成许可证密钥的私钥文件，并获得了在该服务构建基础设施上实现远程代码执行（RCE）的权限。

  • 其他内部服务:

      • 负责AI Ops的平台
      • 微软内部计费账户门户
      • 安全设备门户
      • Azure 订阅中心 API

这项研究突显了在大型环境中，一个单一的配置错误可能带来的连锁风险。当应用开发者和负责注册应用的团队之间存在责任分工时，双方都可能认为自己的部分已经正确设置，从而导致安全盲区。

您是否也存在风险？

这个漏洞并非微软独有，任何使用 Entra ID 的组织都可能受到影响。根据研究员的调查，他自己客户中就有 2% 受到了影响。

如何防范：

    • 谨慎使用多租户应用： 仅在绝对必要时才将应用配置为多租户。
    • 在应用逻辑中验证令牌： 如果必须使用多租户应用，务必在后端代码中检查访问令牌的 iss（颁发者）或 tid（租户 ID）声明，确保只接受来自可信租户的令牌。

研究员提供了一个 PowerShell 脚本，帮助组织快速识别其环境中的所有多租户应用及其重定向 URI，以便进行安全审查。

漏洞报告与奖励

研究员在 2024 年 11 月至 2025 年 1 月期间向 MSRC 提交了发现。微软迅速成立项目组进行修复，大部分问题在两个月内得到解决。作为奖励，研究员登上了 MSRC 第一季度贡献者排行榜的第三名。

有趣的是，在研究过程中，他发现了一个名为“Rewards Support Tool”的内部应用，该应用似乎允许操作奖励和回扣。他在文章末尾幽默地暗示，通过这个工具，他或许可以自己给自己“发奖金”。