免责声明：金色财经所有资讯仅代表作者个人观点，不构成任何投资理财建议。请确保访问网址为（jinse.cn）举报

Numen 独家：微软 0day 漏洞可系统+物理层面掀掉 Web3 牌局

Numen Cyber

刚刚

引言：

在上个月微软的安全补丁中，包含一个在野利用的 win32k 提权漏洞。该漏洞似乎不能在 win11 的系统版本上触发，仅存在于早期系统。

这类漏洞的利用来源已久，此次，我们希望分析这类在当前新缓解措施不断改善的背景下，攻击组织是可能如何继续利用这个漏洞。

我们在 server2016 下完成整个分析过程。

背景补充：

0day 漏洞，即零日漏洞，指未被披露和修补的漏洞，时间概念上类比于 Web3 更为人熟知的概念，是 T+0 交易。0day 漏洞被发现后可以在未被察觉的情况恶意利用，这类攻击往往具备极大的破坏性。

Numen Cyber 本次发现的 0day 漏洞是微软 Windows 系统层面的漏洞，通过该漏洞，黑客可获取 Windows 的完全控制权。

被黑客控制所有权的后果，包括不限于个人信息窃取、系统崩溃数据丢失、财务损失、恶意软件植入等，小范围说，你的私钥可以被窃取，以及数字资产被转移。大范围说，这个漏洞能掀掉基于 Web2 基础设施运行的 Web3 牌局（可查看今日次条获取更多文章）。

图标仅为示意

补丁分析

分析补丁，我们似乎并不能太直观看出是什么问题，这里仅仅似乎是一个对象的引用计数被多处理了一次：

但因为win32k是比较古老的代码，我们能找到一些早期的源码注释：

这样就非常好理解了，这里说明以前的代码只是锁定了窗口对象，没有锁定窗口对象中的菜单对象，这里菜单对象可能被错误引用。

实现 poc

https://github.com/numencyber/Vulnerability_PoC/blob/main/CVE-2023-29336/poc.cpp

如何错误的引用这个窗口中的菜单对象呢？

分析漏洞函数上下文，我们发现一个问题，传入到 xxxEnableMenuItem（）的菜单，通常已经在上一层函数被锁定，那这里到底是要保护哪一个菜单对象呢？

继续分析 xxxEnableMenuItem 中，对菜单对象的可能处理过程，我们终于发现 xxxEnableMenuItem 中的 MenuItemState 函数返回的菜单有两种可能，一种就是窗口中的主菜单，但也有可能是菜单中的子菜单，甚至子子菜单。

poc 中，我们构造一个特殊的菜单（这里是三层，四个菜单）：

上面相邻的菜单都是父子关系，如菜单D 是菜单C 的子菜单。

并且这些菜单有以下一些特点（这些特征都是为了通过 xxxEnableMenuItem 函数中的检测和判断，因为这和该漏洞产生原理有关）：

菜单D 中，必须其 ID 类型必须为系统菜单类型的一种，如：0xf060（关闭菜单）.
菜单A 也必须是系统菜单，为了在后续的菜单遍历过程中在菜单C 中的子菜单中寻找到我们指定的系统菜单类型 0xf060（菜单A 中如果包含我们要找的系统菜单类型，会提前结束菜单查找过程）。我们需要删除菜单A 中的对应系统菜单类型 0xf060。
删除掉菜单C 在菜单B 中的引用，才能在返回用户层的过程中彻底释放菜单C。
为什么需要菜单B，这里我们并不确认这是否是必须以及原理，但如果没有菜单B 这一层，似乎菜单C 的释放仍有一些不顺利。

在 xxxRedrawTitle 返回用户层的时候，删除菜单C 和菜单B 的引用关系，然后成功释放该菜单C。

最后，回到内核中的 xxxEnableMenuItem 函数的 xxxRedrawTitle 函数返回点时，后面即将引用的菜单C 对象已经无效。

实现 exp

A. 整体思路

在确定使用哪种利用思路之前，我们通常希望做一些理论上的前期判断，以避免一些不能绕过关键问题的方案会浪费大量尝试时间。这也是在分析其他漏洞 poc 或者 exp 的一个常规过程。

本次漏洞 exp 构造前，我们主要有以下两种考量方向：

执行 shellcode 代码：

这个思路参考早期的 CVE-2017-0263 和 CVE-2016-0167。这种方式我们并没有尝试，因为在该漏洞的这个方案下，执行 shellcode 的入口点以及一些例如 SMEP 的安全机制问题在高版本 windows 中，可能并没有一些方便且已经公开的解决方式。

利用读写原语修改 token 地址：

即使在最近的两年，依然已经有公开的 exp 可以参考。其中对于桌面堆内存布局以及桌面堆中的读写原语具有长久的通用性。我们现在唯一需要花更多时间完成的只是分析出 UAF 内存被重用时，如何第一次控制 cbwndextra 为一个特别大的值。

所以，这里我们将整个 exp 利用拆分为两个问题。一个是如何利用 UAF 漏洞控制 cbwndextra 的值，另一个则是控制 cbwndextra 值后，稳定的读写原语方式。

B. 如何写入第一次数据

当我们最开始触发漏洞时，系统并不总会 crash。因为我们的漏洞触发方式里，我们已经去掉了被重用漏洞在系统中所有的其他关联。

系统可能错误使用这个被我们控制内存的窗口对象数据基本只有 xxxEnableMenuItem 函数中的 MNGetPopupFromMenu() 和xxxMNUpdateShownMenu()。

我们使用窗口类 WNDClass 中的窗口名称对象来占用漏洞触发中我们释放的菜单对象。

我们能够实现第一次的数据写入时机也在这其中。

我们需要做的只有一件事，就是找到一个可以由我们构建的地址结构中，能够被任意写入数据的地方。哪怕仅仅一个字节（我们可以将这个字节写入到 cbwndextra 的高位）。

此过程如在迷宫中寻找一条出路，不再赘述。

最终我们有 xxxRedrawWindow 函数中的两个预备的方案。

如果使用 GreCreateRectRgnIndirect，交换相邻内存数据的方式有两个困难。

一是 cbwndextra 的前一个8位是一个非常不易控制的参数，并且似乎只能在有限的条件下短暂为1.另外使用这种方式时，cbwndextra 的其他相对偏移会定位到前一个对象（无论任何对象，因为这里只和窗口对象 cbwndextra 偏移本身大小有关）的最后8位，这是一个堆链表尾的安全字节，其不易受控。

所以我们使用了第二个地址写入点，即依靠一个标志位的 AND 2 操作。但同样，由于上述的堆链表尾的安全字节不易受控的原因，我们变换以下思路：

我们并不写入窗口对象的 cb-extra，而是写入 HWNDClass 的 cb-extra。这是因为后者的 cb-extra 偏移相对于前者的 cb-extra 偏移更小，我们可以通过布局内存，控制前一个对象的内存数据来当作通过 xxxRedrawWindow 函数中，对对象标志判断的参数。