AutoWarp 是 Azure 自动化服务中的一个关键漏洞 ，它允许未经授权访问 使用该服务的其他 Azure 客户账户。这种攻击可能意味着完全控制属于目标账户的资源和数据，具体取决于客户分配的权限。
研究表明，有多家大公司正在使用该服务并且可能已被访问，从而造成数十亿美元的损失。研究人员向微软报告了此问题，现已修复，并且已通知所有受影响的客户。
在以下情况下，您在漏洞修复之前容易受到 AutoWarp 的攻击：
1. 你一直在使用 Azure 自动化服务
2. 您的自动化账户中的托管身份功能已启用（默认情况下已启用 ）
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 自动化是非常标准的自动化脚本服务。你可以上传 Python 或 PowerShell 脚本以在 Azure 上执行。
研究人员所做的第一件事就是探索文件系统，看看能找到什么有趣的东西。我从我的自动化脚本中启动了一个反向 shell，使针对服务器的工作更加顺畅。
使用 Python 设置反向 shell不会出现漏洞。但是，当我执行一些常用命令（如tasklist）时，我收到一条错误消息，提示找不到它们。显然，负责定义操作系统应尝试执行哪些文件扩展名的PathExt环境变量被设置为一个奇怪的值。通常，它包含.exe文件扩展名，但在我们的例子中不包含。只有.CPL是存在的，它是 Windows 控制面板项目的文件扩展名。即使我尝试使用tasklist.exe列出正在运行的进程，它也给了我一个我以前从未见过的消息。看起来可能有什么事情发生了……
当我查看 C:\ 驱动器时，首先引起我注意的两件事是“Orchestrator”和“temp”目录。Orchestrator 目录包含许多 DLL 和 EXE。我看到带有“sandbox”的文件名，直觉上我明白这个目录包含我们正在运行的沙箱。临时目录包含另一个名为“diags”的目录，并且有一个“trace.log”文件。
日志文件非常适合研究。在许多情况下，日志提供了非常简洁和重要的信息。您基本上有机会在日记中窥探开发人员认为重要的内容。对我来说幸运的是，这是一个非常好的日志文件。这在第 7 行很早就出现了：
云安全研究员亚尼尔察里米（Orca Security）表示“没有什么比发现你的目标暴露了一个 Web 服务更令人兴奋的了。尤其是当它是本地并且是在一个看似随机的端口上时。”
这只是向我发出了危险信号。这就是我通常所说的“掩护” ——为掩盖某些技术限制而做出的软件决策。为什么会选择这么高的随机端口？因为其他端口被占用。
我使用 cURL 向 URL 发出了 HTTP 请求。虽然它起作用了，但没有提供太多关于正在发生的事情的信息。我还尝试访问下一个端口(40009、40010等)。他们中的一些人对我做出了回应，这立即证实了我的怀疑。日志清楚地表明，Web 服务是由我之前看到的协调器管理的，所以我必须了解发生了什么。这个web服务是什么?深入了解 Azure 自动化代码
深入了解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://mp.weixin.qq.com/s/3YNM4it8yY3_A5aXBHTPNA
