SentinelLabs 在 Microsoft Azure Defender for IoT 中发现了许多影响云和本地客户的严重漏洞。

未经身份验证的攻击者可以通过滥用 Azure 密码恢复机制中的漏洞远程攻击受 Microsoft Azure Defender for IoT 保护的设备。

SentinelLabs的调查结果已于2021年6月主动报告给微软，这些漏洞被定义为 CVE-2021-42310、CVE-2021-42312、CVE-2021-37222、CVE-2021-42313 和 CVE-2021-42311，且标记为严重，一些 CVSS 得分甚至为 10.0。

Microsoft 已发布安全更新以解决这些严重漏洞。鼓励用户立即采取行动。

目前，SentinelLabs 尚未发现野外滥用的证据。

技术细节

运营技术 (OT) 网络虽然很流行，但是，其中许多技术在设计时并未考虑到安全性，并且无法通过传统的 IT 安全控制进行保护。与此同时，物联网 (IoT) 所连接的数十亿设备大大增加了攻击面和安全风险。

但供应商并没有忽视这个问题，许多供应商都提供了安全解决方案以试图解决这个问题，但如果安全解决方案本身就存在着漏洞怎么办？在本文中，我们将讨论 Microsoft Azure Defender for IoT 中发现的严重漏洞，这是 Microsoft Azure 的 IoT/OT 网络安全产品。

首先，我们会介绍密码重置机制中的漏洞如何被远程攻击者滥用以获得未经授权的访问。然后，我们讨论了 Defender for IoT 中的多个 SQL 注入漏洞，这些漏洞允许远程攻击者无需身份验证即可获得访问权限。最终，提出有关安全产品本身的安全性及其对易受攻击部门安全态势的整体影响的严重问题。

Microsoft Azure Defender for IoT

Microsoft Defender for IoT 是一种无代理网络层安全性，用于持续的 IoT/OT 资产发现、漏洞管理和威胁检测，无需更改现有环境。它可以完全部署在本地或与 Azure 连接的环境中。

该解决方案由两个主要组件组成：

Microsoft Azure Defender For IoT Management ——使 SOC 团队能够管理和分析从多个传感器聚合到单个仪表板的警报，并提供网络安全状况的整体视图。

Microsoft Azure Defender For IoT Sensor – 发现并持续监控网络设备。传感器使用物联网和 OT 设备上的被动（无代理）监控来收集 ICS 网络流量。传感器连接到 SPAN 端口或网络 TAP，并立即开始对 IoT 和 OT 网络流量执行 DPI（深度数据包检测）。

这两个组件既可以安装在专用设备上，也可以安装在 VM 上。

深度包检测 (DPI) 是通过负责分析网络流量的 Horizon 组件实现的。 Horizon 组件加载内置解析器，并且可以扩展以添加自定义网络协议解析器。

物联网 Web 界面攻击面防御

管理和传感器共享大致相同的代码库，配置更改以适应设备的用途。这就是为什么两台设备都受到大多数相同漏洞影响的原因。

两台设备上暴露的最吸引人的攻击面是 Web 界面，它允许以简单的方式控制环境。该传感器还暴露了另一个攻击面，即解析网络流量的 DPI 服务。

安装和配置管理和传感器后，我们会看到 Web 界面的登录页面。

相同的凭据也用作 SSH 服务器的登录凭据，这让我们对系统的工作方式有了更多的了解。我们要做的第一件事是获取资源以了解幕后发生的事情，那么我们如何获取这些资源呢？

Defender for IoT 是一款前身为 CyberX 的产品，于 2020 年被微软收购。在“cyberx”用户的主目录中查找，我们发现了安装脚本和一个包含系统加密文件的 tar 压缩文件。读取脚本时，我们找到了解密压缩文件的命令。简化版如下：

解密密钥在所有安装中共享。

提取数据后，我们找到了 Web 界面的源代码（用 Python 编写）并开始工作。

首先，我们的目标是找到任何公开的未经身份验证的API，并查找其中的漏洞。

寻找潜在的漏洞

urls.py 文件包含 Web 应用程序的主要路由：

