文章摘要
作者发现了一个严重的Entra ID漏洞，利用未记录的“Actor tokens”和Azure AD Graph API的验证缺陷，可以在任何Entra ID租户中冒充任何用户，包括全局管理员，且不受条件访问等安全策略的限制，几乎可以完全控制所有租户。
文章总结
标题：一“令”统天下——通过Actor令牌获取所有Entra ID租户的全局管理员权限
主要内容：
在准备今年7月的Black Hat和DEF CON演讲时，我发现了迄今为止最具影响力的Entra ID漏洞。该漏洞可能允许我入侵全球几乎所有的Entra ID租户（除了国家云部署中的租户）。该漏洞由两个部分组成：一是微软后端用于服务间通信的未公开的“Actor令牌”，二是Azure AD Graph API（旧版）在验证来源租户时存在的一个关键缺陷，导致这些令牌可以用于跨租户访问。
这意味着，通过在我的实验室租户中请求的令牌，我可以以任何用户的身份（包括全局管理员）在任何其他租户中进行身份验证。由于Actor令牌的性质，它们不受条件访问等安全策略的限制，因此没有任何设置可以缓解这一漏洞。Azure AD Graph API是管理Azure AD / Entra ID核心服务的旧版API，访问该API可以对租户进行任何全局管理员可以进行的修改，包括接管或创建新身份并授予其任何权限。通过这些被入侵的身份，攻击者还可以进一步访问Microsoft 365和Azure。
我当天向微软安全响应中心（MSRC）报告了该漏洞。微软在报告提交后的几天内修复了该漏洞，并推出了进一步的缓解措施，阻止应用程序为Azure AD Graph API请求这些Actor令牌。微软还为该漏洞发布了CVE-2025-55241。
影响：
这些令牌允许完全访问任何租户中的Azure AD Graph API。请求Actor令牌不会生成日志，即使生成了日志，它们也会在我的租户中生成，而不是在受害者租户中，这意味着这些令牌的存在没有任何记录。此外，Azure AD Graph API没有API级别的日志记录，而其继任者Microsoft Graph则具备这一功能。由于没有API级别的日志记录，以下Entra ID数据可以在没有任何痕迹的情况下被访问：
- 用户信息，包括存储在Entra ID中的所有个人详细信息。
- 组和角色信息。
- 租户设置和（条件访问）策略。
- 应用程序、服务主体以及任何应用程序权限分配。
- 设备信息和同步到Entra ID的BitLocker密钥。
通过冒充受害者租户中的普通用户，可以访问这些信息。如果全局管理员被冒充，攻击者还可以修改上述任何对象和设置，从而导致租户完全被入侵，访问任何使用Entra ID进行身份验证的服务，如SharePoint Online和Exchange Online，以及托管在Azure中的任何资源。
技术细节：
Actor令牌是由“访问控制服务”颁发的令牌，用于微软后端服务间的通信。这些令牌的有效期为24小时，且无法撤销。它们完全绕过了条件访问的任何限制，且没有任何日志记录。微软使用这些令牌在其后端进行服务间通信（S2S），如果这些令牌泄露，攻击者可以在没有任何有用遥测或缓解措施的情况下访问整个租户中的所有数据。
跨租户入侵的关键缺陷：
在测试过程中，我发现Azure AD Graph API在验证令牌时未能正确检查租户ID，导致攻击者可以使用一个租户中的Actor令牌访问另一个租户中的数据。只要攻击者知道目标租户的租户ID和用户的netId，就可以通过伪造的令牌访问目标租户中的任何数据。
实际利用：
通过该漏洞，攻击者可以入侵任何Entra ID租户。具体步骤如下：
- 找到目标租户的租户ID，这可以通过基于域名的公共API完成。
- 找到目标租户中普通用户的有效
netId。 - 使用攻击者租户中的Actor令牌，伪造目标租户的租户ID和用户
netId的令牌。 - 列出目标租户中的所有全局管理员及其
netId。 - 伪造全局管理员账户的令牌。
- 通过Azure AD Graph API执行任何读写操作。
检测：
虽然通过Azure AD Graph查询数据不会留下任何日志，但修改数据通常会生成审计日志。如果使用Actor令牌进行修改，日志会显示一些异常信息，例如日志中会记录被冒充的全局管理员的UPN，但显示名称为Exchange。这为防御者提供了一个明显的线索。
结论：
该博客讨论了一个Azure AD Graph API中的关键令牌验证失败漏洞。虽然漏洞本身是令牌处理中的一个严重疏忽，但Actor令牌的整个设计缺乏几乎所有的安全控制措施，导致了如此大的影响和有限的遥测。感谢MSRC的工作人员迅速处理了漏洞报告，并推出了修复措施，阻止了Actor令牌的滥用。
评论总结
关于安全漏洞的严重性：
- 评论5认为安全措施非常薄弱，甚至像是故意留下的后门：“Security so weak, it seems like you discovered an intentional backdoor.”（安全措施如此薄弱，似乎你发现了一个故意的后门。）
- 评论6认为这是一个非常严重的安全漏洞，可能支付了高额赏金：“it’s hard to think of a more damning security flaw.”（很难想象还有比这更严重的安全漏洞。）
对设计缺陷的质疑：
- 评论3质疑设计者是否考虑了令牌中的“tenant”字段的用途：“One wonders whether those who designed all this ever considered what that field in the token is for.”（人们不禁怀疑设计者是否考虑过令牌中这个字段的用途。）
- 评论3还指出“tenant”一词暗示了用户只是租户，而“房东”始终拥有钥匙：“you’re just renting, and the ‘landlord’ always has the keys.”（你只是租户，而“房东”始终拥有钥匙。）
对技术选择的反思：
- 评论7质疑为什么需要Entra，认为Kerberos已经足够稳定和安全：“after 36 years kerberos seems pretty stable, secure, and well supported finally. why do we need Entra?”（经过36年，Kerberos似乎终于变得稳定、安全且得到良好支持。为什么我们还需要Entra？）
对微软和Azure的批评：
- 评论8对微软和Azure的安全问题表示不意外：“Microsoft, Azure, why am I not surprised?”（微软，Azure，我为什么一点都不意外？）
对漏洞利用的反思：
- 评论4提到自己曾接近利用这个漏洞，认为这是一个明显的漏洞：“it really seemed so obvious of an exploit!”（这看起来真的是一个非常明显的漏洞！）
对权限管理的惊讶：
- 评论2对拥有所有企业系统的钥匙表示惊讶：“Wow the keys to all the enterprise castles! That’s wild!”（哇，拥有所有企业城堡的钥匙！这太疯狂了！）
总结：评论主要围绕安全漏洞的严重性、设计缺陷、技术选择以及对微软和Azure的批评展开。多数评论认为这是一个非常严重且明显的漏洞，甚至质疑其是否为故意留下的后门。同时，也有评论对现有技术的稳定性和必要性提出了反思。