微軟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. 對於漏洞利用檢測,除關注漏洞觸發函數的關鍵點外,還應針對性檢測異常的內存布局和窗口數據讀寫操作。