使用 Jetbrains IntelliJ 的类层次结构功能，我们可以轻松识别不需要身份验证的路由控制器。

不需要身份验证的路由控制器

从 BaseHandler 继承并且不验证身份验证或需要秘密令牌的每个控制器在此时都是一个很好的候选者。

Azure 的密码恢复机制

管理和传感器的密码恢复机制操作如下：

1.访问管理/传感器 URL（例如，https://ip/login#/dashboard）；

2.进入“密码恢复”页面；

3.将此页面中提供的 ApplianceID 复制到 Azure 控制台，并获取你在密码重置页面中上传的密码重置 ZIP 文件。

4.使用步骤 2 中提到的表格将签名的 ZIP 文件上传到管理/传感器密码恢复页面。这个ZIP包含数字签名的证明，通过数字证书和签名数据的方式，证明用户是这台设备的所有者。

5.生成新密码并显示给用户：

5.1实际过程分为对管理/传感器服务器的两个请求：

5.1.1上传签名的 ZIP 证明；

5.1.2密码恢复；

5.2当上传ZIP文件时，它被解压缩到/var/cyberx/reset_password目录(由zipfileconfigationapihandler处理)；

5.3在处理密码恢复请求时，服务器会执行以下操作：

5.3.1 PasswordRecoveryApiHandler 控制器验证证书。这将验证证书是否由根 CA 正确签名。此外，它还会检查这些证书是否属于 Azure 服务器。

5.3.2向内部 Tomcat 服务器发送请求以进一步验证设备的属性。

5.3.3如果所有检查都正确通过，PasswordRecoveryApiHandler将生成一个新密码并将其返回给用户。

ZIP 包含以下文件：

IotDefenderSigningCertificate.pem – Azure 公钥，用于验证 ResetPassword.json 中的数据签名，由 issuer.pem 签名。

Issuer.pem – 签署 IotDefenderSigningCertificate.pem，由受信任的根 CA 签署。

ResetPassword.json – JSON 应用程序数据，设备的属性。

ResetPassword.json 文件的内容如下所示：

根据步骤2，处理文件上传到reset_password目录（components\xsense-web\cyberx_web\api\admin.py:1508）的代码如下：

如下所示，该代码将用户交付的ZIP解压到上述目录，并处理密码恢复请求(cyberx python库文件django_helper .py:576)：

该函数首先验证提供的用户并调用函数_try_reset_password：

在内部，此代码会验证证书，包括颁发者。

之后，对内部 API http://127.0.0.1:9090/core/api/v1/login/reset-password 的请求由最终执行以下代码的 Java 组件发出和处理：

此代码再次验证密码重置文件。这次它还验证了 ResetPassword.json 文件的签名及其属性。

如果一切顺利并且 Java API 返回 200 OK 状态码，PasswordRecoveryApiHandler 控制器继续并生成新密码并将其返回给用户。

Defender for IOT 中的漏洞

如图所示，密码恢复机制由两个主要部分组成：

Python Web API（外部）；

Java Web API（tomcat，内部）；

这引入了一个time-of-check-time-of-use (TOCTOU) 漏洞，原因是没有应用同步机制。

如上所述，重置密码机制从上传 ZIP 文件开始。这个原语允许我们将任何文件上传到/var/cyberx/reset_password目录并将其解压缩。

可以在第一次验证（Python API）和第二次验证（Java API）之间更改 /var/cyberx/reset_password 中的文件，Python API文件由 Azure 证书正确签名。然后，Java API 处理要替换的自定义文件，导致它错误地同意其真实性并返回 200 OK 状态代码。

密码恢复Java API包含逻辑漏洞，这些漏洞让专门设计的有效负载绕过了所有验证。

Java API 验证 JSON 文件的签名（与上面的代码相同）：

这里的问题是它没有验证 IotDefenderSigningCertificate.pem 证书，而不是 Python API 验证。它只检查 JSON 文件中的签名是否由附加的证书文件签名，这引入了一个重大漏洞。

因此，攻击者可以生成自签名证书并签署将通过签名验证的 ResetPassword.json 有效负载。

如前所述，ResetPassword.json 如下所示：

之后，有一个订阅 ID 检查：

