内核漏洞利用之CVE-2020-17382篇（上）

在本文中，我们将以CVE-2020-17382漏洞为例来介绍内核漏洞如何被武器化的。

序言——为何驱动程序仍然是一个有价值的目标？

毫无疑问，内核是一个非常复杂的软件，即使Windows操作系统也不例外。由于缺乏源代码和无正式文档说明的API，它一直是最难审查的对象之一；现在，由于研究社区的巨大努力，相关的资料已经越来越丰富了。令人遗憾的是，近来内核不仅在复杂性上有所增加，同时，其缓解方式也有所改进。那为，攻击者什么要攻击驱动程序呢？除了Microsoft附带的驱动程序之外，第三方驱动程序也是第三方将代码执行权限提升至ring 0级别的唯一且轻松的途径。不过，从Windows 1607 Anniversary Update开始，目前仅允许加载具有WHQL认证进程签名的驱动程序，因此，构造带有“漏洞门”的代码并将其植入内核空间已经难上加难了。有关驱动程序签名过程的更多信息，请参见此处。

在这篇文章中，我们将为大家介绍的是一些“低垂的果实”，即那些隐藏在已签名的、受信任的生产性驱动程序中仍未被发现的漏洞，这些漏洞往往被广泛部署在消费者和企业终端上。

实际上，这些可利用的内核驱动程序漏洞可以将无特权的用户提升至SYSTEM权限，因为漏洞驱动程序可供任何本地用户使用。（好吧，有时易受攻击的驱动程序或内核组件甚至可以被远程利用：EternalBlue，大家还有印象吧？）

在这里，我们的主要目的，就是为大家介绍一套通过IDA和WinDbg完成漏洞的初步分析，然后运行简单的模糊测试，最后自下而上构建exploit的通用方法。

本文构建的exploit是基于CoreSecurity公司的安全研究人员Lucas Dominikow在MSI的Ambient Link驱动程序中发现的一个安全漏洞。虽然我们为Windows 7 SP1构建的exploit已经非常可靠了，但还不够优雅，不过，我们的重点还是Windows 10平台。

下面是我们已经测试过的两个Windows 10版本，分别为1709和2004版本奇热：

· 19041.1.amd64fre.vb_release.191206-1406

· 16299.15.amd64fre.rs3_release.170928-1534

不过，我们不打算深入讨论2004版本，因为除了ROP gadget的偏移量之外，它和1709版本几乎一样。另外，PoC可以从我们的Github下载。

驱动程序的组织结构

从某种意义上讲，驱动程序只不过是一个可加载的内核模块，这意味着，除非写成完全独立的程序，否则它免不了要跟用户模式中的代码进行交互；不过，在此之前，用户模式的应用程序必须获得驱动程序的有效句柄，这只是与ring 0级别的代码进行通信的一种安全方式。

设备对象

正如我们很快就会看到的那样，用户应用程序可以通过调用CreateFile API来获取一个有效的句柄。这个函数需要接受一个符号链接，在我们的例子中，这个链接就是一个DEVICE_OBJECT元素。这个设备对象是由驱动程序本身创建的，作为任何用户应用都可以使用的通信通道，如果没有采取适当的访问控制的话，这肯定会增加攻击面——这一点是毋庸置疑的。

实际的设备对象是由Windows I/O管理器进行控制的，一旦收到有效的请求，它就会给用户模式的应用程序返回一个有效的句柄。

获取驱动程序句柄

DriverEntry与Driver对象

DriverEntry是驱动程序的入口点，它存在于每个驱动程序中。我们可以把它看作是驱动程序的main函数，类似于用户模式应用程序中的main函数。

DriverEntry函数接受的第一个参数是DRIVER_OBJECT结构体。这个结构体是由内核创建的，并且会在没有完成初始