签名内核驱动漏洞 通往Windows核心网关

有各种类型的内核驱动程序；首先想到的是为硬件设备提供软件接口的设备驱动程序，例如即插即用接口或过滤器驱动程序。这些低级系统组件具有严格的开发过程，包括对安全性的审查。但是，还有一些额外的“软件”驱动程序被设计为在 Ring 0 中运行，并提供特定的、非硬件相关的功能，如软件调试和诊断、系统分析等。如下所示，这些很容易扩展攻击显着地浮出水面。

虽然在较新版本的 Windows 中不再可能直接加载恶意的、未签名的驱动程序（除非在启动期间明确禁用驱动程序签名强制）并且内核 rootkit 被认为已成为过去，但仍有加载恶意代码的方法进入内核。虽然实现这一目标的实际漏洞和利用得到了很多关注，但还有一种更简单的方法：滥用合法的签名驱动程序。有许多来自各种硬件和软件供应商的驱动程序提供了以最小的努力完全访问内核的功能。

签名驱动程序中的漏洞主要被游戏作弊开发人员用来规避反作弊机制，但也观察到它们被多个 APT 组织和商用恶意软件等使用。

本文讨论了内核驱动程序中常见的漏洞类型，提供了几个利用此类易受攻击驱动程序的恶意软件案例研究，分析了我们在研究期间发现的易受攻击驱动程序的示例，并概述了针对此类利用的有效缓解技术。虽然这个问题并不是新问题，而且过去已经提出了有关该主题的相关研究，主要是在 2018 年和 2019 年（[1]、[2]、[3]），但在撰写本文时它仍然是一个问题。

常见的驱动程序漏洞类型

虽然每个漏洞都不同，但类似类型的漏洞似乎在不相关的内核驱动程序中反复出现。这可能部分是由（古老的）驱动程序代码示例造成的，当访问内核模式不限于签名驱动程序并且开发人员没有考虑安全性时（恶意软件可以简单地加载未签名的 rootkit 驱动程序）。以下部分描述了来自各种甚至知名硬件和软件供应商的驱动程序中最常见的漏洞。

MSR 读/写

1993 年在奔腾 80586 CPU 中引入了特定于模型的寄存器(MSR)。MSR 可以被认为是 CPU（或特定内核）的“全局变量”。有些包含有关处理器或特定 CPU 内核的各种信息——例如温度、功率……。此外，还有许多 MSR 包含对系统工作至关重要的数据，例如SYSCALL的IA32_LSTAR ( 0xC0000082 )或SYSENTER 的 IA32_SYSENTER_EIP ( 0x00000176 )，它们都包含指向内核中的地址的指针，CPU 在SYSCALL或SYSENTER _指令被执行。在较新的 Windows x64 平台（例如 Windows 10 或 11）上，SYSCALL用于 AMD 和 Intel CPU，其中IA32_LSTAR应指向ntoskrnl.exe中的KiSystemCall64函数。执行SYSCALL时转换到 Windows 内核的机制如图 1 所示。

MSR 由数字索引并由特权RDMSR和WRMSR指令访问，这些指令只能在内核模式下执行。许多商业驱动程序实现了用户模式应用程序通过 IOCTL 机制访问这些指令的功能。这通常旨在能够读取或写入一些特定的无害 MSR（如 CPU 电压、温度等），但开发人员有时不会添加任何额外的检查来限制对关键 MSR 的访问，例如图 2 中的示例. 这为潜在的攻击者提供了机会，例如，修补SYSCALL/SYSENTER入口点 MSR，这些 MSR 是指向处理来自用户模式的任何系统调用的函数的指针。

在引入管理模式执行保护 (SMEP) 等缓解措施之前，在较旧的 CPU 和系统上覆盖系统调用指针是微不足道的并且非常强大。在这样的系统上，只需将指针更改为包含恶意代码的任意用户模式可执行缓冲区的地址，然后立即在同一 CPU 内核上执行系统调用指令，就足以获得内核级代码执行。由于现代利用缓解措施，较新的系统不再是这种情况。话虽如此，通过巧妙地使用各种技术，仍然可以绕过大部分缓解措施，并在 Windows 10 甚至全新的 Windows 11 系统（截至 2021 年 12 月）上实现内核级代码执行。

以下部分中的所有缓解措施都适用于大多数现代机器，需要绕过以实现成功的内核模式利用。

