Wiz 机构 如何在 Azure活动目录 中发现一个通用的错误配置，该错误配置损害了多个 微软 应用程序，包括 Bing 后台管理系统

执行总结

• Wiz 机构 在 Azure活动目录 中发现了一种新的攻击向量，它会将配置错误的应用程序暴露给未经授权的访问。

• 这些错误配置相当普遍，尤其是在 Azure App Services 和 Azure Functions 中。根据我们的扫描，大约 25% 的多租户应用程序被证明是易受攻击的。

• 我们发现了几个具有高影响力且易受攻击的 微软 应用程序。其中一个应用程序是为 Bing.com 提供支持内容管理系统 (CMS)，使我们不仅可以修改搜索结果，还可以对 Bing 用户发起高影响 XSS 攻击。这些攻击可能会损害用户的个人数据，包括 Outlook 电子邮件和 SharePoint 文档。

• 所有问题都已报告给 微软安全响应中心 团队。它修复了易受攻击的应用程序，更新了客户指南，并修补了一些 AAD 功能以减少客户风险。

• 要检查您的环境是否受到此错误配置的影响，请参阅博客的“客户修复指南”部分。

介绍

从 Amazon Cognito 到 Google Firebase 或 微软 Azure活动目录，市场上有许多基于云的身份提供商可满足各种业务需求。每个 IdP 的复杂性都会导致配置错误，威胁行为者可能会利用这些错误配置来破坏组织的生产环境。

在这篇博文中，我们将展示 微软 本身如何成为 AAD 配置挑战的牺牲品，并无意中将内部应用程序暴露给外部攻击者。这些应用程序允许我们查看和更改各种类型的敏感 微软 数据。在一个特定案例中，我们能够操纵 Bing.com 上的搜索结果并对 Bing 用户执行 XSS 攻击，从而可能暴露客户的 Office 365 数据，例如电子邮件、聊天和文档。此博客还将提供有关错误配置的详细信息，以及如何在您的环境中检测和缓解它们。

Azure 活动目录 (AAD)

微软 在 Azure 中提供自己的 SSO 服务 AAD，这是在 Azure App Services 或 Azure Functions 中创建的应用程序最常见的身份验证机制。AAD 提供不同类型的帐户访问：单租户、多租户、个人帐户或后两者的组合。单租户应用程序只允许来自同一租户的用户为应用程序颁发 OAuth 令牌。另一方面，多租户应用程序允许任何 Azure 租户为其颁发 OAuth 令牌。因此，应用程序开发人员必须检查其代码中的令牌并决定应允许哪个用户登录。

在 Azure App Services 和 Azure Functions 的案例中，我们看到了共享责任混乱的教科书级示例。这些托管服务使用户能够通过单击按钮添加身份验证功能，这对应用程序所有者来说是一个看似顺利的过程。但是，该服务仅确保令牌的有效性。应用程序所有者不清楚他们有责任通过 OAuth 声明验证用户身份并相应地提供访问权限。

使用单租户身份验证，影响仅限于应用程序的租户——来自同一租户的所有用户都可以连接到应用程序。

但是对于多租户应用程序，暴露的范围非常广泛——如果没有适当的验证，任何 Azure 用户都可以登录到应用程序。

这种复杂的架构对开发人员来说并不总是显而易见的，验证最终用户令牌的责任也不明确。因此，配置和验证错误非常普遍。

在认识到这些问题及其潜在影响后，我们开始扫描互联网以查找暴露的应用程序。结果让我们感到惊讶：我们扫描的所有多租户应用程序中有 25% 容易受到身份验证绕过攻击。

以下关于“Bing Trivia”应用程序（我们称之为“#BingBang”）的案例研究说明了 微软 本身如何成为错误配置陷阱的受害者，并将其最关键的应用程序之一暴露给互联网上的任何人。

BingBang 案例研究

第 1 部分 – 侦察

为了衡量这种错误配置的常见程度，我们开始扫描 Azure App Services 和 Azure Functions 以查找暴露的端点。扫描输出了许多潜在易受攻击的网站，因此为了缩小研究范围，我们决定专注于 微软 自己的租户。

