微软0day漏洞分析:可能危及Web3基础设施安全

上个月微软的安全补丁中包含一个在野利用的win32k提权漏洞。该漏洞似乎只存在于早期系统版本,无法在Windows 11上触发。这类漏洞的利用由来已久,本文将分析在当前新缓解措施不断改善的背景下,攻击者可能如何继续利用这个漏洞。我们在Windows Server 2016环境下完成了整个分析过程。

0day漏洞是指未被披露和修补的漏洞,可被黑客在未被察觉的情况下恶意利用,往往具有极大的破坏性。本次发现的0day漏洞位于Windows系统层面,黑客可通过它获取Windows的完全控制权。被控制后可能导致个人信息窃取、系统崩溃数据丢失、财务损失、恶意软件植入等后果。小范围可能导致私钥被窃取,数字资产被转移;大范围可能危及基于Web2基础设施运行的整个Web3生态。

补丁分析显示,这似乎只是一个对象引用计数被多处理了一次的问题。但查看早期源码注释发现,以前的代码只锁定了窗口对象,没有锁定窗口对象中的菜单对象,这可能导致菜单对象被错误引用。

分析漏洞函数上下文,我们发现传入xxxEnableMenuItem()的菜单通常已在上层函数被锁定,那这里究竟要保护哪个菜单对象?进一步分析发现,xxxEnableMenuItem中返回的菜单有两种可能:窗口主菜单或菜单的子菜单(甚至子子菜单)。

为构造POC,我们设计了一个特殊的四层菜单结构,并对各菜单进行了特殊设置以通过函数检测。在xxxRedrawTitle返回用户层时,我们删除了菜单C和菜单B的引用关系,成功释放菜单C。这样在xxxEnableMenuItem函数返回点时,即将引用的菜单C对象已经无效。

对于EXP实现,我们主要考虑了两个方向:执行shellcode代码和利用读写原语修改token地址。考虑到高版本Windows的安全机制,我们选择了后者。整个利用过程可分为两部分:如何利用UAF漏洞控制cbwndextra值,以及如何建立稳定的读写原语。

我们通过精心设计的内存布局,利用窗口类的窗口名称对象占用释放的菜单对象,并在xxxRedrawWindow函数中找到了可写入数据的时机。为实现稳定的内存布局,我们设计了连续三个HWND对象的结构,并通过堆内存中泄露的内核句柄地址来精确判断对象排列顺序。

在读写原语方面,我们使用GetMenuBarInfo()实现任意读,SetClassLongPtr()实现任意写。除了替换TOKEN的写入操作依赖第二个窗口的class对象外,其他写入都利用第一个窗口对象的class对象通过偏移实现。

总的来说,虽然win32k漏洞历史悠久,但微软已在Windows 11预览版中尝试用Rust重构该部分内核代码,未来此类漏洞可能被杜绝。本次漏洞利用过程相对简单,主要难点在于如何控制第一次写入。该漏洞的发现可能依赖于更完善的代码覆盖率检测。对于漏洞检测而言,除了关注触发函数的关键点,对异常的内存布局和数据偏移读写的检测也是发现同类漏洞的可能途径。