SMEP

SMEP 是 2011 年在基于 Ivy Bridge 架构的英特尔处理器中引入的一种保护机制，自 Windows 8.0 起默认启用。它阻止从 Ring 0 执行用户模式页面中的代码，并通过将用户模式或内核模式值分配给页表中每个虚拟内存页面上的标志位来实现。如果系统尝试从内核空间执行用户模式页面中的代码，则会触发0x000000FC错误（ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY ）并导致 BSOD。SMEP 可以在执行期间动态地打开和关闭，其状态分别保存在每个 CPU 内核的CR4寄存器中（参见图 3）。

SMEP 减轻了滥用 MSR R/W IOCTL 的幼稚利用技术，以便将LSTAR MSR 更改为直接指向恶意用户模式代码。话虽如此，由于攻击者控制着系统调用时传递给内核模式的堆栈，因此他们可能会利用一种称为ROP 链的技术来操纵堆栈。通过在堆栈上放置一系列返回地址，攻击者可以通过更改LSTAR来安排在内核模式下执行一组精心挑选的指令MSR 通过易受攻击的 IOCTL。适当准备好堆栈后，执行系统调用指令会导致 ROP 链中的第一个“小工具”执行，完成后其代码将“返回”到链中的下一个小工具，该小工具与其余的堆栈一起提供连锁，链条。

这种 ROP 链的功能受限于内核模块中可用的合适代码块（称为小工具）的可用性。由于攻击者可以从文件系统中读取内核模块并知道模块加载的地址，因此可以轻松查找小工具，如果这些小工具存在，则可以构建一个有效的 ROP 链。

为了正确初始化到内核的转换，ROP 链需要使用SWAPGS指令交换GS寄存器。在 64 位 Windows 上，GS 寄存器在用户模式下保存线程环境块 (TEB) 的地址，在内核模式下保存内核处理器控制区 (KPCR) 的地址。因此，在内核中发生任何操作之前改变这两个地址是至关重要的。毫无疑问，SWAPGS指令也是 Windows 内核KiSystemCall64函数中的第一条指令。

下一步是使用WRMSR指令恢复LSTAR MSR的原始值，以避免在下一次执行SYSCALL指令时执行 ROP 链。

此时，恶意代码在内核中正确执行，攻击者可以执行所需的任何有效载荷。这可以是额外的 ROP 小工具，例如，通过覆盖CR4来禁用 SMEP 或 SMAP 保护，甚至可以直接调用导出的ntoskrnl API 函数。

攻击者可以使用MOV CR4小工具覆盖CR4，以禁用 SMEP 和 SMAP，这将在下一节中介绍。然后他们可以继续直接执行用户模式有效负载。这种方法的唯一困难是预先计算一个有效的CR4值。虽然大部分CR4值可以通过运行CPUID指令从用户态猜测出来，但不同版本的 Windows 之间可能存在一些不一致。

为了安全地转换回用户模式，一旦攻击者的 ROP 链运行，他们需要再次执行SWAPGS指令，然后执行SYSRET指令。

[4], (2015) 中描述了绕过 SMEP 的旧漏洞利用。

SMAP

主管模式访问预防 (SMAP) 是一种较新的缓解措施，已被引入以补充 SMEP 并进一步限制从内核到用户模式页面的访问——它不允许读取和写入。与 SMEP 一样，它的状态作为一个位存储在CR4寄存器中（参见图 3）。

SMAP 应该使前面描述的 ROP 链技术变得无用，因为包含 ROP 链的堆栈实际上是一个用户模式页面。激活 SMAP 的系统在通过系统调用转换到内核后尝试访问堆栈时将出现蓝屏。

SMAP 也可以通过设置EFLAGS CPU 寄存器中的AC标志来临时禁用。这个特性也是这种缓解在 MSR 漏洞利用方面的失败——事实证明，可以在转换到内核模式之前通过使用POPF和PUSHF指令从用户模式设置AC标志。这是由控制在执行SYSCALL指令时清除哪些EFLAGS寄存器位的SFMASK MSR引起的。即使在最新的 Windows 11 机器上，面罩也没有AC 标志位设置，这意味着它不会在转换到内核时被清除，因此用户可以禁用 SMAP。

