目录导航
AutoWarp 是 Azure 自动化服务中的一个严重漏洞，允许未经授权访问使用该服务的其他 Azure 客户帐户。这种攻击可能意味着完全控制属于目标帐户的资源和数据，具体取决于客户分配的权限。
我们的研究表明，多家大公司正在使用该服务并且可能已被访问，从而将数十亿美元置于风险之中。我们直接向 Microsoft 报告了此问题，现已修复，并且已通知所有受影响的客户。
您是否容易受到 AutoWarp 的影响？
在以下情况下，您在漏洞修复之前容易受到 AutoWarp 的攻击：
- 你一直在使用 Azure 自动化服务
- 您的自动化帐户中的托管身份功能已启用（默认情况下已启用）
AutoWarp 发现时间线
- 2021 年 12 月 6 日：我们已经开始研究，发现了该漏洞，并将其报告给 Microsoft。
- 2021 年 12 月 7 日：我们发现了面临风险的大公司（包括一家全球电信公司、两家汽车制造商、一家银行集团、四大会计师事务所等）。
- 2021 年 12 月 10 日：Microsoft 修复了该问题并开始寻找此攻击的其他变体。
- 2022 年 3 月 7 日：微软调查结论后公开披露。
微软声明
“我们要感谢 Orca Security 的 Yanir Tsarimi，他报告了这个漏洞，并与 Microsoft 安全响应中心 (MSRC) 在协调漏洞披露 (CVD)下合作，以帮助确保 Microsoft 客户的安全。”
-Microsoft 安全响应中心 (MSRC)
微软在博客中回应了这一事件。
Microsoft 还建议其自动化客户遵循 此处概述的安全最佳实践。
什么是 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 行很早就出现了：
Orchestrator.Sandbox.Diagnostics Critical:
0 : [2021-12-06T12:08:04.5527647Z]
Creating asset retrieval web service.
[assetRetrievalEndpoint=
http://127.0.0.1:40008]“没有什么比发现你的目标暴露了一个 Web 服务更令人兴奋的了。尤其是当它是本地 AND 在一个高的、看似随机的端口上时。”
亚尼尔察里米
云安全研究员，Orca Security
这只是向我发出了危险信号。这就是我通常所说的“掩护” ——为掩盖某些技术限制而做出的软件决策。为什么会选择这么高的随机端口？因为其他端口被占用。
我使用 cURL 向 URL 发出了 HTTP 请求。它有效，但没有提供太多关于正在发生的事情的信息。我还尝试访问下一个端口（40009、40010 等）。他们中的一些人回应了我，这立即证实了我的怀疑。日志清楚地表明，Web 服务是由我之前看到的协调器管理的，所以我必须了解发生了什么。这是什么网络服务？
深入了解 Azure 自动化代码
下载编排器的文件后，我启动了 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 脚本来向从 40,000 开始的 20 个端口发出 HTTP 请求。这样做很简单：
import requests
PORT_RANGE_START = 40000
PORTS_TO_SCAN = 1000
print("Making requests to ports 40000 and up...")
for port in range(PORT_RANGE_START, PORT_RANGE_START + PORTS_TO_SCAN):
try:
resp = requests.post(f"http://127.0.0.1:{port}/oauth2/token",
timeout=0.5, headers={'Metadata': 'True'}, data={'resource':
'https://management.azure.com/'})
print(f"Port {port}: {resp.json()}")
except Exception as e:
continue随机端口给了我 JWT 令牌。我又执行了几次脚本，不同的端口给了我不同的令牌！对我来说很明显，我实际上是在访问其他人的身份端点。我已经证明，如果给予足够的权限，这些令牌可以用于管理 Azure 帐户，因此无需访问其他租户的数据。
我们想了解这个简单的缺陷能走多远。我们使用 Azure 自动化的计划功能尝试从数百个端口获取令牌并查看哪些租户出现。我们没有存储令牌，只提取了有关租户的元数据（租户 ID 和自动化帐户资源 ID）。
在这短短的时间内，在问题修复之前，我们看到了许多独特的租户，包括几家非常知名的公司！这只是每小时一次的预定运行。如果我们连续运行，很可能我们会捕获更多（预计身份端点会在自动化作业完成后立即关闭，因此在某些情况下您必须非常快地抓住它）。
这是一个相当简单的缺陷，它表现为一个非常有趣和有趣的漏洞。目前还不清楚这里缺少什么，身份端点可能需要某种形式的身份验证（该服务器上的其他端点肯定需要）。或者也许有人忽略了机器内部的网络实际上并没有像你想象的那样被沙盒化。
AutoWarp Microsoft Azure 自动化漏洞的后果
我在同一天向微软报告了这个漏洞。我要感谢他们在负责任的披露过程中如此积极和合作。Microsoft 决定通过在请求身份时要求“X-IDENTITY-HEADER”HTTP 标头来修补此问题。您必须将该值设置为环境变量中设置的秘密值。他们还提到他们正在对他们的架构进行全面审查，以确保类似的事情不会再次发生！
我们很高兴在它落入坏人之手之前发现了这个问题。我们要感谢 Microsoft 与我们合作并迅速而专业地解决此问题。我们对云提供商的重点研究将继续，您可以期待很快收到我们的更多消息。
AutoWarp 以及之前的关键云漏洞（例如AWS Superglue和BreakingFormation）表明，没有什么是万无一失的，攻击者可以通过多种方式进入您的云环境。这就是为什么全面了解您的云资产（包括最关键的攻击路径）非常重要的原因。为了提供帮助，我邀请您通过免费、免费的云风险评估来亲身体验我们的技术和人才。您将获得对公有云的完整可见性、包含执行摘要的详细风险报告，以及与我们的云安全专家交流的时间。
转载请注明出处及链接