# 微軟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重構相關內核代碼,未來新系統中此類漏洞可能被杜絕。本次漏洞利用過程相對簡單,主要難點在於如何控制第一次寫入。該漏洞嚴重依賴桌面堆句柄地址泄露,這仍是老舊系統的安全隱患。我們推測該漏洞的發現可能得益於更完善的代碼覆蓋率檢測。對於漏洞利用檢測而言,除了監控關鍵點,對異常內存布局和窗口數據讀寫的針對性檢測也可能有助於發現此類漏洞。
Windows系統漏洞威脅Web3資產安全 私鑰恐遭竊取
微軟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重構相關內核代碼,未來新系統中此類漏洞可能被杜絕。本次漏洞利用過程相對簡單,主要難點在於如何控制第一次寫入。該漏洞嚴重依賴桌面堆句柄地址泄露,這仍是老舊系統的安全隱患。
我們推測該漏洞的發現可能得益於更完善的代碼覆蓋率檢測。對於漏洞利用檢測而言,除了監控關鍵點,對異常內存布局和窗口數據讀寫的針對性檢測也可能有助於發現此類漏洞。