由于SFMASK由另一个 MSR ( 0xC0000084 ) 控制，即使 Microsoft 更改SFMASK以隐式清除AC标志，理论上攻击者仍可以在利用之前修补此 MSR。

值得注意的是，SMAP 直到最近才在 Windows 10 x64 中使用较新的硬件默认启用。

KVA shadowing

引入 KVA shadowing作为针对2017 年底发现的Meltdown CPU 漏洞的软件缓解措施。

这种缓解的基本思想是将虚拟地址空间分为两部分——用户模式和内核模式。用户模式地址空间只能访问ntoskrnl模块的非常有限的部分，特别是称为.KVASCODE的单个代码部分，它负责处理系统调用时进入和离开内核等低级操作。这是通过实现负责函数的“影子”等价物来处理的，例如作为原始 KiSystemCall64 工作的KiSystemCall64Shadow，但包含负责处理 KVA 映射和正确切换地址空间上下文的差异（参见图 4）。内核的其余部分完全分离并映射到它自己的地址空间，甚至在适当切换上下文之前，即使 CPU 从用户模式地址空间直接访问也无法访问。

虽然 KVA shadowing是为修复 Meltdown 漏洞而设计的，但它也可能对其他类型的漏洞（包括 MSR 漏洞）造成麻烦。

通常有两种方法可以禁用缓解 – 一种是将其作为注册表中的设置禁用。这需要管理员访问权限并在之后重新启动才能使更改生效。

或者，在构建用于 MSR 攻击的 ROP 链时，攻击者会尝试在ntoskrnl模块的.KVASCODE部分中查找小工具——由于该部分处理系统调用转换，因此可以构建一个有效的 ROP 链。

Linux 系统中也引入了类似的缓解措施，称为内核页表隔离 (KPTI)。

物理内存读/写

能够直接读写物理内存似乎是许多低级内核驱动程序中的一个共同特性。这是通过将特定范围的物理内存映射到可以读取或写入甚至传递给用户模式应用程序的虚拟内存缓冲区来实现的。有几种方法可以实现这一点，最常见的一种是将\Device\PhysicalMemory部分映射到虚拟内存的能力，如图 5 所示。

攻击者的一个潜在缺点是他们首先需要将虚拟地址转换为物理地址。实现物理内存 I/O 的驱动程序有时还提供 IOCTL 用于物理到虚拟地址的转换，但即使驱动程序没有任何此类地址转换，仍然有很多方法可以利用此功能。

最直接的用例是简单地遍历所有物理内存，寻找代表攻击者想要找到的关键数据结构的特定工件。例如，攻击者可能会尝试寻找恶意进程的EPROCESS结构，并通过从特权更高的进程中窃取令牌或修改其权限来将其提升到 SYSTEM 权限。这里和这里展示了其中一些策略。

由于物理内存映射不考虑任何虚拟内存保护功能，因此也可以写入可执行内存页面。这使攻击者有机会查找特定的内核模块和代码块，仔细修改它们，如果修补的代码可以通过系统 API 或驱动程序的 IOCTL 执行，则可以实现恶意内核级代码执行。

虚拟内存读/写

虚拟内存访问 IOCTL 在这些驱动程序中不像物理内存驱动程序那样常见，但它们具有非常相似的影响。使用这些更容易，因为不需要地址转换，并且可以直接访问从用户模式找到的所有虚拟内核地址。一个潜在的缺点是访问受到目标地址的内存保护的限制，因此在不首先更改保护的情况下无法写入只读内存页面。

因此，此漏洞通常用于操纵各种内核数据结构，以通过从此类内核结构中窃取令牌来实现诸如将恶意进程提升为 SYSTEM 权限之类的事情。

此漏洞最常见的出现方式是通过 IOCTL 在内核模式下使用简单的指针取消引用，因此使用启发式方法很难检测到此漏洞。

实例探究

当恶意软件参与者需要在 x64 系统上运行带有驱动程序签名强制 (DSE) 的 Windows 内核中的恶意代码时，携带易受攻击的签名内核驱动程序似乎是一个可行的选择。这种技术被称为自带易受攻击的驱动程序 (BYOVD)，并且已被观察到被知名 APT 参与者和商品恶意软件广泛使用。

在以下部分中，我们将介绍一些示例。

Slingshot APT