这是远程攻击者无法获得的唯一属性，并且在合理的时间内无法猜测。但是，可以轻松绕过此检查。

该代码从 JSON 文件中获取 subscriptionId，并将其与 machineSubscriptionId 进行比较。但是，这里的代码有漏洞。它检查 machineSubscriptionId 是否包含来自用户控制的 JSON 文件的 subscriptionId，而不是相反。 .contains() 的使用是不安全的。 subscriptionId 采用 GUID 格式，这意味着它必须包含连字符。这允许我们通过仅提供单个连字符来绕过此检查。

接下来，检查 issueDate 和 ApplianceId。这已经由密码恢复页面（在步骤 2 中提到）提供给我们。

现在我们明白了，我们可以绕过 Java API 中的所有检查，这意味着我们只需要成功赢得竞争条件并最终在未经授权的情况下重置密码。

ZIP上传界面和密码恢复界面分开的事实在开发阶段派上了用场。

Azure Defender for IoT的被攻击过程

为了准备攻击，我们需要执行以下操作。

从 Azure 门户获取合法的密码恢复 ZIP 文件。显然，我们无法访问受害设备所属的 Azure 用户，但我们可以使用任何 Azure 用户并生成一个“虚拟”ZIP 文件。我们只需要恢复 ZIP 文件即可获得合法证书。这可以通过以下 URL 完成：

为此，我们可以创建一个新的试用 Azure 帐户并使用上述接口生成恢复文件。秘密标识符无关紧要，可能包含垃圾。

然后我们需要生成一个自定义的（“坏的”）ZIP 文件。此 ZIP 文件将包含两个文件：

IotDefenderSigningCertificate.pem – 自签名证书。可以通过以下命令生成：

ResetPassword.json – 属性数据 JSON 文件，由上述自签名证书签名并进行相应修改以绕过 Java API 验证。

可以使用以下 Java 代码对该 JSON 文件进行签名：

如前所述，applianceId 是从密码恢复页面获取的。tenantId 未经验证，因此可以是任何内容。

issuanceDate参数是自解释的。

一旦生成并签名，可以将其添加到 ZIP 压缩文件并供以下 Python 漏洞利用脚本使用：

benign.zip 文件是从 Azure 门户获取的 ZIP 文件，而malicious.zip 文件是如上所述的自定义 ZIP 文件。

上面的漏洞利用脚本执行 TOCTOU 攻击以重置并接收cyberx用户名的密码，而无需任何身份验证。它通过使用三个线程来实现：

looper_benign – 负责无限循环上传良性 ZIP 文件；

looper_malicious – 与looper_benign相同，但是上传恶意ZIP，在这个配置中有1秒的超时时间；

looper_recover – 发送密码恢复请求以触发易受攻击的代码；

不幸的是，文档提到 ZIP 文件不能被篡改。

该漏洞在CVE-2021-42310中得到了恢复。

以 root #1 身份执行未经身份验证的远程代码

至此，我们可以获得特权用户cyberx的密码。这允许我们登录到 SSH 服务器并以 root 身份执行代码。即使没有这个，攻击者也可以使用更隐蔽的方法来执行代码。

使用获取的密码登录后，攻击面大大增加。例如，我们在更改密码机制中发现了一个简单的命令注入漏洞：

来自components\xsense-web\cyberx_web\api\authentication.py:151：

该函数接收来自用户的三个 JSON 字段，“username”、“password”、“new_password”。

首先，它验证我们已经拥有的用户名和密码。接下来，它只使用正则表达式检查密码的复杂性，但不清理命令注入原语的输入。

在验证之后，它使用攻击者控制的用户名和新密码以root身份执行/usr/local/bin/cyberx-users-password-reset脚本。由于该函数没有正确地对“new_password”的输入进行清理，所以我们可以注入任何我们选择的命令。我们的命令将在sudo的帮助下以root用户的身份执行，这让我们可以以root用户的身份执行代码：

这可以通过以下 HTTP 数据包来利用：

该漏洞在CVE-2021-42312中被修复。

POC

接下来，我们将介绍两个额外的路由和新漏洞，以及流量处理框架中的一个漏洞。

