微软0day漏洞分析:可能对Web3基础设施造成重大威胁

上个月微软安全补丁中包含一个在野利用的win32k提权漏洞。该漏洞似乎只存在于早期Windows系统,无法在Windows 11上触发。

这类漏洞的利用由来已久。本文将分析在当前新的缓解措施不断改善的背景下,攻击者可能如何继续利用这个漏洞。我们在Windows Server 2016环境下完成了整个分析过程。

0day漏洞指未被披露和修补的漏洞,可在未被察觉的情况下被恶意利用,具有极大的破坏性。本次发现的0day漏洞位于Windows系统层面,黑客可通过该漏洞获取Windows的完全控制权。

被黑客控制系统可能导致个人信息泄露、系统崩溃数据丢失、财务损失、恶意软件植入等后果。对Web3用户而言,私钥可能被窃取,数字资产被转移。从更大范围来看,这个漏洞甚至可能影响到基于Web2基础设施运行的整个Web3生态。

补丁分析

分析补丁后发现,问题似乎只是一个对象的引用计数被多处理了一次。由于win32k代码较为古老,我们能找到一些早期的源码注释,说明以前的代码只锁定了窗口对象,没有锁定窗口对象中的菜单对象,这里菜单对象可能被错误引用。

漏洞利用概念验证(PoC)

我们发现,传入xxxEnableMenuItem()的菜单通常已经在上层函数被锁定。进一步分析发现,xxxEnableMenuItem中的MenuItemState函数返回的菜单有两种可能:窗口的主菜单,或菜单中的子菜单(甚至子子菜单)。

在PoC中,我们构造了一个特殊的四层菜单结构,并对各级菜单设置了特定属性,以通过xxxEnableMenuItem函数中的检测和判断。关键步骤包括删除某些菜单引用关系,在xxxRedrawTitle返回用户层时释放特定菜单对象等。

漏洞利用(Exp)实现

整体思路

我们主要考虑了两种利用方向:执行shellcode代码,以及利用读写原语修改token地址。考虑到各种因素,我们选择了后者。

整个exp利用可拆分为两个关键问题:如何利用UAF漏洞控制cbwndextra的值,以及如何在控制cbwndextra值后实现稳定的读写原语。

实现第一次数据写入

我们利用窗口类WNDClass中的窗口名称对象来占用释放的菜单对象。关键是找到一个可由我们构建的地址结构中能够被任意写入数据的位置。

最终我们选择了通过xxxRedrawWindow函数中的一个标志位AND 2操作来实现写入。我们写入HWNDClass的cb-extra而非窗口对象的cb-extra,以便更好地控制内存布局。

稳定的内存布局

我们设计了至少三个连续的0x250字节HWND对象的内存布局,释放中间一个,用0x250字节的HWNDClass对象占用。前后的HWND对象分别用于通过检验参数和作为读写原语媒介。

我们通过堆内存中泄露的内核句柄地址来精确判断申请的窗口对象是否按预期排列。

读写原语的修改

我们使用GetMenuBarInfo()实现任意读,使用SetClassLongPtr()实现任意写。除替换TOKEN的写入操作外,其他写入都利用第一个窗口对象的class对象使用偏移来完成。

总结

1. win32k漏洞虽然由来已久,但微软正在尝试使用Rust重构相关内核代码,未来新系统中此类漏洞可能被杜绝。

2. 本次漏洞利用过程相对简单,主要难点在于如何控制第一次写入。漏洞仍严重依赖桌面堆句柄地址的泄露,这对老旧系统仍是一个安全隐患。

3. 该漏洞的发现可能得益于更完善的代码覆盖率检测。

4. 对于漏洞利用检测,除关注漏洞触发函数的关键点外,还应针对性检测异常的内存布局和窗口数据读写操作。