我们发现了几个 微软 应用程序，但第一个引起我们注意的域是bingtrivia.azurewebsites.net. 鉴于 Bing 是当今非常受欢迎的产品，我们对与之相关的任何事物都很感兴趣。为了验证曝光，我们在自己的租户中创建了一个名为“Wiz Research”的新用户，并尝试使用它登录 Bing Trivia。

尽管我们不属于 微软 租户，但我们成功登录并登陆了 Bing Trivia 主页。

我们开始检查我们面前的页面。乍一看，它似乎有点不起眼——只是一个简单的 CMS，里面塞满了很多东西。要确定系统是否有意开放，我们需要了解其目的。

鉴于该应用程序被命名为“Bing Trivia”，我们假设它是为琐碎内容而设计的。然而，在浏览该应用程序时，我们注意到几个与必应核心内容相关的有趣部分。这些部分之一是“轮播”部分，其中包含一个表格，其中包含出现在 Bing 上的搜索结果建议。另一部分展示了当天出现在 Bing.com 主页上的提问和背景图片。这就提出了一个问题——这个面板能让我们修改 Bing 的搜索结果吗？

第 2 部分 – 更改搜索结果

为了验证我们控制 Bing 搜索结果的能力，我们在 CMS 中选择了一个轮播并稍微改变了它的内容。我们想做一个小改动，这样很容易恢复。我们选择了“best soundtracks”查询，它返回了一个高度推荐的电影配乐列表；然后，我们继续将第一项“Dune (2021) ”更改为我们个人最喜欢的“Hackers (1995) ”，并保存我们的编辑。

令我们惊讶的是，我们的新结果立即出现在 Bing.com 上，连同我们的新标题、缩略图和任意链接！

这证明我们可以控制 Bing 的搜索结果，而且正如我们稍后确认的那样，这种控制也扩展到了 Bing 的主页内容。

为了确定攻击面的广度，我们随后决定利用此访问权限并使用无害负载的样本测试 XSS 可行性。有效载荷也按预期运行，因此我们迅速恢复了我们的更改，并立即向 微软 报告了我们的发现。

第 3 部分——攻击 Bing 用户

在与 微软 合作编写报告时，我们开始调查 XSS 的影响。我们看到 Bing 有一个“工作”部分，允许您搜索您的组织目录；在检查此功能时，我们意识到它基于 Office 365 API，Bing 使用主机名business.bing.com进行与 Office 相关的通信。

这确实激起了我们的兴趣，因为许多组织使用 Office 365 来存储他们最敏感的业务数据。一个特定节点为 Office 365 API 创建了 JWT 令牌，因此我们通过此节点生成了一个新的 XSS 负载：

然后，我们针对我们的旧注入点测试了这个有效负载，并从我们的“受害者”用户（在本例中为我们的研究账户）获得了一个有效令牌。

这个令牌使我们作为“攻击者”能够获取受害者的 Office 365 数据，包括 Outlook 电子邮件、日历、Teams 消息、SharePoint 文档和 OneDrive 文件。在这里我们可以看到攻击者的计算机，成功地从受害者的收件箱中读取电子邮件：

具有相同访问权限的恶意行为者可以利用相同的负载劫持最流行的搜索结果，并泄露数百万用户的敏感数据。根据 SimilarWeb 的数据，Bing 是世界上访问量排名第 27 的网站，每月的页面浏览量超过 10 亿次。换句话说，数百万用户可能已经暴露于恶意搜索结果和 Office 365 数据窃取之下。

其他易受攻击的应用程序

除了 Bing Trivia 应用程序之外，我们还发现了其他几个 微软 内部应用程序，它们具有类似的错误配置并且暴露给任何尝试登录的人：

Mag News：MSN Newsletter 的控制面板，能够从受信任的 微软 电子邮件向大量受众发送任意电子邮件。

CNS API：微软 Central Notification Service 的 API，能够读取内部通知并将其发送给 微软 开发人员。

Contact Center：微软 Contact Center 的 API，控制 微软 客户代表的呼叫中心座席。

PoliCheck：“PoliCheck”是一个微软内部工具，用于检查微软代码中的禁用词。该应用程序本质上是 PoliCheck 规则的集中式数据库。规则包括 100 多种语言的词语，从亵渎和诽谤到地缘政治和法律上有争议的问题。

