🎉 攢成長值,抽華爲Mate三折疊!廣場第 1️⃣ 2️⃣ 期夏季成長值抽獎大狂歡開啓!
總獎池超 $10,000+,華爲Mate三折疊手機、F1紅牛賽車模型、Gate限量週邊、熱門代幣等你來抽!
立即抽獎 👉 https://www.gate.com/activities/pointprize?now_period=12
如何快速賺成長值?
1️⃣ 進入【廣場】,點擊頭像旁標識進入【社區中心】
2️⃣ 完成發帖、評論、點讚、發言等日常任務,成長值拿不停
100%有獎,抽到賺到,大獎等你抱走,趕緊試試手氣!
截止於 8月9日 24:00 (UTC+8)
詳情: https://www.gate.com/announcements/article/46384
#成长值抽奖12期开启#
Windows系統級0day漏洞深度剖析與利用技術
微軟系統級0day漏洞分析及利用
引言
近期微軟安全補丁修復了一個正在被黑客利用的 win32k 提權漏洞。該漏洞主要影響早期 Windows 系統版本,對 Windows 11 似乎無效。本文將深入分析這類漏洞在當前新防護措施不斷改進的背景下,攻擊者可能如何繼續加以利用。我們的分析環境爲 Windows Server 2016。
漏洞背景
0day 漏洞指未公開且未修復的安全漏洞,類似於金融市場中的 T+0 交易概念。這類漏洞一旦被惡意利用,往往會造成巨大危害。此次發現的 Windows 系統級 0day 漏洞可讓攻擊者獲得系統完全控制權。
被攻擊者控制系統後果嚴重,包括個人信息泄露、系統崩潰數據丟失、財產損失、惡意程序植入等。對於加密貨幣用戶來說,私鑰可能被盜取,數字資產被轉移。從更大範圍來看,這個漏洞甚至可能影響到整個基於 Web2 基礎設施的 Web3 生態系統。
補丁分析
分析補丁代碼,問題似乎出在一個對象的引用計數被多次處理。通過查看早期源碼注釋,我們發現以前的代碼只鎖定了窗口對象,沒有鎖定窗口中的菜單對象,這可能導致菜單對象被錯誤引用。
漏洞驗證
分析漏洞函數上下文,我們發現傳入 xxxEnableMenuItem() 的菜單通常已在上層函數被鎖定,那具體要保護哪個菜單對象?進一步分析 xxxEnableMenuItem 中對菜單對象的處理,發現 MenuItemState 函數返回的菜單有兩種可能:窗口主菜單或子菜單(包括子子菜單)。
爲驗證漏洞,我們構造了一個特殊的四層菜單結構,並設置了一些特定條件來繞過 xxxEnableMenuItem 函數中的檢測。在 xxxRedrawTitle 返回用戶層時,我們刪除菜單 C 和 B 的引用關係,成功釋放菜單 C。最後,當內核中 xxxEnableMenuItem 函數返回到 xxxRedrawTitle 函數時,即將引用的菜單 C 對象已失效。
漏洞利用
整體思路
在確定利用方案前,我們通常會進行一些理論分析,以避免在不可行的方案上浪費時間。本次漏洞利用主要考慮了兩個方向:
執行 shellcode:參考早期的類似漏洞,但在高版本 Windows 中可能面臨一些難以解決的問題。
利用讀寫原語修改 token:即使在最近兩年仍有公開的可參考案例。我們需要重點解決如何在 UAF 內存被重用時首次控制 cbwndextra 爲特大值。
因此,我們將整個利用過程分爲兩部分:如何利用 UAF 漏洞控制 cbwndextra 值,以及控制該值後如何實現穩定的讀寫原語。
初次數據寫入
觸發漏洞後,系統不一定會立即崩潰。錯誤使用被控制內存的窗口對象數據主要發生在 xxxEnableMenuItem 函數的 MNGetPopupFromMenu() 和 xxxMNUpdateShownMenu() 中。
我們使用窗口類 WNDClass 中的窗口名稱對象來佔用釋放的菜單對象內存。關鍵是找到一個可由我們構建的地址結構中能任意寫入數據的位置,哪怕只有一個字節。
最終我們在 xxxRedrawWindow 函數中找到了兩個可行方案。考慮到一些限制因素,我們選擇了依靠標志位 AND 2 操作的方案,並決定寫入 HWNDClass 的 cb-extra 而非窗口對象的 cb-extra。
穩定內存布局
我們設計了至少連續三個 0x250 字節 HWND 對象的內存布局。釋放中間對象,用 0x250 字節的 HWNDClass 對象佔用。前一個 HWND 對象尾部數據用於通過 xxxRedrawWindow 標志檢驗,後一個 HWND 對象的菜單對象和 HWNDClass 對象作爲最終讀寫原語媒介。
我們盡量控制窗口對象和 HWNDClass 對象大小一致,並確保窗口對象擴展數據足夠大。通過堆內存中泄露的內核句柄地址,我們可以精確判斷申請的窗口對象是否按預期順序排列。
讀寫原語實現
任意讀原語仍使用 GetMenuBarInfo()。任意寫原語則使用 SetClassLongPtr()。除替換 TOKEN 的寫入操作依賴第二個窗口的 class 對象外,其他寫入都利用第一個窗口對象的 class 對象使用偏移來實現。
總結
win32k 漏洞由來已久,但微軟正在用 Rust 重構相關內核代碼,未來新系統可能杜絕此類漏洞。
本次漏洞利用過程不算困難,主要難點在於如何控制首次寫入。漏洞仍嚴重依賴桌面堆句柄地址泄露,這對老舊系統仍是安全隱患。
該漏洞的發現可能得益於更完善的代碼覆蓋率檢測。一旦系統 API 能在目標函數執行路徑到達最深處漏洞點,且窗口對象處於多重嵌套引用狀態,fuzz 測試就可能發現這個漏洞。
對於漏洞利用檢測,除了關注漏洞觸發函數的關鍵點,還應關注異常的內存布局和對窗口或窗口類額外數據的非常規偏移讀寫,這可能有助於發現同類型漏洞。