微软Windows系统漏洞可能导致Web3安全风险

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

此类漏洞的利用由来已久。在当前新的安全缓解措施不断改进的背景下,我们希望分析攻击者可能如何继续利用这一漏洞。本文的分析过程是在Windows Server 2016环境下完成的。

这种零日漏洞未被公开和修复,可被恶意利用而不被察觉,具有极大破坏性。通过该漏洞,黑客可获取Windows系统的完全控制权。这可能导致个人信息被窃取、系统崩溃、数据丢失、财务损失、恶意软件植入等严重后果。对Web3用户而言,私钥可能被盗取,数字资产可能被转移。从更广泛的角度看,这个漏洞甚至可能影响基于Web2基础设施运行的整个Web3生态。

通过分析补丁,我们发现问题出在对象的引用计数被多处理了一次。win32k是较老的代码,早期源码注释显示,以前的代码只锁定了窗口对象,没有锁定窗口对象中的菜单对象,这可能导致菜单对象被错误引用。

在实现概念验证(PoC)时,我们发现传入xxxEnableMenuItem()的菜单通常已在上层函数被锁定,不清楚这里要保护哪个菜单对象。进一步分析发现,MenuItemState函数返回的菜单可能是窗口主菜单,也可能是子菜单甚至子子菜单。

为触发漏洞,我们构造了一个特殊的四层菜单结构,并设置了一些特定条件以通过xxxEnableMenuItem函数的检测。在xxxRedrawTitle返回用户层时,我们删除了菜单C和B的引用关系,成功释放菜单C。最终,当xxxEnableMenuItem函数返回到xxxRedrawTitle时,即将引用的菜单C对象已经无效。

在开发漏洞利用(Exp)时,我们主要考虑了两种方案:执行shellcode和利用读写原语修改token地址。考虑到可行性,我们选择了后者。整个利用过程可分为两步:如何利用UAF漏洞控制cbwndextra的值,以及如何实现稳定的读写原语。

我们通过精心设计内存布局,使用窗口类WNDClass中的窗口名称对象占用被释放的菜单对象。通过xxxRedrawWindow函数中的特定操作,我们实现了第一次数据写入。

为实现稳定的内存布局,我们设计了连续三个HWND对象,释放中间一个并用HWNDClass对象占用。前后的HWND对象分别用于通过检验和实现读写原语。我们还通过内核句柄地址泄露来精确判断对象排列是否符合预期。

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

虽然win32k漏洞由来已久,但微软正在尝试用Rust重构相关内核代码,未来新系统中此类漏洞可能被杜绝。本次漏洞利用过程相对简单,主要难点在于如何控制第一次写入。该漏洞严重依赖桌面堆句柄地址泄露,这仍是老旧系统的安全隐患。

我们推测该漏洞的发现可能得益于更完善的代码覆盖率检测。对于漏洞利用检测而言,除了监控关键点,对异常内存布局和窗口数据读写的针对性检测也可能有助于发现此类漏洞。