📢 Gate廣場 #NERO发帖挑战# 秀觀點贏大獎活動火熱開啓!
Gate NERO生態周來襲!發帖秀出NERO項目洞察和活動實用攻略,瓜分30,000NERO!
💰️ 15位優質發帖用戶 * 2,000枚NERO每人
如何參與:
1️⃣ 調研NERO項目
對NERO的基本面、社區治理、發展目標、代幣經濟模型等方面進行研究,分享你對項目的深度研究。
2️⃣ 參與並分享真實體驗
參與NERO生態周相關活動,並曬出你的參與截圖、收益圖或實用教程。可以是收益展示、簡明易懂的新手攻略、小竅門,也可以是行情點位分析,內容詳實優先。
3️⃣ 鼓勵帶新互動
如果你的帖子吸引到他人參與活動,或者有好友評論“已參與/已交易”,將大幅提升你的獲獎概率!
NERO熱門活動(帖文需附以下活動連結):
NERO Chain (NERO) 生態周:Gate 已上線 NERO 現貨交易,爲回饋平台用戶,HODLer Airdrop、Launchpool、CandyDrop、餘幣寶已上線 NERO,邀您體驗。參與攻略見公告:https://www.gate.com/announcements/article/46284
高質量帖子Tips:
教程越詳細、圖片越直觀、互動量越高,獲獎幾率越大!
市場見解獨到、真實參與經歷、有帶新互動者,評選將優先考慮。
帖子需原創,字數不少於250字,且需獲得至少3條有效互動
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 測試就可能發現這個漏洞。
對於漏洞利用檢測,除了關注漏洞觸發函數的關鍵點,還應關注異常的內存布局和對窗口或窗口類額外數據的非常規偏移讀寫,這可能有助於發現同類型漏洞。