Slingshot 是卡巴斯基在 2018 年发现的网络间谍平台 [5]，据信至少自 2012 年以来一直处于活跃状态。该恶意软件背后的攻击者决定将其名为 Cahnadr 的主要模块作为内核模式驱动程序实施。在较旧的 x86 系统上，驱动程序将由用户模式模块直接加载。在具有活动 DSE 的较新系统上，他们决定实施自定义驱动程序加载程序，该加载程序利用以下具有 MSR 漏洞的签名内核驱动程序：Goad、SpeedFan ( CVE-2007-5633 )、Sandra ( CVE-2010-1592 ) 和 ElbyCDIO ( CVE -2009-0824）。该漏洞针对的是 Windows 8 之前的系统，因此该漏洞是对LSTAR的简单修改 MSR 指向用户模式缓冲区中的恶意负载。

请注意，卡巴斯基研究人员估计这些威胁参与者从 2012 年到 2018 年一直活跃，这意味着这些漏洞利用非常古老且众所周知，但这并不是攻击者停止使用它们的理由，因为这些易受攻击的驱动程序的证书是从未撤销。

InvisiMole

2018 年，ESET 研究人员发现了一个复杂的 APT 攻击者，他们将其命名为 InvisiMole [6]。从那时起，ESET 就一直在跟踪该小组，并于 2020 年发布了一份关于该小组及其工具集的广泛白皮书。在该白皮书中，我们的同事报告称，InvisiMole 使用 BYOVD 技术，利用speedfan.sys驱动程序 (CVE-2007-5633) 中的 MSR 漏洞加载恶意未签名驱动程序。虽然此活动针对的是较旧的 x86 系统，并且从现代角度来看，使用恶意驱动程序的利用是微不足道的，但由于没有像 SMEP 这样的缓解措施，它仍然是一个有趣的案例，表明这个恶意软件背后的组织非常有技术能力。

然而，在那次调查的后期，发现了使用 BYOVD 技术的 InvisiMole 恶意软件的新变种。此变体是迄今为止我们观察到的唯一一个恶意行为者在 Windows 10 x64 系统上利用 MSR 的案例。它采用先进技术绕过 SMEP 甚至 SMAP 等缓解措施。话虽如此，KVA shadowing缓解了这种利用，但作者未能处理好。巧合的是，MSR 利用被用来部署恶意驱动程序，试图禁用我们的安全产品。尽管整个危害链更为广泛，但我们将关注恶意软件的特定部分，该部分利用 BYOVD 技术和发生在主用户模式模块中的 MSR 漏洞利用。

用户模式模块

InvisiMole 的作者似乎开发了一个复杂的 ROP 链开发框架，他们将其用于 MSR 开发——尽管该示例在代码中包含许多调试消息，但我们无法识别并将它们链接到任何已知项目。这使我们相信该框架是这些恶意软件作者的原创作品，并且已经花费了不可忽视的资源来开发它。该框架是一个包含各种类的扩展 C++ 代码库。

InvisiMole 的作者似乎不知道使用SMAP部分中描述的PUSHF和POPF指令设置AC标志的可能性，而是选择了在MiDbgCopyMemory内核函数中找到的一个非常复杂的 ROP 小工具，该小工具以特权STAC指令开头，专用于设置 AC 标志（参见图 6）。最重要的是，InvisiMole在每个显式设置带有AC标志集的RFLAGS寄存器的小工具之后使用IRETQ指令，从而进一步稳定了漏洞利用。

初始小工具直接跳转到STAC指令，该指令通过设置 AC 标志立即禁用 SMAP。由于这个小工具出现在MiDbgCopyMemory函数的中间，恶意软件会仔细准备堆栈和寄存器以安全地离开该函数。一旦MiDbgCopyMemory函数返回，ROP 链继续到SWAPGS小工具 [7] 以便正确切换到内核模式，然后是WRMSR小工具将LSTAR MSR 设置回其原始值。此时，InvisiMole 将继续执行有效载荷，该有效载荷可能是导出的内核函数或加载的恶意驱动程序的入口点。

驱动程序加载器

驱动程序加载技术相当复杂——InvisiMole 将首先安装一个“驱动程序加载程序”——另一个内核驱动程序模块，用于加载作为参数传递的恶意负载（又一个驱动程序）。为了初始化驱动程序加载器，InvisiMole 执行了几个单独的 MSR 漏洞利用，其中每个实例都带有一个专用的 ROP 链和一个 API 调用有效负载。恶意软件将首先执行ExAllocatePoolWithTag为加载程序分配一个可执行的内核内存缓冲区，然后在用户模式下准备映像以反映其在内核中的未来地址——部分被移动到它们的虚拟偏移量；解决了进口问题，并修复了重定位。映像准备好后，使用memcpy将其从用户模式复制到分配的内核缓冲区来自ntoskrnl模块。

为了在将代码复制到内核后将代码执行转移到加载器，InvisiMole 的作者还利用 MSR 漏洞并在加载器中设计了几个专用的 PE 导出（示例参见图 7），旨在处理来自用户模式系统的转换来电。它的工作方式与 ROP 链小工具非常相似——交换GS寄存器，交换用户模式和内核模式堆栈，将所有寄存器保存在堆栈上，恢复原始LSTAR MSR 值，然后调用实际函数。一旦完成，这个过程就反过来了。

当加载程序在内核中正确初始化时，通过将 LSTAR MSR 更改为内核中的导出地址来执行名为_Start64的导出。在处理到内核的转换之后，_Start64 注册一个延迟例程，负责加载有效负载驱动程序，并返回到用户模式。延迟加载程序将尝试以“正确”方式初始化有效负载驱动程序——创建注册表项和内核驱动程序对象，执行所有必要的步骤以在系统中注册驱动程序，就好像操作系统正在加载驱动程序本身一样，并且最终调用IoCreateDriver。选择了正确的初始化方法，以便加载的有效负载驱动程序可以处理 I/O 请求数据包并使用 IOCTL 与用户模式模块进行通信。

有效负载驱动程序

有效负载驱动程序提供 IOCTL 功能，用于禁用各种通知回调（参见图 8），主要旨在解除第三方安全解决方案，以及保护文件系统中的文件的可能性。特定命令从用户模式模块传递。有趣的是，用户模式模块将尝试禁用内核中 ESET 保护的各个部分。

RobbinHood

在商用恶意软件中看到旨在覆盖尽可能多的人的 BYOVD 技术很少见，但 RobbinHood 勒索软件系列表明它可能仍然有用 [8]。

该勒索软件利用易受攻击的 GIGABYTE 主板驱动程序GDRV.SYS ( CVE-2018-19320；参见图 9 和图 10) 禁用 DSE 以安装其自己的恶意驱动程序。

禁用 DSE 的方式取决于 Windows 版本——在 Windows 7 和更早版本上，直接在 ntoskrnl 模块中修改nt!g_CiEnabled变量。在较新的 Windows 8 到 Windows 11 系统上，ci.dll模块中的变量ci!g_CiOptions被修改。查找这个变量稍微复杂一些，看起来作者采用了一种在 GitHub 上提供的名为DSEFix的开源项目中找到的方法。此外，从Windows 8.1开始，ci.dll中的变量受到PathcGuard的保护，篡改模块最终会导致系统蓝屏，即使变量被改回原来的值。

然后恶意驱动程序被用来杀死一长串进程并删除它们的文件，主要集中在端点保护软件和其他实用程序上。由于终止是从内核模式完成的，因此安全软件采用的大多数自我保护机制都被规避了，并且该技术比试图解除用户模式的保护更有可能成功。

LoJax

2018 年，ESET 研究人员发现了首个在野外使用的 UEFI rootkit。为了访问受害者的 UEFI 模块，该恶意软件利用了一个名为 RWEverything 的强大实用程序。

Microsoft 最近使用基于虚拟化的安全部分中描述的 HVCI 内存完整性功能直接在 Windows 10 和 11 中禁用了 RWEverything 驱动程序。

发现的漏洞

在我们的研究过程中，我们决定不仅要对现有漏洞进行分类，还要寻找新漏洞。我们设置了 YARA 规则来寻找具有特定功能和潜在易受攻击指标的内核驱动程序。我们还创建了一个概念验证利用框架，用于测试新发现的驱动程序并确认它们是可利用的。

我们检查了数百个符合我们标准的不同内核驱动程序，除了找到已经发现的驱动程序外，我们还发现了三个以前不知道易受攻击的驱动程序，其中一些包含几个不相关的错误。即使在几个独立的研究小组解决了这个领域之后，我们仍然能够找到新的漏洞，即使是来自信誉良好的供应商，这表明 Windows 驱动程序安全仍然是一个问题。

虽然我们正在寻找前几节中描述的各种漏洞，但发现具有 MSR 访问权限的漏洞是最容易的，最常见的原因是使用了放弃此功能的特殊特权指令 ( RDMSR / WRMSR )。有趣的是，在许多情况下，此类驱动程序还包含其他类型的漏洞，例如任意物理或虚拟内存读写功能。

AMD μProf (CVE-2021-26334)

我们在AMDPowerProfiler.sys内核驱动程序中发现了一个 MSR 漏洞，该驱动程序是AMD μProf分析软件的一部分。

使该驱动程序脱颖而出的是，一旦安装了底层软件包，该驱动程序就会在每次系统启动时运行。未过滤的 MSR IOCTL 访问加上缺少FILE_DEVICE_SECURE_OPEN标志（参见图 11）和启动时的存在为攻击者提供了利用驱动程序的好机会，即使是非特权用户 – 当攻击者使用 BYOVD 方法时，这是一个优势需要自己加载驱动。

另一方面，该软件是开发人员的利基实用程序，而不是分发到大量系统的软件包。我们尚未在驱动程序中发现任何其他漏洞。

易受攻击的 IOCTL 是IOCTL_ACCESS_MSR ( 0x222030 )。

AMD 承认了该漏洞 ( CVE-2021-26334 ) 并在 2021 年 11 月补丁星期二版本中发布了修复程序。

密码软件

Passmark 是一家提供各种计算机基准测试和诊断工具的公司。为了在用户模式下实现这样的功能，需要通过利用内核模式驱动程序来访问许多低级系统功能。

Passmark 的DirectIo32.sys和DirectIo64.sys内核驱动程序是在多个供应商的应用程序（即 BurnInTest、PerformanceTest 和 OSForensics）之间共享和分发的通用框架。

该驱动程序包含直接的、未过滤的 MSR R/W 访问 ( CVE-2020-15480 )、为读写映射物理内存 ( CVE-2020-15481 ) 的能力，并且 IOCTL 处理程序还包含缓冲区溢出 ( CVE- 2020-15479 ) 由于在没有任何大小检查的情况下盲目地将任意大小的 IOCTL 输入缓冲区复制到堆栈上的局部变量。

Passmark 承认了这些漏洞，并在此后不久发布了一个修复版本。

CVE-2020-15479

当驱动程序接收到来自用户模式程序的 IOCTL 请求时，它将首先将请求的输入缓冲区复制到堆栈上的本地缓冲区中。memmove的大小仅基于输入缓冲区的大小（参见图 12），不考虑堆栈缓冲区的容量。如果提供了足够大的 IOCTL 缓冲区，这可能会导致缓冲区溢出。IOCTL 处理函数中有多个未经检查的memmove调用，并且可以使用多个 IOCTL 来利用缓冲区溢出。

CVE-2020-15480

此驱动程序提供通过 IOCTL 公开的RDMSR和WRMSR功能，允许非特权用户模式程序读取和写入任意 CPU MSR，而无需任何额外检查。易受攻击的 IOCTL 是IOCTL_READ_MSR ( 0x80112060 ) 和IOCTL_WRITE_MSR ( 0x80112088 )。

CVE-2020-15481

物理内存映射功能通过单个控制代码公开 – IOCTL_MAP_PHYSICAL_MEMORY ( 0x80112044 )。实现分为两部分：主要版本通过ZwMapViewOfSection API 完成；如果由于某种原因此方法失败，该函数还通过MmMapIoSpace和MmMapLockedPages内核 API实现辅助方法作为备份。两者都如图 13 所示。

Devid Espenschied PC 分析仪

PC Analyzer 是另一个用于检查机器的各种详细信息的实用程序。与应用程序一起分发的PCADRVX64.sys内核驱动程序包含两个单独的漏洞 – 未过滤的 MSR 访问 ( CVE-2020-28921 ) 和读取和写入任意物理内存地址的能力 ( CVE-2020-28922 )。创建驱动程序设备时，未指定FILE_DEVICE_SECURE_OPEN标志，允许非特权用户检索驱动程序的句柄。

Devid Espenschied 承认了这些漏洞并发布了更新版本。

CVE-2020-28921

与以前的驱动程序一样，MSR 访问不受限制（参见图 14），并且 IOCTL 代码处理程序包含FILE_ANY_ACCESS标志，即使是非特权用户也可以利用该功能。

CVE-2020-28922

驱动程序的物理内存读取和写入功能是根据读取或写入请求的大小使用单独的 IOCTL 实现的。它提供了以下控制代码，它们都不会对请求所针对的内存地址进行任何检查：

IOCTL_READ_PHYSICAL_MEMORY_BYTE（0x82002400）
IOCTL_READ_PHYSICAL_MEMORY_WORD（0x82002500）
IOCTL_READ_PHYSICAL_MEMORY_DWORD（0x82002600）
IOCTL_WRITE_PHYSICAL_MEMORY_BYTE（0x82002700）
IOCTL_WRITE_PHYSICAL_MEMORY_WORD（0x82002800）
IOCTL_WRITE_PHYSICAL_MEMORY_DWORD（0x82002900）

缓解措施

虽然我们已经提到了 CPU 和/或操作系统使用的几种机制，但它们中的大多数都可以通过一些巧妙的技术被绕过，并且如果攻击者提前做好准备，它们中的大部分都不是很有效。在本节中，我们想提及一些在完全阻止滥用易受攻击的驱动程序方面实际上是有效的缓解措施。

基于虚拟化的安全性

基于虚拟化的安全性或 VBS 是 Windows 10 中引入的一项功能，它利用硬件虚拟化并使内核由管理程序沙盒化，以便通过各种保护来保护操作系统。

VBS 提供了多种保护功能，其中最突出的是 Hypervisor-Protected Code Integrity (HVCI)，它也作为独立功能提供。HVCI 在内核中强制执行代码完整性，并且只允许执行签名代码。它还采用了黑名单功能，可以将由特定有效签名签名的已知代码列入黑名单，并且不允许运行或加载。已通过此方法列入黑名单的驱动程序之一是 RWEverything 实用程序。

HVCI 有效地防止易受攻击的驱动程序被滥用来执行未签名的内核代码或加载恶意驱动程序（无论使用何种利用方法），并且似乎恶意软件滥用易受攻击的驱动程序来加载恶意代码是微软实现此功能的主要动机之一：

VBS 对实际攻击提供了显着的安全收益，包括我们去年看到的几种攻击，包括 RobbinHood 等人为操作的勒索软件攻击和 Trickbot 等复杂的恶意软件攻击，这些攻击采用了可以通过 HVCI 缓解的内核驱动程序和技术。我们的研究表明，与未启用 HVCI 的系统相比，启用 HVCI 的计算机向 Microsoft 365 Defender 报告检测到的活动恶意软件报告减少了 60%。Surface Book 3 于 2020 年 5 月发货，Surface Laptop Go 于 2020 年 10 月发货，用户可能没有注意到他们正在运行 VBS，因此基于引擎盖下的工作得到了更好的保护。[重点补充]

除了强制内核代码完整性之外，VBS 还保护重要的 MSR 并禁止对其进行任何更改。不出所料，这种保护也会影响 LSTAR MSR 并减轻上述所有利用可能性。

虽然 VBS 通常可以有效地防止 MSR 攻击和在内核中运行恶意代码，但这项新功能的采用非常有限，因为它有几个硬件要求，只有较新的机器才能满足。还有一些缺点，最显着的是性能下降，根据工作负载的不同，这可能非常明显。虽然一些基准测试估计特定视频游戏的性能影响高达 25% ，但Tom’s Hardware 进行的更详细的基准测试根据具体的基准和硬件配置估计性能损失约为 5%（参见图 15），这仍然不是一个可以忽略的数量，可能会导致一些用户考虑关闭此功能。旧版驱动程序和软件也可能存在一些兼容性问题。随着 Windows 11 的发布，微软决定默认为所有兼容设备启用 HVCI。

第三方管理程序

与 Microsoft 的 VBS 类似，使用足够新的硬件，第三方安全解决方案可能会部署自己的自定义管理程序。在管理程序下运行操作系统可以详细监督机器的状态，并提供检查和拦截任何事件的可能性，包括执行特定指令。与 VBS 一样，这是有代价的，即性能和兼容性。

证书吊销

在现代 Windows 系统上，驱动程序需要具有基于“可接受”证书的有效签名。因此，撤销易受攻击的驱动程序的证书将是一种“解除”它并在大多数情况下使其无用的简单方法。

可悲的是，撤​​销很少发生，在我们上述研究中记录的易受攻击的驱动程序中，没有一个人的签名被撤销。没有发生此类撤销的原因可能有很多，但主要原因可能是时间和成本。由于没有人要求撤销，从供应商的角度来看，要求撤销没有多大意义，因为这将是一个昂贵且耗时的过程。此外，签名证书通常在其他项目之间共享，因此由于单个驱动程序可能导致的撤销可能会阻碍每个项目的开发。

此外，在我们的研究中，我们了解到证书被吊销的驱动程序并不总是被阻止，而且这个问题比最初看起来要复杂得多。毕竟，撤销可能不是最简单的解决方案。

驱动程序黑名单

驱动程序黑名单是 Microsoft 和各种第三方安全产品供应商采用的一种做法。ESET 安全产品会检测到一些最臭名昭著的易受攻击的驱动程序，并在系统上发现时将其删除。微软还选择不仅通过其安全解决方案将驱动程序列入黑名单，而且还直接通过操作系统利用其 HVCI 缓解措施（这是基于虚拟化的安全性的一部分）。虽然黑名单是有效的，但它不是一种主动解决方案——只有以前发现的易受攻击的驱动程序才能被列入黑名单，而且必须由每个供应商手动完成。这意味着这种缓解措施将无法有效应对以前未知的、可能用于复杂 APT 攻击的零日驱动程序漏洞。

可能最突出的列入黑名单的驱动程序是 Capcom “反作弊”驱动程序Capcom.sys，它显式地实现了一个 IOCTL，它在内核模式下简单地执行提供的缓冲区的内容（参见图 16）。为了能够执行从用户模式提供的缓冲区，它甚至会暂时禁用 SMEP！

一经发现，该驱动程序登上了多个头条，许多未签名的驱动程序加载工具都是基于滥用驱动程序的此功能而创建的。因此，该驱动程序最终被包括 Microsoft 和 ESET 在内的许多安全产品供应商列入黑名单。

结论

易受攻击的驱动程序长期以来一直是一个已知问题，并被游戏作弊社区和恶意软件作者滥用，虽然已经做出了一些努力来减轻影响，但它仍然是一场持续的战斗。似乎所有相关的责任方都想解决这个问题——我们联系的供应商在披露过程中非常积极主动，急于修复我们发现的漏洞。微软正试图从内部加强操作系统，最后但并非最不重要的一点是，第三方安全供应商正试图想出聪明的方法来检测和缓解这些驱动程序本身。

然而，似乎仍然缺少一点——一种通用的、统一的处理这些问题的方法，包括更彻底地“解除”驱动的武装，无论是通过撤销或屏蔽他们的证书，还是安全公司采用的一些公开的、共享的屏蔽名单.

参考书目

[1] J. Desimone 和 G. Landau，“ BlackHat 2018：内核模式威胁和实际防御”，2018 年 8 月 9 日。[在线]。
[2] R. Warns 和 T. Harrison，“ INFILTRATE 2019: Device Driver Debauchery and MSR Madness ”，2019 年 5 月 2 日。[在线]。
[3] J. Michael 和 M. Skhatov，“ Defcon 27: Get off the Kernel if you can’t Drive ”，2019 年 8 月 13 日。[在线]。
[4] N. Economou 和 E. Nissim，“ekoparty 2015：Windows SMEP 绕过：U=S ”，2015 年。[在线]。
[5] A. Shulmin、S. Yunakovsky、V. Berdnikov 和 A. Dolgushev，“ The Slingshot APT ”，2018 年 3 月 6 日。[在线]。
[6] Z. Hromcová 和 A. Cherepanov，“InvisiMole：故事的隐藏部分——发掘 InvisiMole 的间谍工具集和战略合作”，2020 年 6 月 18 日。[在线]。
[7] A. Ionescu，“UMPOwn：在 3 幕中从第 3 圈到第 0 圈”，PoC||GTFO，第一卷。2，无淀粉出版社，2018 年，p。768.
[8] A. Brandt 和 M. Loman，“生活在另一块土地上：勒索软件借用易受攻击的驱动程序来删除安全软件”，Sophos，2020 年 2 月 7 日。[在线]。

from

转载请注明出处及链接