CVE-2022-24481

一、漏洞信息

CVE-2022-24481是发生在CLFS驱动中的一个类型混淆漏洞，通过精巧的对blf文件的部分数据进行构造，可使LogBlockHeader中的ClientContextOffset指向ContainContext，从而造成类型混淆。

二、测试环境及漏洞复现

测试环境

• POC： 4c1579c6a14bb8f3985be8a1a83c731c
• 靶机： win10 x64 专业版，21H2

漏洞复现

三、漏洞成因分析

CLFS内部结构

CLFS即通用日志文件系统是在 Windows
Vista 和 Windows Server 2003 R2 中为实现高性能而引入的日志框架，它负责提供一个高性能、通用的日志文件子系统，供专用客户端应用程序使用，提供 API 函数来创建、存储和读取日志数据。并且多个客户端可以共享以优化日志访问。CLFS驱动本质上的作用就是对BLF 日志进行格式解析及处理。

BLF日志的格式如上图所示，每个日志块都以一个名为**_CLFS_LOG_BLOCK_HEADER**的结构开始：

Checksum(0xC)字段是该Log文件的CRC校验和，在对Log文件进行编码/解码操作时都需要对文件进行校验，通常在CLFS漏洞利用实现过程中都需要绕过CRC校验。

RecordOffsets(0x28)是日志块内记录的偏移量数组。CLFS
只处理指向 _CLFS_LOG_BLOCK_HEADER末尾的第一个记录偏移量 (0x70)。当基本日志文件存储在磁盘上时，必须对其日志块进行编码。

基本日志记录存储用于将基本日志文件与容器相关联的元数据。其结构如下：

rgClients（0x1a8）和rgContainers(0x398)字段分别是存储着ClientContext和ContainerContex偏移值的数组。

ClientContext的结构：

ContainerContext的结构：

pContainer(0x18) 实际上包含一个内核指针, 指向在运行时描述容器的类CClfsContainer。当Log文件在磁盘上时，该字段必须设置为零。

获取ClientContext/ContainerContext的函数分别是CClfsBaseFile::AcquireClientContext及

CClfsBaseFile::AcquireContainerContext，大致流程均是先通过CClfsBaseFile::GetBaseLogRecord获取基本日志块的地址，然后通过GetSymbol函数通过偏移找到对应的Context结构。

漏洞触发

CVE-2022-24481漏洞原因在于CClfsBaseFile::GetSymbol获取ClientContext时对其字段的校验不够严格，攻击者进行精巧的数据布局后使rgClients的偏移指向ContainerContext。

1. 添加容器（Container）

为Log文件添加容器，以便 BaseLogRecord中拥有ContainerContext。

2. 数据构造

成功创建Log文件并为其添加容器后，BaseLogRecord 0x1368和0x1528的偏移处分别存储着ClientContext和ContainerContext

数据构造的目的是为了绕过CLFS在解析Log文件对context的校验。

第一部分绕过Log文件的crc校验。Log文件的BaseLogRecord在进行编码和解码都会进行CRC校验。

在触发过程中，为绕过CLFS对Checksum字段的检查，需要自己实现一次CRC校验并将结果填充至Checksum（0xc）

第二部分，对ClientCotext的数据进行修改，使其能够成功的绕过CLFS的检查最后指向ContainerContext。

首先，更新_CLFS_LOG_BLOCK_HEADER中 rgClients（0x1a8）字段，使rgClients存储的偏移值变为0x1520(ContainerContext offset为0x1528)

然后在0x1510及0x1514偏移处分别存储ClientContext新的起始偏移地址（0x1520）以及ClientContext的结尾偏移地址（0x1520+size(0x88)。

构造这两处值是为了绕过在CClfsBaseFile::GetSymbol函数中的相关检查，以使CLFS在调用

CClfsBaseFile::AcquireClientContext能够成功获取ClientContext。

完成以上步骤之后，rgClients已成功指向ContainerContext。

四、漏洞利用分析

漏洞成功触发之后，下一步就是要实现提权利用，对于此漏洞我们需要重点关注以下两个点：

• 借助ClientContext对ContainerContext的修改能力
• ContainerContext中pContainer(可将其指向R3内存)

1. 修改pContainer

成功利用该漏洞前提就是能够控制pContainer指向的值，第一步就是通过ClientContext修改ContainerContext->pContainer的值。由于为Log文件添加容器之后，需要再次调用CreateLogFile对BaseLogRecord进行一次初始化更新

大致逻辑首先获取ClientContext

将ClientContext中的数据保存到CclfsLogFcbPhysical类中，此处重点关注rcx+20h处的值，现存储着我们pContainer的目标值（r3可控地址0x40000000）。

随后会调用CClfsBaseFilePersisted::LoadContainerQ函数加载Container并更新pContainer,让其指向在运行时描述容器的类CclfsContainer

CclfsContainer类的前8个字节指向虚表

此时pContainer还是指向内核的CclfsContainer类，我们的可控地址0x40000000被保存到了CclfsLogFcbPhysical类的0x1a0处，经过分析发现，在close Log文件句柄过程中，CLFS会调用CClfsLogFcbPhysical::FlushMetadata对ClientContext进行更新

实际上就是将存储在CclfsLogFcbPhysical类中的数据重新写回到ClientContext。

由于ClientContext指向ContainerContext-0x8，这里将0x40000000赋给ClientContext+0x20就是修改ContainerContext+0x18(pContainer)为0x0x40000000。

2. 修改previousMode

执行CloseHandle时，内核中首先会将当前线程的previousMode修改为内核态（0）

待到成功执行完返回R3前，又会将当前线程的previousMode修改为用户态（1）

此漏洞的提权原理就是在返回R3前，修改当前线程的previousMode为0，下图为我们自定义构造由pContainer指向的” CclfsContainer”.

0x0为“虚表指针“，0x20为文件句柄，0x30为previousMode+0x30 address

漏洞利用是发生在CClfsLogFcbPhysical::CloseContainers函数中

在CClfsLogFcbPhysical::CloseContainers首先通过ContainerContext获取到pContainer，然后对CclfsContainer类进行一个清理释放。这里我们拥有一个可控函数的执行！

CClfsContainer::Close实现：

提权过程：

随后调用ObfDereferenceObjectWithTag传入的参数为previousMode+0x30，并利用该函数的减数机制，将previousMode修改为0（内核态）

此时，已到达提权目的。

最后，调用可控函数ClfsSetEndOfLog返回错误码到R3。

在提权样本中，利用当前线程的内核执行能力将当前线程的token替换为system token。

Token替换之后，在将previousMode改回1（目的是混淆）

至此，分析完毕！