这些漏洞是基本的 SQL 注入（稍加改动），但它们对产品和组织网络的安全性有很大影响。

CVE-2021-42313

DynamicTokenAuthenticationBaseHandler类继承自BaseHandler类，不需要身份验证。这个类包含两个容易被SQL注入的函数(get_version_from_db, uuid_is_connected)。

如上所示，UUID 参数未经过清理并格式化为 SQL 查询。有几个类继承了 DynamicTokenAuthenticationBaseHandler。易受攻击函数的流程实际上存在于令牌验证过程中。

因此，我们可以在不进行身份验证的情况下触发 SQL 注入。

这些漏洞可以通过以下方式触发：

api/sensors/v1/sync
api/v1/upgrade/status
api/v1/upgrade/upgrade-log

值得注意的是，函数execute_select_query在内部调用SQL execute, API支持堆叠查询。这使得“简单”的select SQL注入成为一个更强大的原语(也就是使用';'执行任何查询)。在我们的测试中，我们设法注入、更新和执行SQL特殊命令。

对于这个漏洞的PoC，我们使用了api/sensors/v1/sync API。我们创建了以下脚本来从数据库中提取登录用户会话 ID，最终允许我们接管该帐户。

此脚本输出的示例：

从数据库中提取会话ID后，我们可以登录管理Web界面，此时有几种方法可以以root身份执行代码。例如，我们可以更改密码并登录 SSH 服务器（这些用户是 sudoers），使用脚本调度机制，或者使用我们在本文前面提到的命令注入漏洞。

由于缺乏会话验证，这种攻击很容易发生。没有进一步的验证层，例如验证会话id是否来自与会话发起者相同的IP地址和User-Agent。

CVE-2021-42311

UpdateHandshakeHandlers::is_connected 函数也容易发生 SQL 注入。

UpdateHandshakeHandler 类继承自 BaseHandler，它可以被未经身份验证的用户访问，并且可以通过API: / API /v1/token/update-handshake访问。

然而，这一次有一个变化:_post函数执行令牌验证。

这意味着 API 需要一个秘密令牌，没有它我们就无法利用这个 SQL 注入漏洞。幸运的是，这个 API 令牌并不是那么隐秘。此 update.token 硬编码在文件 index.properties 中，并在全球所有 Defender For IoT 安装中共享，这意味着攻击者无需任何身份验证即可利用此漏洞。

我们创建了以下脚本，并从数据库中提取登录的用户会话 ID，这允许我们接管该帐户。

与第一个 SQL 注入漏洞一样，在从数据库中提取会话 id 后，我们可以使用上述任何一种方法以 root 身份执行代码。

CVE-2021-37222

传感器设备使用 RCDCAP（一个开源项目）打开 CISCO ERSPAN 和 HP ERM 封装的数据包。

函数 ERSPANProcessor::processImpl 和 HPERMProcessor::processImpl 方法易受基于 Wildcopy 堆的缓冲区溢出漏洞的影响，在处理自定义输入时，该漏洞可能允许任意代码执行。

这些函数容易受到基于 Wildcopy 堆的缓冲区溢出漏洞的影响，该漏洞可能允许任意代码执行。

此漏洞是通过使用 pcap 文件在本地对 RCDCAP 进行模糊测试发现的，并在执行此行时发生：

(hp-erm-processor.cc:94)
(erspan-processor.cc:90)

目前已经发布了修复：

但是，MSRC 认为此漏洞不符合 MSRC 安全更新的标准，开发组可能会决定根据需要修复它。

谁受到影响？使用未打补丁的系统运行的适用于 IoT 的 Azure Defender 会受到影响。由于该产品有许多配置，例如 RTOS，这些配置还没有经过测试，因此这些系统的用户也会受到影响。

攻击可能会导致整个网络的破坏，因为Azure Defender For IoT被配置为在网络流量上有一个TAP(终端接入点)。访问网络上的敏感信息可能会打开一些复杂的攻击场景，这些攻击场景可能很难或不可能检测到。

本文翻译自：https://www.sentinelone.com/labs/pwning-microsoft-azure-defender-for-iot-multiple-flaws-allow-remote-code-execution-for-all/如若转载，请注明原文地址