Sentinelabs研究团队在驱动软件中发现了许多严重的漏洞，影响了许多云服务。

像Amazon Workspaces这样的云桌面解决方案依赖于包括Eltima SDK在内的第三方库，提供“以太网USB”功能，允许用户连接和共享本地设备，如网络摄像头。这些云服务被全球数以百万计的客户使用。

这些漏洞允许攻击者升级特权，使他们能够禁用安全产品、覆盖系统组件、破坏操作系统或任意执行恶意操作。

SentinelLabs 的调查结果在 2021 年第二季度主动报告给易受攻击的供应商，漏洞被跟踪为 CVE-2021-42972、CVE-2021-42973、CVE-2021-42976、CVE-2021-42977、CVE-20291-4297 -2021-42980、CVE-2021-42983、CVE-2021-42986、CVE-2021-42987、CVE-2021-42988、CVE-2021-42990、CVE-2021-42992、CVE-2021-42992、CVE-2021-42992、CVE-2021-42924 -42996、CVE-2021-43000、CVE-2021-43002、CVE-2021-43003、CVE-2021-43006、CVE-2021-43637、CVE-2021-43638、CVE-26282、CVE-26282 、CVE-2021-42683、CVE-2021-42685、CVE-2021-42686、CVE-2021-42687、CVE-2021-42688。

供应商已发布安全更新以解决这些漏洞。其中一些是自动应用的，而另一些则需要客户操作。

目前，SentinelLabs 还没有发现野外滥用的证据。

在2020-2021年期间，世界各地的组织需要采用新的工作模式，包括远程工作，以应对疫情。这要求组织使用各种解决方案，允许远程工作员工安全地访问其组织的资产和资源。因此，远程工作市场已经有了巨大的增长，但安全性并没有相应的发展。

在这篇文章中，研究人员在主要云服务中发现的多个漏洞的细节，包括：

需要注意的是：

这些漏洞源于Eltima开发和提供的一个库，多个云提供商正在使用这个库。

最终用户(本例中为AWSWorkSpaces客户端)和云服务(运行在AWS云中的AWSWorkSpaces)都容易受到研究人员下面将讨论的各种漏洞的影响。这种特性可以归因于服务器端和客户端应用程序之间的代码共享。

虽然研究人员已经确认了AWS、NoMachine 和 Accops 的这些漏洞，但测试范围仅限于这些供应商，研究人员相信使用相同库的其他云提供商也很有可能存在这些漏洞。

此外，在测试的供应商中，并不是所有的供应商都测试了客户端和服务器端的漏洞，因此，还可能存在更多的漏洞实例。

技术细节

虽然这些漏洞影响多个产品，但下面的技术细节将主要以 AWSWorkSpaces作为示例。这就是研究起点，所有提到的产品的漏洞本质上都是一样的。

Amazon WorkSpaces 是一项完全托管且持久的桌面虚拟化服务，使用户能够从任何受支持的设备随时随地访问所需的数据、应用程序和资源。 WorkSpaces 支持配置 Windows 或 Linux 桌面，并且可以快速扩展以向全球员工提供数千个桌面。

WorkSpaces通过将数据保存在终端用户的设备上，并通过AWS云的强大功能提高可靠性，从而提高安全性。AWS云对于不断增长的远程劳动力来说是一项越来越有价值的服务。

如上所示，身份验证和会话编排是通过HTTPS完成的，而数据流是PCoIP (PC over IP)或WSP (WorkSpaces Streaming Protocol)，这是一种私有协议。

它们之间的主要区别在于，在 Amazon WorkSpaces 上，只有 WSP 支持设备重定向，例如智能卡和网络摄像头，这就是漏洞所在。

WSP协议由几个库组成，其中一些是由第三方提供的。其中之一是Eltima SDK。Eltima开发了一个名为“USB Over Ethernet”的产品，它支持远程USB重定向。

Amazon WorkSpaces 使用经过一些修改的相同产品，使其用户能够将 USB 设备重定向到其远程桌面，从而允许他们将 USB 网络摄像头等设备直接从远程桌面连接到 Zoom调用。

该程序与“客户端”（连接到其他共享设备）和“服务器”（通过互联网共享设备）捆绑在一起：

USB Over Ethernet 屏幕截图

负责 USB 重定向的驱动程序是 wspvuhub.sys 和 wspusbfilter.sys，这两个驱动程序都很容易受到攻击，并且似乎自 2020 年初宣布 WSP 协议以来一直在使用。

在讨论这些漏洞之前，了解Windows Kernel IO Manager (IOMgr)的工作原理是很重要的。当用户模式线程发送 IRP_MJ_DEVICE_CONTROL 数据包时，它会在用户模式和内核模式之间传递输入和输出数据，具体取决于调用的 I/O 控制 (IOCTL) 代码。根据微软的文档，“一个 I/O 控制代码是一个由多个字段组成的 32 位值”，如下图所示：

