AutoWarp是Azure自动化服务中的一个关键漏洞，它允许未经授权的用户访问使用该服务的其他Azure客户帐户。这种攻击可能意味着完全控制属于目标帐户的资源和数据，具体取决于客户分配的权限。

研究表明，有多家大公司正在使用这项服务，并可能被访问，从而造成数十亿美的损失。研究人员直接向微软报告了这个漏洞，现在已经修复，所有受影响的客户都已得到通知。

在此漏洞被修复之前，如果你已经使用了Azure Automation服务或者你的自动化帐户中的Managed Identity功能已启用(默认情况下已启用)，你很容易受到AutoWarp攻击。

AutoWarp被发现的时间表

2021 年12月6日：研究人员已经开始研究，发现了该漏洞，并将其报告给了微软。

2021年12月7日：研究人员发现了面临风险的大公司(包括一家全球电信公司、两家汽车制造商、一家银行集团、四大会计师事务所等)。

2021年12月10日：微软修复了该漏洞，并开始寻找这种攻击的其他变体。

2022年3月7日：微软调查结论公布。

微软的声明如下：“研究人员要感谢Orca安全公司的Yanir Tsarimi，是他报告了这个漏洞，并与微软安全响应中心(MSRC)在漏洞协调披露(CVD)下合作，帮助维护微软客户的安全。”

什么是 Microsoft Azure自动化服务?

 Microsoft Azure自动化服务允许客户以托管的方式执行自动化代码。你可以安排作业、提供输入和输出等。每个客户的自动化代码运行在一个沙箱中，与在同一虚拟机上执行的其他客户的代码隔离开来。

AutoWarp：Azure自动化安全漏洞

研究人员发现了一个严重的漏洞，它允许研究人员与管理其他客户沙盒的内部服务器进行交互。研究人员设法通过该服务器获得了其他客户账户的身份验证令牌。有恶意意图的人可能会不断地获取令牌，并通过每个令牌将攻击范围扩大到更多的 Azure 客户。

通过浏览Azure服务列表，研究人员可以寻找到下一个要研究的服务。在“管理和治理”类别下看到“自动化帐户”让我措手不及。我以为它是某种允许我自动化控制Azure帐户的服务。

在创建了我的第一个自动化帐户后，我意识到Azure automation是一个非常标准的自动化脚本服务。你可以上传你的Python或PowerShell脚本以在Azure上执行。

研究人员所做的第一件事就是探索文件系统，看看能找到什么有趣的东西。我从我的自动化脚本中启动了一个反向 shell，使针对服务器的工作更加顺畅。

使用 Python 设置反向 shell 不会出现漏洞。然而，当我执行一些常见的命令，如tasklist，我却收到一条错误消息，提示找不到它们。显然，负责定义操作系统应尝试执行哪些文件扩展名的 PathExt 环境变量被设置为一个奇怪的值。通常，它包含 .exe 文件扩展名，但在我们的例子中不包含。只有 .CPL 是存在的，它是 Windows 控制面板项目的文件扩展名。即使我尝试使用 tasklist.exe 列出正在运行的进程，它也给了我一个我以前从未见过的消息。看起来可能有什么事情发生了……

当我查看 C:\ 驱动器时，首先引起我注意的两件事是“Orchestrator”和“temp”目录。 Orchestrator 目录包含许多 DLL 和 EXE。我看到带有“sandbox”的文件名，直觉上我明白这个目录包含我们正在运行的沙箱。临时目录包含另一个名为“diags”的目录，并且有一个“trace.log”文件。

日志文件非常适合研究。在许多情况下，日志提供了非常简洁和重要的信息。你基本上有机会在日记中窥探开发人员认为重要的内容。对我来说幸运的是，这是一个非常好的日志文件。这在第 7 行很早就出现了：

没有什么比发现你的目标暴露了一个web服务更令人兴奋的了。特别是当它是本地的，并且是在一个看似随机的高端口上。

这只是向我发出了危险信号。这就是我通常所说的“掩护”——为掩盖某些技术限制而做出的软件决策。为什么会选择这么高的随机端口？因为其他端口被占用。

我使用 cURL 向 URL 发出了 HTTP 请求。虽然它起作用了，但没有提供太多关于正在发生的事情的信息。我还尝试访问下一个端口(40009、40010等)。他们中的一些人对我做出了回应，这立即证实了我的怀疑。日志清楚地表明，Web 服务是由我之前看到的协调器管理的，所以我必须了解发生了什么。这个web服务是什么?

深入了解 Azure 自动化代码

下载了orchestrator的文件后，我启动了 ILSpy（.NET 反编译器）并开始寻找他们称之为“资产检索 Web 服务”的代码。我查看了设置HTTP路由的方法，真正弹出的是“/oauth2/token”和“/metadata/identity/oauth2/token”映射到一个名为“MSIController”的控制器。我当时不知道的是，MSI 是“Managed Service Identity”的首字母缩写。很有趣，对吧？

我之前没有接触过 .NET Web 开发或研究，所以我从代码中推断这些路由映射到“MSIController”类，如果你熟悉 MVC（Model-View）的概念，这非常简单。值得注意的是，在检查源代码时，一些软件开发经验会有很大的帮助，它有助于在更复杂的情况下操作。

我开始向 /oauth2/token 发出 HTTP 请求，我将请求调整为看起来像元数据请求（添加“Metadata: True”HTTP 标头）并添加资源参数。我希望令牌可供 Azure 管理 API 使用，因此我使用了“resource=https://managment.azure.com/”。该请求仅返回一个 JWT（JSON Web 令牌）。

这个令牌背后的使用者是谁？为此，我解码了令牌并看到了我的订阅 ID、租户 ID 和我的自动化帐户资源 ID。我在网上查了“Azure 自动化标识”，发现每个自动化账户都有一个“系统分配的托管标识”，这基本上意味着你可以为你的自动化脚本分配角色，并且该标识由服务管理。所以我想测试一下我的令牌是不是真的。我使用 Azure CLI 发出一个简单的请求来获取我的所有 VM（“az vm list”）并截获该请求并交换令牌。我收到一个错误提示，提示我没有足够的权限。我没有为我的托管身份分配任何角色。分配兼容角色后，令牌起作用了。该令牌实际上与我的托管身份相关联！

因此，与托管身份相关联的令牌本身并不是漏洞。你应该能够为自己的托管身份获取令牌。但是，如果你一直在关注，则可以在本地访问其他端口。每次我运行自动化作业时，我都会看到端口发生变化，但仍保持在相同的范围内。

我编写了一个快速的 Python 脚本来向从 40000 开始的 20 个端口发出 HTTP 请求。这样做很简单：

随机端口给了我 JWT 令牌。我又执行了几次脚本，不同的端口给了我不同的令牌！很明显，我实际上是在访问其他人的身份端口。我已经证明，如果给予足够的权限，这些令牌可以用于管理 Azure 帐户，因此无需访问其他租户的数据。

研究人员想要了解这个简单的漏洞攻击力有多大。通过使用Azure Automation的调度功能，尝试从几百个端口中获取令牌，并查看哪些租户出现了。研究人员没有存储令牌，只提取了有关租户的元数据（租户 ID 和自动化帐户资源 ID）。

在这个漏洞被修复之前，研究人员看到了许多独特的租户，包括几家非常知名的公司。如果研究人员连续运行，很可能捕获了更多。

总的来说，这是一个相当简单的漏洞，表现为一个非常有趣的漏洞。目前还不清楚这里缺少什么，验证端口可能需要某种形式的身份验证(该服务器上的其他终端肯定需要)。

本文翻译自：https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/如若转载，请注明原文地址