微軟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重構該部分內核代碼,未來此類漏洞可能被杜絕。本次漏洞利用過程相對簡單,主要難點在於如何控制第一次寫入。該漏洞的發現可能依賴於更完善的代碼覆蓋率檢測。對於漏洞檢測而言,除了關注觸發函數的關鍵點,對異常的內存布局和數據偏移讀寫的檢測也是發現同類漏洞的可能途徑。