Power Automate 博客：一个 WordPress 管理面板，控制托管在powerautomate.microsoft.com. 该面板允许我们创建和编辑具有任意 HTML 内容的帖子，并将它们发布到受信任的 microsoft.com 域。

COSMOS：一个文件管理系统，管理超过 4 艾字节 (!) 的 微软 内部文件。COSMOS 按微软部门和团队对文件进行分类，并支持在应用程序内列出、阅读和编辑文件。

所有这些问题都已报告给 微软。微软 团队及时修复了它们，并授予我们 40,000 美元的赏金。尽管这些服务不属于赏金计划的范围，但 微软 团队的决定基于我们发现的 AAD 的附加产品和指南改进。

客户补救指南

我受到影响了吗？

我们在这项研究中发现的问题可能会影响任何满足这种条件的组织：拥有已配置为多租户但缺乏足够授权检查的Azure活动目录应用程序。

根据我们扫描的数据，我们评估在 Azure App Service 和 Azure Functions 应用程序中暴露的情况要普遍得多，开发人员不清楚验证责任。

我如何检测我的环境中的这些问题？

管理员可以使用 Azure 门户查询他们的 AAD 服务主体并查找任何配置为允许多租户访问的服务主体。这些应该出现在每个应用程序页面的“应用程序注册”或“身份验证”部分下。

也可以使用 Azure CLI 查询多租户应用程序：

az ad app list --filter "(signinaudience eq 'AzureADMultipleOrgs' or
signinaudience eq 'AzureADandPersonal微软Account')" --query "[?web && 
web.homePageUrl].{AppName:displayName, AppID:appId, AppURL:web.homePageUrl}" 

要验证应用程序是否易受攻击，请在浏览器用一个来自另外Azure租户的用户登录你的应用程序。如果此登录成功，并且你的应用不打算暴露给其他 Azure 租户，则该应用容易受到攻击。

我该如何解决这些问题？

如果您的应用程序不需要多租户，只需转到您的应用程序页面并切换到单租户身份验证。

如果您确实需要授予外部租户访问权限，您可以通过多种方式来补救您的风险。

如果您的应用程序需要特定外部租户上可用，您可以 要求用户分配 或 使用条件访问策略。

否则，您将需要通过在应用程序代码中执行令牌检查来实现基于声明的授权逻辑。没有万能的解决方案，您应该咨询您的工程团队以找到适合您的应用程序的解决方案。但是，建议事先查阅相关的微软文档。

我如何知道此问题是否已被利用？

据微软称，Azure活动目录日志不足以提供对过去活动的追溯。推荐的解决方案是查看您的应用程序日志并查找任何可疑的登录。

引申

我们将此问题视为云暴露的案例。云服务提供商允许用户通过单击按钮向外部公开他们的许多云资源。同样的事情也发生在这里，用户可能会勾选错误的框并意外公开他们的应用程序。

此外，Azure App Service 和 Azure Functions 的用户可能并不完全了解谁负责验证访问令牌。通过 Azure 门户启用身份验证的用户可能会认为他们的应用程序是完全安全的。但是，用户必须在其应用程序代码中实施额外的令牌验证和身份验证，以确保身份验证安全。

概括

在此博客中，我们介绍了 OAuth 配置错误的真实示例，重点是微软自己的应用程序。根据我们的发现，我们得出结论，这个问题既容易被利用又具有严重影响。这就是为什么我们敦促拥有多租户应用程序的任何人使用上面提供的指南扫描他们的环境。

披露时间表

• 2023 年 1 月 31 日——Wiz 机构 向 微软安全响应中心 报告了 Bing 问题

• 2023 年 1 月 31 日——微软安全响应中心 发布对 Bing 应用程序的初步修复

• 2023 年 2 月 25 日——Wiz 机构 向 微软安全响应中心 报告了其他易受攻击的应用程序

• 2023 年 2 月 27 日——微软安全响应中心 开始为上述应用程序发布修复程序

• 2023 年 3 月 20 日——微软安全响应中心 声明所有报告的应用程序现已修复

• 2023 年 3 月 28 日——微软安全响应中心 向 Wiz 机构 提供 40,000 美元的漏洞赏金

• 2023 年 3 月 29 日——公开披露