在本博客文章中，我将解释 Microsoft Windows DWM Core 库中的一个漏洞，该漏洞是在为 Core Impact 开发利用程序时分析的。该漏洞允许无特权的攻击者以具有 Integrity System 权限的 DWM 用户身份执行代码 (CVE-2024-30051)。
由于当时没有足够的公开信息来开发利用程序，我不得不进行大量逆向工作，因此这里我将展示如何使用 IDA PRO 逆向 Windows 23H2 的 KB5037771 补丁，将使用 BINDIFF 对 dwmcore.dll 版本 10.0.22621.3447 和版本 10.0.22621.3593 进行二进制差异分析，展示堆溢出是如何产生的，然后通过提升权限来利用它，最后创建一个可用的 PoC。
索引：
[Windows DWM Core Library 特权提升漏洞 (CVE-2024-30051) 1](#windows-dwm-core-library-elevation-of-privilege-vulnerability-cve-2024-30051)
[漏洞详情： 2](#vulnerability-details)
[差异分析查找漏洞： 3](#diffing-to-find-the-bug)
[利用 CVE-2024-30051 的 PoC 分析： 8](#analysis-of-the-poc-exploiting-cve-2024-30051)
[1) 初始化 8](#initialization)
[2) 挂钩 8](#hooking)
[3) 创建窗口 16](#creating-the-window)
[4) 创建设备 16](#create-device)
[5) 创建工厂 22](#create-factory)
[6) 创建设备上下文 28](#create-a-device-context)
[7) 创建组合设备 29](#create-a-composition-device)
[8) 调用 hook3 函数 31](#calling-dcompositioncreatedevice-function)
[9) 为 HWND 创建目标 32](#creating-a-target-for-handle-hwnd)
[10) 创建表面 33](#creating-surface)
[11) 调用 BeginDraw、EndDraw 和 CreateVisual 34](#calling-begindraw-enddraw-and-createvisual)
[11) 调用 Visual SetContent 36](#calling-visual-setcontent)
[12) 释放对象 38](#release-objects)
[13) 提交组合设备 38](#commit-composition-device)
[14) 调用 hook2 39](#calling-hook2)
[15) 调用 hook 39](#remember-that-the-vulnerable-function-can-be-reached-using-some-methods-of-the-cprimitivegroup-class.-at-this-point-it-creates-a-heap-then-hook2-captures-and-saves-the-corresponding-heaphandle.)
[16) 调用 hook4 41](#calling-the-function-hook4)
[17) 执行堆喷射 49](#performing-heap-spray)
[18) 发送前修改基础块 51](#modifying-the-base-chunk-before-send)
[19) 调试 DWM 进程 52](#debugging-the-dwm-process)
[20) 提升权限至 Integrity System 级别 62](#elevating-privileges-to-integrity-system-level)
Windows DWM Core Library 特权提升漏洞 CVE-2024-30051
发布时间：2024 年 5 月 14 日
分配 CNA：Microsoft CVE-2024-30051
影响：特权提升
最高严重性：重要
弱点：
CWE-122：基于堆的 缓冲区溢出
CVSS：3.1 7.8 / 7.2
漏洞存在于 Windows 主 DWM 库 dwmcore.dll 中整数除法的尺寸计算错误。本地用户可以在 dwmcore.dll 的 CCommandBuffer::Initialize 方法中导致堆缓冲区溢出，并可以以具有 Integrity System Privileges 的 DWM 用户身份执行任意代码。利用程序将在 DWM 进程中执行堆喷射来准备内存，最终在 dwmcore.dll 中产生堆溢出，该溢出通过释放堆喷射的某些部分来触发。
一旦利用成功，DWM 进程将加载我们精心制作的 DLL，该 DLL 以具有 Integrity System Privileges 的 DWM 用户身份执行我们的代码或可执行文件（在我们的例子中是 CMD）。
让我们逐步分析这个漏洞，看看它如何允许我们以 Integrity Level SYSTEM 的 DWM 用户身份运行。请注意，由于这不是属于 Administrators 组的用户，它有一些权限限制。
Windows 11 23H2 的补丁可以从以下地址下载：
https://www.catalog.update.microsoft.com/Search.aspx?q=KB5037771
windows11.0-kb5037771-x64_19a3f100fb8437d059d7ee2b879fe8e48a1bae42.msu
dwmcore.dll 的易受攻击版本是：10.0.22621.3447
dwmcore.dll 的修补版本是：10.0.22621.3593
分析更改的函数后，很明显修补版本的 CCommandBuffer::Initialize 添加了大量块，使其看起来与未修补版本大不相同。
静态逆向该函数后，有两个对 CD2DSharedBuffer::GetBufferSize 的调用。
第一次调用获取要分配给 new 的 size，第二次调用获取相同的 memcpy 的大小。
一切最初看起来都是正确的。然而，在分配之前，它对大小执行了一些操作。
它通过调用相同的 CD2DSharedBuffer::GetBufferSize 函数获取 buffer_size 和 buffer_size2，两者返回相同的值。但在 new 中，它执行了一个前操作，将 buffer_size 除以 0x90 再乘以 0x90，而在 memcpy 中，它直接使用返回的 buffer_size2 而不对其进行操作。
通过这些操作，我发现最终用于 new 和 memcpy 的大小可能不同。
buffer_size = buffer_size2（返回的大小）
size_new = buffer_size/0x90 x 0x90
size_memcpy = buffer_size2
例如，如果 buffer_size 是 0x91
buffer_size = buffer_size2 = 0x91
size_new = buffer_size/0x90 x 0x90 = 0x90
size_memcpy = buffer_size2 = 0x91
这个例子证明存在 堆溢出。它复制了比分配更多的字节，并且大小是可控的。
例如，如果 buffer_size 是 0x23f，就像他们在 POC 中使用的那样。
buffer_size = buffer_size2 = 0x23F
size_new = buffer_size/0x90 x 0x90 = 0x1b0
size_memcpy = buffer_size2 = 0x23f
分析了易受攻击的函数后，我想了解如何到达易受攻击的函数 CCommandBuffer::Initialize。事情从这里开始变得复杂。
回过头来查看对该函数的引用，它似乎是通过 CPrimitiveGroup 类的方法到达的：
这些方法可以从 CPrimitiveGroup 对象的 vftable 访问：
它有它的 构造函数：
并且是这样到达的：
最初我经历这个过程时，花时间阅读了 PDF “The Lost World of DirectComposition: Hunting Windows Desktop Window Manager Bugs” 并深入研究了 Direct Composition 的世界。这帮助我创建了第一个 PoC。
另外，我需要逆向 win32ksys 并尝试通过以下函数发送数据包：
NtDCompositionCreateChannel
NtDCompositionProcessChannelBatchBuffer
NtDCompositionCommitChannel
我的第一个 PoC 到达了 CPrimitiveGroup 的构造函数。然而，经过大量逆向后，我未能找到一种方法，通过这些函数的 ALPC 调用直接处理对 vftable 方法的调用来到达易受攻击的函数。
我花了很多时间进行一些复杂的逆向工作。在这个过程中，我找到了利用此漏洞的恶意代码样本，这非常有帮助，因为利用方法比我最初想象的要复杂得多。它还包含多个系统 API 的挂钩，并使用了一些可能有点可疑的方法。但在战争和漏洞利用中一切都是有效的，因此我开始分析恶意代码，并根据分析创建了我的最终 PoC，最终成功利用了该漏洞，我将在下面解释这一点。
首先，我想澄清的是，恶意代码不仅利用了 CVE-2024-30051 漏洞将我们的进程提升到 Integrity System 级别，而且还执行了第二部分，最终提升到一个具有所有权限的 SYSTEM 用户，这已经超出了所解释的 CVE 范围。
此外，需要注意的是，恶意代码比我的 PoC 复杂得多，我的 PoC 试图最小化代码。恶意代码执行了更多检查以确保可靠性，因此它在第一次尝试时就成功了。我丢弃了所有那些检查以简化代码，并专注于纯粹的利用，甚至可能需要运行 PoC 两到三次才能成功利用。
可执行的 PoC 链接是 https://github.com/fortra/CVE-2024-30051
首先，PoC 调用 GetVersion 获取其运行的操作系统版本，并根据版本对某些全局变量执行不同的初始化。我的 PoC 在 Windows 11 23H2 和 Windows 11 22H2 上进行了测试。其他系统也存在漏洞，并添加了利用它们所需的值。
它挂钩了四个系统函数，如果不挂钩这些函数，就无法成功利用。这些系统函数是：RtlAllocateHeap、RtlCreateHeap、NtDCompositionCreateChannel 和 NtDCompositionCommitChannel。
