利用Microsoft内核Applocker驱动漏洞过程

AppLocker是Windows内置的应用程序白名单技术, 该漏洞(CVE-2024-38041)允许本地攻击者检索可能导致内核地址空间布局随机化（KASLR）绕过的信息，这在未来的Windows版本中可能成为一种需求。本篇文章详细介绍了在Windows内核中进行补丁差异分析的过程，找到该漏洞并构建一个有效的漏洞利用程序。

补丁差异分析基础

补丁差异分析是一种常见的技术, 比较同一代码的两个二进制构建版本: 一个是已知有漏洞的版本，另一个是包含安全修复的版本。它通常用于确定漏洞公告背后的技术细节, 确立漏洞的根本原因、攻击向量和潜在变体。多年来，这种方法吸引了大量研究和工具开发，被证明对于识别nDay漏洞非常有用，这些漏洞可以针对那些未及时安装最新安全补丁的用户进行利用。总体而言，对于可以自由进行逆向工程的软件，修补后漏洞利用的风险是不可避免的，因此被认为是该生态系统的自然组成部分。

类似地，如果多个版本的同一产品共享相同的核心代码但由供应商独立维护，二进制差异分析可以用来发现它们之间的差异。Windows操作系统就是一个这样的例子。

在之前的Windows版本中，绕过KASLR非常简单，因为许多系统调用在输出中包含内核指针。然而，在Windows 11 24H2中，这些内核地址泄露不再对无特权调用者可用。在没有经典的KASLR绕过方式的情况下，要确定内核的布局，仍然需要信息泄露或新的技术。

补丁差异分析(Appid.sys)

为了确定漏洞的具体原因, 通常将比较修补前后的二进制文件, 并尝试使用名为BinDiff的工具提取差异。我已经提前在电脑上保存了这两个二进制版本，因为之前已经习惯跟踪每个月的补丁更新。此外，还编写了一个简单的Python脚本，在应用每月补丁之前转储所有驱动程序，然后再转储修补后的二进制文件。不过，也可以使用Winbindex获取appid.sys的两个版本：一个是补丁前的版本，另一个是补丁后的版本，两者都来自同一个Windows版本。

利用Microsoft内核Applocker驱动漏洞过程

获取二进制文件的连续版本非常重要，因为即使使用相隔几个更新的版本也会引入与补丁无关的差异带来的干扰，并导致在分析时浪费时间。Winbindex 使补丁分析变得更简单，因为可以获取从 Windows 10 开始的任何 Windows 二进制文件。可以先在IDA Decompiler中加载了这两个文件分析。之后，可以使用扩展名 BinExport 将文件导出为 BinExport 格式，然后加载到 BinDiff 工具中。

利用Microsoft内核Applocker驱动漏洞过程

BinDiff 的工作原理是使用各种算法来匹配正在比较的二进制文件中的函数。在本例中，应用了微软的函数符号信息，因此所有函数都可以通过名称进行匹配。

利用Microsoft内核Applocker驱动漏洞过程

上面可以看到只有一个函数的相似度小于100%。该补丁更改的函数是AipDeviceIoControlDispatch。

利用Microsoft内核Applocker驱动漏洞过程

在上图中，可以看到两个以红色突出显示的块已添加到驱动程序的修补版本中。此代码检查传入 IOCTL 数据包的PreviousMode，以验证该数据包来自内核模式而不是用户模式。

漏洞原因分析

下面的截图显示了在 IDA 中查看 AipDeviceIoControlDispatch 的反编译函数代码时，补丁前后的更改代码:

appid.sys 的预补丁版本 Windows 11 22H2:

利用Microsoft内核Applocker驱动漏洞过程

appid.sys 的补丁后版本 Windows 11 22H2:

利用Microsoft内核Applocker驱动漏洞过程

上面显示的此更改是对已识别功能的唯一更新。一些快速分析表明正在基于 PreviousMode 执行检查。如果 PreviousMode 为零（表明调用源自内核），则指针将写入 SystemBuffer 字段中指定的输出缓冲区。另一方面，如果 PreviousMode 不为零并且启用了 Feature_2619781439...，则驱动程序将仅返回 STATUS_INVALID_DEVICE_REQUEST (0xC0000010) 错误代码。

漏洞利用程序开发

第一步是与驱动程序通信以触发其漏洞。要与驱动程序通信，通常需要查找设备名称、获取句柄，然后发送适当的IOCTL代码以访问漏洞。因此, 在DriverEntry函数中分析了IoCreateDevice函数，发现DeviceName的第三个参数为DeviceAppID。

利用Microsoft内核Applocker驱动漏洞过程