输入/输出控制代码结构

出于本文的目的，我们将重点关注两个最低有效位 TransferType。文档告诉我们，这些位指示系统将如何在 NtDeviceIoControlFile 系统调用的调用者和处理 IRP 的驱动程序之间传递数据。

使用IRP在内核模式和用户模式之间交换数据有三种方式：

METHOD_BUFFERED——被认为是最安全的。使用此方法 IOMgr 会将调用者输入数据从提供的调用者输出缓冲区中复制出来，然后再复制到提供的调用者输出缓冲区中。

METHOD_IN/OUT_DIRECT——根据数据方向，IOMgr 将提供一个描述缓冲区的 MDL，并确保执行线程对缓冲区具有读/写访问权限，IOCTL 例程然后可以将缓冲区锁定到内存。

METHOD_NEITHER——被认为更容易出现故障。 IOMgr 不映射/验证提供的缓冲区，IOCTL 处理程序接收用户模式地址，这主要用于高速数据处理。

易受攻击的 IOCTL 处理程序是 0x22005B 和 0x22001B，其中包含多个漏洞并且在所有易受攻击的产品中都是相同的。

此代码处理类型为 METHOD_NEITHER (Type3InputBuffer) 的用户缓冲区

这意味着 IOCTL 处理程序负责根据用例验证、探测、锁定和映射缓冲区本身。

这为利用该设备提供了许多可能性，例如双重提取和任意指针取消引用，这也可能导致其他漏洞。在下图中，可以看出这段代码中根本不存在缓冲区验证：

IOCTL 0x22001B 处理程序

下面是这段代码的简要解释：

首先，例程检查调用进程是32位还是64位(红色箭头)。

然后，它根据第一次检查的结果(蓝色箭头)决定是使用alloc_size_64bit还是alloc_size_32bit。

接下来，使用用户控制的大小参数(粉色箭头)调用ExAllocatePoolWithTag_wrapper。

此时，代码继续处理处理32位memmove(黄色箭头)和64位memmove(绿色箭头)的块。从图中可以看出，在这个阶段存在对用户控制的数据进行不安全的算术操作的情况，在计算副本大小时没有进行溢出检查，这可能导致整数溢出，最终可能导致任意代码执行。

一般来说，访问(读/写)用户模式地址需要探测。处理Type3InputBuffer还需要将页面锁定到内存中，并且只获取一次数据。

导致此代码溢出的最简单方法是为分配和复制函数传递不同的参数。这可以通过制作一个特殊的 IRP 来完成：

其中copy_size_64位或copy_size_32位大于alloc_size_32位或alloc_size_64位

即使副本大小和分配大小是完全相同的参数，由于在计算 memmove 大小参数时存在不安全的算术运算，代码仍然可以被利用。

在简化版本中，为了触发该漏洞，攻击者可能会发送以下IOCTL（假设运行64位进程）：

此代码将导致分配 0x20 字节：

以及0x435字节的复制：

由于研究人员同时控制数据和大小，这使得在内核模式下实现代码执行是一个非常强大的原语。

BSoD 概念验证

使用来自OSR的DeviceTree工具，研究人员可以看到这个驱动程序在没有ACL强制的情况下接受IOCTLs(注意：某些驱动程序在 IRP_MJ_CREATE 例程中独立处理对设备的访问):

使用DeviceTree软件检查设备的安全描述符

这意味着该漏洞可以从沙箱中触发，并且可能在本地权限升级之外的上下文中被利用。例如，它可能被用作第二阶段的浏览器攻击(尽管大多数现代浏览器都有一个允许IOCTLs请求的列表)或其他类似的沙箱。

攻击目标

使用上述客户端版本的用户容易出现漏洞，如果成功利用这些漏洞，可能会被用来获得高权限。由于易受攻击的代码同时存在于远程和本地端，因此远程桌面也会受到此漏洞的影响。

这些高度严重的漏洞可能允许计算机上的任何用户(即使没有特权)升级特权并以内核模式运行代码。这些漏洞的明显弊端之一是，它们可以被用来绕过安全产品。访问组织网络的攻击者还可以访问未打补丁的系统上的执行代码，并利用此漏洞获得本地权限提升。然后攻击者可以利用其他技术来转向更广泛的网络，比如横向移动。

目前，Accops和NoMachine都进行了回应。

本文翻译自：https://www.sentinelone.com/labs/usb-over-ethernet-multiple-privilege-escalation-vulnerabilities-in-aws-and-other-major-cloud-services/如若转载，请注明原文地址