一、產(chǎn)生原因

1.1 Callback機制

Win32k組件最初的設計和編寫是完全建立的用戶層上的，但是微軟在 Windows NT 4.0 的改變中將 Win32k.sys 作為改變的一部分而引入，用以提升圖形繪制性能并減少 Windows 應用程序的內(nèi)存需求。窗口管理器（User）和圖形設備接口（GDI）在極大程度上被移出客戶端/服務端運行時子系統(tǒng)（CSRSS）并被落實在它自身的一個內(nèi)核模塊中。

wKg0C2Q1UZKAI9jFAAA8HhChBCU732.png

這樣的設計無疑是為內(nèi)核增添了一部分壓力，win32k.sys需要處理大量的用戶層回調(diào)，在這之后國外安全研究人員Tarjei Mandt公開了他對Win32k User-Mode Callback機制的研究成果，從此User-Mode Callback的攻擊面得到廣泛關注，UAF的漏洞也不斷的涌現(xiàn)。

下圖代碼為一個經(jīng)典UAF漏洞，用戶層執(zhí)行的某個函數(shù)通過syscall傳入到內(nèi)核層，當內(nèi)核代碼執(zhí)行到xxxSomeCallback這一句時，用戶層可以在用戶定義的callback函數(shù)中獲得代碼執(zhí)行的機會，如果用戶在callback函數(shù)調(diào)用了DestroyWindow函數(shù)銷毀窗口p，內(nèi)核層的相應銷毀代碼將會被執(zhí)行，p的相應內(nèi)存被釋放，回調(diào)執(zhí)行完畢，NtUserSysCall函數(shù)繼續(xù)執(zhí)行，當執(zhí)行到xxxSetWindowStyle(p)一句時，由于p的內(nèi)存已經(jīng)被釋放從而導致UAF漏洞的產(chǎn)生。

wKg0C2Q1UdGAG1l0AAB8AXXrrIM630.png

1.2 GDI對象

在TypeIsolation機制的引入之前，windows內(nèi)核中以bitmap為代表的GDI對象成為內(nèi)核漏洞利用時的首選，對于WWW漏洞來說，GDI對象就是它的“左膀右臂”，借助GDI對象可以很容易構造出穩(wěn)定內(nèi)核內(nèi)存的任意地址讀寫原語，以此來繞過Windows的安全機制（KALSR、SMEP等）。

二、利用框架

漏洞成功利用漏洞觸發(fā)、漏洞利用這兩大環(huán)節(jié)，而漏洞利用又有以下三個階段，分別是堆噴射階段、信息泄露階段、代碼執(zhí)行階段。下面將結合CVE-2019-0808、CVE-2021-1732進行詳細闡述。

2.1 漏洞觸發(fā)

漏洞的類型雖然五花八門，但基于win32k的內(nèi)核漏洞是存在者一些共性的，也就是它的用戶層回調(diào)，近年來所爆出的win32k的漏洞，其觸發(fā)點大多都在用戶層回調(diào)被hook。下面將通過兩個案例來進行介紹。

案例1：

在CVE-2021-1732中，攻擊者正是hook xxxClientAllocWindowClassExtraBytes的用戶層回調(diào)函數(shù)，強行改變窗口對象tagWND的擴展數(shù)據(jù)的保存位置以及尋址方式，從而觸發(fā)一個任意地址覆蓋寫漏洞。

wKg0C2Q1UrqAce6UAACLexflaGQ178.png

針對這種觸發(fā)方式，我們可以直接對用戶層的usertable進行檢測，usertable存在于PEB+0x58偏移處:

案例2：

CVE-2021-40449 是Win32k 的 NtGdiResetDC 函數(shù)中的一個釋放后使用漏洞，在執(zhí)行其自己的回調(diào)期間針對同一句柄第二次執(zhí)行函數(shù) ResetDC 時觸發(fā)UAF漏洞。

wKg0C2Q1UuOAZdTrAACPaTgCZog116.png

針對這種觸發(fā)方式，可以通過開啟Driver Virifier進行檢測，UAF的漏洞再此環(huán)境下會觸發(fā)藍屏。

2.2 漏洞利用

漏洞成功被觸發(fā)僅僅是一個好的開端，更重要的是漏洞利用點的尋找過程。筆者將此過程大致劃分為信息泄露、堆噴射、原語構造、代碼執(zhí)行這四個階段。

1.信息泄露階段

在win32k漏洞利用過程中，內(nèi)核對象的泄漏是至關重要的?？梢哉f成功利用一個漏洞的大前提就是獲取win32k內(nèi)核對象的地址。

wKg0C2Q1U3aAYy0iAAEH1E9EANQ917.png

上圖是對Windows內(nèi)核地址泄漏的總結（來自GitHub），表格中包含截止目前泄漏內(nèi)核對象的各種技巧。下面也是拿兩個demo來闡述內(nèi)核對象泄露的細節(jié)：

• Demo1，通過GdiSharedHandleTable去泄露bitmap對象：

在R3通過CreateBitmap創(chuàng)建位圖成功后會得到一個hBitmap,如果要在R3去泄露該對象在內(nèi)核中的地址可以通過GdiSharedHandleTable獲取。GdiSharedHandleTable位于PEB+0x94的位置。

wKg0C2Q1U5CAaWhkAAAepg2jbsk966.png

GdiSharedHandleTable的本質(zhì)是一個指向GDICELL結構體數(shù)組的指針。

wKg0C2Q1U6KAT7J1AAA0SxX9GE617.png

同 CreateFile 類似，其實Windows 都用句柄（Handle）來標識用戶態(tài)對內(nèi)核對象的引用。這個句柄低 16 位其實是數(shù)組索引。

wKg0C2Q1VAWAfZUXAAANNlwfltw725.png

通過上文，就可以計算出bitmap在內(nèi)核中的地址。

wKg0C2Q1VBGAQck3AAAUsLBZxA641.png

• Demo2，通過HMValidateHandle函數(shù)泄漏內(nèi)核對象：

HMValidateHandle是微軟未公開的一個函數(shù)，憑借此函數(shù)可以通過傳入句柄獲取對于內(nèi)核對象的地址（win32k對象）。HMAllocObject創(chuàng)建了桌面堆類型句柄后，會把tagWND對象放入到內(nèi)核模式到用戶模式內(nèi)存映射地址里。 為了驗證句柄的有效性，窗口管理器會調(diào)用User32!HMValidateHandle函數(shù)讀取這個表。函數(shù)將句柄和句柄類型作為參數(shù)，并在句柄表中查找對應的項。如果查找到對象, 會返回tagWND只讀映射的對象指針，通過tagWND這個對象我們可以獲取到句柄等一系列窗口信息。

該函數(shù)地址是通過R3的user32.dll!IsMenu函數(shù)獲取到的。

wKg0C2Q1VDaAOEifAABK7i13EFg646.png

具體獲取方式如下：

wKg0C2Q1VEOAQ8crAADZGjJrmGw662.png

2.堆(池)噴射階段

堆（池）噴射是進行內(nèi)存布局的常用手段, 通過在分配關鍵的內(nèi)核對象之前，首先分配和釋放特定長度和數(shù)量的其他對象，使內(nèi)核內(nèi)存首先處于一個確定的狀態(tài)，來確保在分配關鍵的內(nèi)核對象時，能夠被系統(tǒng)內(nèi)存管模塊分配到我們所希望其分配到的某些位置，例如接近某些可控對象的位置。攻擊者可利用此種方法構造完美的內(nèi)存布局從而達到自己的目的。此技術沒有固定的方法（“因地制宜”），但是所要達成的目的比較一致--執(zhí)行shellcode以及信息泄露。

案例1：

Bitmap對象的地址在RS1中是通過AcceleratorTable獲取到的。先申請大量的AcceleratorTable對象然后釋放其中一個，接著申請大小相等的bitmap對象。通過泄漏AcceleratorTable對象的地址，即可等到bitmap的內(nèi)核地址。（內(nèi)存大小計算方式將在下一章節(jié)進行詳細闡述）

wKg0C2Q1VFiAatRuAABZb8ZW9wQ135.png

代碼框架如下

wKg0C2Q1VGGAC6cqAACw29G8S0A729.png

3.RW原語構造階段

在win32k內(nèi)核漏洞利用中，RW原語同樣扮演著重要角色。它可以對所分配的關鍵內(nèi)核對象后面的內(nèi)存區(qū)域進行操作，以控制原本不能控制的相鄰對象的成員數(shù)據(jù)，這些數(shù)據(jù)將作為后續(xù)利用操作的重要節(jié)點。

下面將對win32k漏洞常用到的讀寫原語進行介紹：

• Bitmap系列：SetBitmapBits/GetBitmapBits可對內(nèi)核對象bitmap的pvScan0指向的像素數(shù)據(jù)內(nèi)存進行修改。

wKg0C2Q1VJ2AUPU9AAE36tbfPzk258.png

此系列一直到RS3微軟把Bitmap header與Bitmap data分離后，徹底失效。

• Palette系列：GetPaletteEntries/SetPaletteEntries可對內(nèi)核對象Palette的成員pFirstColor（指向4個bytes的數(shù)組PALETTENTRY）修改構造RW原語。

wKg0C2Q1VNWAAeetAAB4GMR5X8A958.png

wKg0C2Q1VNqAACqeAACfThupnU170.png

• Wnd系列：SetWindowLog/SetWindowLogPtr對wnd(tagWnd)內(nèi)核對象的修改能力。

應用場景1：

Wnd->StrName 字段是指向窗?標題名的指針，通過修改此變量，再借助?戶態(tài)下 的 InternalGetWindowText 和 NtUserDefSetText 函數(shù)則可實現(xiàn)任意內(nèi)核地址讀寫

wKg0C2Q1VPWAP7o8AABRuCzwQr0810.png

應用場景2：

a)申請兩個連續(xù)的Wnd對象（Spray），Wnd0與Wnd1

b)通過漏洞能力將Wnd0的pExtraBytes字段變?yōu)榭稍浇缱x寫的。

c)通過Wnd0.的越界寫入能力，修改tagWND1.pExtraBytes到指定地址

d)借助SetWindowLongPtr的修改能力，最后使Wnd1獲得任意地址寫入能力。

wKg0C2Q1VSeAbZPuAAAwYN3HNgQ077.png

• Menu系列（最新）：GetMenuBarInfo，當其第二參數(shù)、第三參數(shù)分別設置成-3,1的時候，可以借助menu bar info獲取16字節(jié)的讀取能力。

wKg0C2Q1VTWATycRAACFCy5ktlM232.png

一般僅需tagMenuBarInfo.rcBar.left 和 tagMenuBarInfo.rcBar.top讀取指定地址的8個字節(jié)的數(shù)據(jù)。

wKg0C2Q1VUCAPhNuAACdn1vLEPQ467.png

另外，通過GetMenuBarInfo構造Read Primitive時，需要提前構造Fake Menu（用戶層），再通過SetWindowLongPtr對Target Wnd的Menu（內(nèi)核層）進行替換，以達到讀取地址可控的目的。

wKg0C2Q1VUuAd8KAACqSW0mBns734.png

4.代碼執(zhí)行階段

對于win32k內(nèi)核漏洞，其最終利用方式就是本地提權，而提升權限的主要手法就是進行Token替換，共以下兩種方式：

• Token指針替換（_EX_FAST_REF替換）

wKg0C2Q1VWKASYr9AAA52Kc5NjM556.png

將當前進程 EPROCESS 中存儲的 Token 指針替換為 System 進程的 Token 指針。

wKg0C2Q1VW2AA6MzAACv5Wa8u5Q094.png

wKg0C2Q1VXKALdlUAAEJvY13O8519.png

• Token中的成員替換

將當前進程 EPROCESS 的成員 Token 指針指向的 Token 塊中的數(shù)據(jù)替換成 System 進程擁有的 Token 塊的數(shù)據(jù)

wKg0C2Q1VYSAWQaSAABAUD69sOQ973.png

將Present和Enabled的值更改為SYSTEM進程令牌的所有權限。

wKg0C2Q1VY2AK7OpAAA1U2FkTU378.png

三、內(nèi)核對象

3.1 Bitmap

簡介

GDI（Windows Graphics Device Interface），是windows為應用程序提供圖形、文字顯示的 API 接口。

Bitmap是GDI中的圖形對象，用于創(chuàng)建、操作（縮放、滾動、旋轉和繪制）并將圖像作為文件存儲在磁盤上，其實際上為一個二元數(shù)組，去存儲像素、顏色、大小等信息。

• Bitmap關鍵結構體及對象

SURFACE對象（Bitmap在內(nèi)核中的結構）

wKg0C2Q1VcKAYJpSAAAsz7rKY4c312.png

BaseObject，內(nèi)核 GDI 對象類的基類都是一個稱作 _BASEOBJECT 的結構。對內(nèi)核對象進行標記，用于描述最基礎的對象信息

wKg0C2Q1VdCASXVAAAlRzvaNM671.png

SURFOBJ（Bitmap核心結構），用于控制位圖的大小，像素等信息。

wKg0C2Q1VdABlnSAABTSUqvvrg712.png

• CreateBitmap相關

wKg0C2Q1VgCAbkXoAAApoINYtcc373.png

創(chuàng)建具有指定寬度，高度和顏色格式（顏色平面和位每像素）的位圖，而前文中也提過bitmap在內(nèi)核中關聯(lián)的對象SURACE,由SURACE通過CreateBitamp的前4個參數(shù)去精確控制分配的內(nèi)核內(nèi)存塊的大小。其調(diào)用鏈如下：

wKg0C2Q1VhSAUxAQAAB75owvyTw709.png

在GreCreateBitmap函數(shù)中，首先根據(jù)傳入的 cPlanes 和 cBitsPerPel參數(shù)確定位圖的像素位類型，然后創(chuàng)建一個DEVBITMAPINFO對象，通過CreateBitmap前四個參數(shù)去內(nèi)存塊中申請一片內(nèi)存并且設置位圖數(shù)據(jù)掃描線的長度。接著lpBits如果不為0，則通過GreSetBitmapBits去設置像素數(shù)據(jù)。

wKg0C2Q1Vh6AEDA3AABVoGSJSBo274.png

DEVBITMAPINFO的結構：

wKg0C2Q1VieADLBBAABGYsmlzbI562.png

• 掃描線

在 Windows 內(nèi)核中處理位圖像素數(shù)據(jù)時，通常是以一行作為單位進行的，像素的一行被稱為掃描線，而掃描線的長度就表示的是在位圖數(shù)據(jù)中向下移動一行所需的字節(jié)數(shù)。

位圖數(shù)據(jù)掃描線的長度被存儲在SURFACE+0x34 字節(jié)偏移的成員（即 SURFACE->so.lDelta 成員）中。這樣一來，成員 pvScan0 將指向當前位圖 SURFACE 對象的像素點數(shù)據(jù)緩沖區(qū)的起始位置。在后續(xù)對位圖像素點進行讀寫訪問時，系統(tǒng)位圖解析模塊將以該對象的 pvScan0 成員存儲的地址作為像素點數(shù)據(jù)區(qū)域起始地址。

wKg0C2Q1VkiADXVeAABsg3IFe0151.png

3.2 Palette

簡介

調(diào)色板是一個數(shù)組，其中包含標識當前可以在輸出設備上顯示或繪制的顏色的顏色值。調(diào)色板由能夠生成多種顏色但在任何給定時間只能顯示或繪制這些顏色的子集的設備使用。

Palette關鍵結構體及對象

PALETTE對象

wKg0C2Q1VuCAO8nAAE5zXPcDuQ249.png

PALETTE結構中，有三個成員是值得我們關注的分別是cEntries、pFirstColor、apalColors。cEntries指定當前調(diào)色板的項數(shù)，pFirstColor指向調(diào)色板列表起始表項（apalColors）的地址，apalColors是一個結構體數(shù)組存儲調(diào)色板列表數(shù)據(jù)。

PALETTEENTRY （調(diào)色板列表）

結構體 PALETTEENTRY 大小為 4 字節(jié)，其各個成員用于定義調(diào)色板表項對應的 24 位 RGB 顏色值等信息

wKg0C2Q1Vu6AZ8bAAApmXRjvG0967.png

Createpalette相關

wKg0C2Q1Vx2AOGL7AAAZ8CsH2YM553.png

Createpalette函數(shù)用來創(chuàng)建調(diào)色板對象，其只有一個參數(shù)lplgpl是指向LOFGPALETTE類型結構體對象的指針。定義如下：

wKg0C2Q1V4SACU02AABEui0D474872.png

這里我們僅需要關注第二個和第三個參數(shù)，palPalEntry是可變長度的 PALETTEENTRY 結構體類型數(shù)組，而palNumEntries來決定PALETTEENTRY 的個數(shù)。也就是說palette對象的大小是由palNumEntries控制的。

wKg0C2Q1V4ABNCAAAD39Rl4gy4172.png

顯然，我們可以得出palette對象大小的計算方式：4 * cEntries + 0x90/PALETTE/

3.3Wnd

簡介

Windows是對象，它們同時具有代碼和數(shù)據(jù)，但它們不是C++ 類。 相反，程序通過使用名為句柄 的值來引用窗口。句柄是不透明類型。實質(zhì)上它只是操作系統(tǒng)用來標識對象的數(shù)字?？梢韵胂骔indows創(chuàng)建的所有窗口都有一個大表。它使用此表按其句柄查找窗口。 (它內(nèi)部的工作方式是否完全相同都很重要。) 窗口句柄的數(shù)據(jù)類型是 HWND， 這通常發(fā)音為"aitch-wind"。 窗口句柄由創(chuàng)建窗口的函數(shù)返回 ：CreateWindow 和CreateWindowEx。

關鍵結構體及對象

這里只介紹tagWnd常用的字段,分別是tagwnd.cbwndextra和tagWND.ExtraBytes。當使用CreateWindowEx創(chuàng)建窗口時，可以在注冊窗口類時通過WNDCLASSEXA結構體中的cbWndExtra字段直接在內(nèi)存中的tagWND對象之后請求額外的內(nèi)存字節(jié)。

wKg0C2Q1ViAJvcjAAC9fUTdNWI133.png

關鍵函數(shù)分析

• CreateWindowEx

CreateWindowEx是用來創(chuàng)建窗口，在漏洞利用的世界中，Wnd地位是非常高的，可被用來進行堆spray，越界寫的容器等等。此次我們僅介紹Wnd的pExtraByte字段，分析它在內(nèi)核中生成的過程。

wKg0C2Q1WEKAMR2AACNvR70g8412.png

上圖時CreateWindowEx到內(nèi)核真正調(diào)用xxxCreateWindowEx函數(shù)的過程，xxxCreateWindowEx中回到tagWND的cbWndExtra字段進行判斷。

wKg0C2Q1WEyAUfiMAABVSsYn8w305.png

如果cbWndExtra不為0，則將其作為參數(shù)傳入xxxClientAllocWindowClassExtraBytes，在xxxClientAllocWindowClassExtraBytes中通過KeUserModeCallback進入到R3，最后調(diào)用RtlAllocateHeap為其在用戶層的桌面堆上申請一塊內(nèi)存。

wKg0C2Q1WF6AaVL0AABDDmtkyk581.png

SetWindowLongPtr

對于SetWindowLongPtr函數(shù)，最重要的就是其對Wnd的修改能力，下圖xxxSetWindowLongPtr函數(shù)的部分反匯編代碼，可以看到當dwExtraFlag被設置為800后，可以直接對位于內(nèi)核桌面堆的pExtraBytes+Index處的數(shù)據(jù)進行修改。

wKg0C2Q1WHCALoOMAABs2i1UgSE515.png

xxxSetWindowData

xxxSetWindowData函數(shù)可以對Wnd的spMenu進行替換，這是我們能夠利用Menu構造Read Primitive的先決條件。

wKg0C2Q1WIaAJ1E1AABtmMOgRZA040.png

獲取相鄰Wnd

相鄰的窗口中相差的只是一個tagWNDk結構體的大小

3.4Menu

簡介

菜單是為應用程序指定選項或選項組（子菜單）的項目列表。單擊菜單項打開子菜單或使應用程序執(zhí)行命令。菜單管理也是win32k中最復雜得組件之一，其整體依賴多種十分復雜的函數(shù)和結構體。

Menu關鍵結構體及對象

tagMENU，

wKg0C2Q1WTOABfwBAADqVmnN14o150.png

tagPOPUPMENU，

wKg0C2Q1WTyAWWZAADxjkmL5X8350.png

信息泄露能力

通過spMenu泄漏EPROCESS內(nèi)核地址，用于尋找SYSTEM進程以及Token替換。

wKg0C2Q1WVeAdGtAABRE7Pewxc086.png

四、攻防進化史

漏洞只有能夠被成功利用，才可以體現(xiàn)出它的價值。而對于win32k內(nèi)核漏洞，最經(jīng)典也是利用率最高的類型就是“任意地址任意寫(WWW)”漏洞。本章節(jié)將圍繞“ArbitraryOverwrite”，對win32k提權利用方式的進化史以及微軟相應的緩解措施進行詳細闡述。

4.1 Win7下的利用模式

緩解措施

個人認為Win7是Win32k內(nèi)核漏洞利用最理想的環(huán)境，因其具有以下幾點特征：

• Win32k.sys未分離
• 信息泄露的方式最多（目前已知技術均兼容win7）
• 0頁內(nèi)存機制未被緩解
• Win32k 內(nèi)核對象公開（成員偏移清晰）

綜上，可以更加確認一個win32k內(nèi)核漏洞在win7的利用率是極高的。

利用思路

我們以“Bitmap”為例，介紹內(nèi)核提權漏洞在win7上的利用方式：

前提：Arbitrary Memory Write漏洞

• 創(chuàng)建兩個bitmap對象分別為hManager、hWorker,通過GdiSharedHandleTable泄露內(nèi)核地址。
• 利用任意地址覆蓋寫漏洞，將hManager的pvScan0修改為指向hWorker成員pvScan0的地址。

wKg0C2Q1Wa6AOjwRAAAOHNIDfM234.png

• 構造對內(nèi)核任意地址的RW原語（GetBitmapBits/SetBitmapBits）

wKg0C2Q1WbyAfWQ0AABWPadb8I609.png

• 本地提權—令牌替換

操作第一個 hManager，可以替換第二個 hWorker->pvScan0地址，再通過第二個 hWorker來將system進程的token寫入當前進程。

wKg0C2Q1WdWAP4PiAAEcglZL8Y656.png

4.2 RS1下的利用模式

緩解措施

GdiSharedHandleTable泄露bitmap的方式被緩解，GdiSharedHandleTable的pKernelAddress 指向一塊無意義的地址。

wKg0C2Q1WkSAW8wyAAGbgyaOwdY153.png

利用思路

結合網(wǎng)上資料，Windows 中存在著 3 種類型的對象，分別為 User object、GDI object、Kernel object，一共有 40 多種對象。

wKg0C2Q1WmaAJkNLAACzMzaa3VU995.png

而bitmap屬于GDI object其存在于換頁會話池中，由于GDI object泄露地址方式在RS1版本中被緩解，因此我們需要從另外兩種類型對象中去尋找替代方案。此次我們使用的是Accelerator table其屬于User object并且也存在于分頁會話池中。

wKg0C2Q1WnKAdfZAAAidc8gxcU837.png

Tips:非分頁池的虛擬地址被物理地址分配,而分頁池對應的虛擬地址和物理地址不存在一一映射，只保證在當前執(zhí)行會話有效，其余內(nèi)核操作時，并不要求這些對象必須在內(nèi)存中。

• User Object地址獲取

在user32.dll中有一個全局變量gSharedInfo，其成員aheList為一個USER_HANDLE_ENTRY的句柄表。

wKg0C2Q1WoOACfYZAABH840fs30887.png

該句柄表的具體結構如下所示，其第一個成員為pKernel作用GdiSharedHandleTable 中的 pKernel 一致，均指向object在內(nèi)核中的位置（KernelAddress）。

wKg0C2Q1WoyAb2hWAAAOnVvZ8c916.png

因此可通過USER_HANDLE_ENTRY去泄露Accelerator table的內(nèi)核對象地址。

KernelAddress= SHAREDINFO->USER_HANDLE_ENTRY->pKernel + handle&0xffff

• Accelerator table 對象創(chuàng)建

函數(shù) CreateAcceleratorTable 用來在內(nèi)核中創(chuàng)建快捷鍵對應表。

wKg0C2Q1Wp2ATnvAAAXHn4ybg394.png

該函數(shù)存在 LPACCEL lpaccl 和 int cAccel 兩個參數(shù)。參數(shù) lpaccl 作為指向 ACCEL 結構體類型數(shù)組的指針，cAccel 表示數(shù)組的元素個數(shù)。結構體 ACCEL (szie=6)的定義如下:

wKg0C2Q1WqeARsSAAAA5BM3aN0c314.png

• 堆分水

通過1)、2)我們肯定可以想到通過內(nèi)存分水技術去泄露bitmap內(nèi)核對象的地址，經(jīng)筆者分析得出可以控制CreateAcceleratorTable 的參數(shù)，來控制其到內(nèi)核所申請內(nèi)存的大小。

wKg0C2Q1WxKAGITMAABN5EuR2U269.png

現(xiàn)在，bitmap和AcceleratorTable內(nèi)核對象的大小均可控，可以進行內(nèi)存布局。過程如下：

wKg0C2Q1Wx2AOixGAACSUNu5bg788.png

至此，我們就可以成功泄露bitmap內(nèi)核對象的地址啦！

wKg0C2Q1W0iAdWGnAACTFPUjts242.png

后續(xù)提權過程與win7一致。

4.3 RS2 下的利用模式

緩解措施

在RS2中pKernel指向異常地址， AcceleratorTable + 池風水泄露pvScan0的方式失效

利用思路

新的替代方案—桌面堆，更準確一點就在桌面堆上的lpszMenuName。lpszMenuName就是我們創(chuàng)建窗口時wndclass的成員，同bitmap一樣它也存于換頁內(nèi)存池。

另外，我們還需知道桌面堆是有兩份分別存于用戶態(tài)和內(nèi)核態(tài)。

wKg0C2Q1W4SAfnL5AABHHHDvfzk145.png

上圖，在網(wǎng)上流傳的比較火，應該是國外某位大神逆出來，再此稍稍瞻仰一下。有了這個我們就可以通過桌面堆來泄露bitmap的內(nèi)核地址啦。

• 獲取lpszMenuName的地址.

首先，我們要得到內(nèi)核態(tài)桌面堆到用戶態(tài)桌面堆的偏移值ulClientDelta。

wKg0C2Q1W52ATszxAAB0SOVOLXg150.png

通過HMValidateHandle泄露Wnd的內(nèi)核地址，然后通過用戶態(tài)的tagCLS獲取lpszMenuName（0x98）的地址。

wKg0C2Q1W8OAL3mkAACdFHYmuE332.png

泄露結果如下所示：

wKg0C2Q1W86AKpsnAABZVdDesEE087.png

• 堆風水

到這，相信大家都知道可以通過桌面堆對象進行占坑，并控制lpszMenuName的大小與bitmap大小一致。即可成功泄露bitmap的內(nèi)核地址。lpszMenuName申請內(nèi)存過程堆棧如下，其大小為實際申請大小。

wKg0C2Q1WCAI0bvAAB69JVUyuc773.png

另外，BitMap的SurFace結構 在RS2上比RS1增大了10。

內(nèi)存布局如下，申請等大小的lpszMenuName和bitmap。利用UAF技術確保泄露lpszMenuName的地址穩(wěn)定之后使用bitmap占坑。

wKg0C2Q1WCALEPyAACLaCzLK00651.png

下圖來自fuzzySecurity的blog,精確的展現(xiàn)出通過lpszMenuName進行UAF后泄露bitmap的過程。

wKg0C2Q1WAWHyrAADIeqoA8bM878.png

4.4 RS3 下的利用模式

緩解措施

微軟引入了 TypeIsolation 功能將Bitmap header與Bitmap data分離，無法通過Bitmap header取得pvscan0指針的內(nèi)核地址。

利用思路

在第三章節(jié)介紹過另一個用于WWW漏洞利用的內(nèi)核對象—Palette，它和bitmap有著異曲同工之妙，palette對象的0x90處是一個4字節(jié)的數(shù)組apalColors，相當于BitMap里的pixel data，pFirstColor是一個指針，指向apalColors，相當于BitMap里的pvScan0。

wKg0C2Q1XCaAB5nYAAATtJzGCek419.png

因此，我們完全可以按照在RS2中的利用思路，完成在RS3中的提權。

• 創(chuàng)建兩個palette對象分別為hManager、hWorker,并通過桌面堆泄露內(nèi)核地址。

wKg0C2Q1XLaAOI9AAAx7y9av8004.png

泄露的方法還是采用池分水技術，利用lpszMenuName為palette占坑。

Palette大小的計算方式：LOGPALETTE->palNumEntries進行控制的，具體如下：

• 利用任意地址覆蓋寫漏洞，將hManager的pFirstColor修改為指向hWorker成員pFirstColor的地址。

wKg0C2Q1XO6AR2yHAACUl66GW9A717.png

• 構造對內(nèi)核任意地址的RW原語（GetPaletteEntries/ SetPaletteEntries）

wKg0C2Q1XPyAWPaJAACkIwPXv2o616.png

• 提權-令牌替換（與bitmap方式一致）

wKg0C2Q1XReAP7maAADQpi2kHrQ470.png

4.5 攻防現(xiàn)狀

緩解措施

RS4:

HMValidateHandle泄露內(nèi)核方法失效

Palette同樣被TypeIsolation進行header和body分離

RS5:

微軟修改大量API，桌面堆泄露的方法被緩解 。

2.新的思路

到這，已有的所有泄露GDI對象的方法均以被緩解。但車到山前必有路，這也正體現(xiàn)了攻防對抗的魅力，直到2021年CVE-2021-1732的漏洞被爆出，不同于傳統(tǒng)的內(nèi)核漏洞，需借助“溢出”來完成漏洞利用，該漏洞是由于窗口類型混淆而導致的，通過spMenu的信息泄漏能力和借助GetMenuBarInfo/SetWindowLong函數(shù)構造讀寫原語（RW Primitive），最后通過純數(shù)據(jù)攻擊（DataOnlyAttack，特點不需要執(zhí)行原語，只操縱操作系統(tǒng)使用的數(shù)據(jù)結構以實現(xiàn)提權）實現(xiàn)內(nèi)核提權。

wKg0C2Q1XTAMRovAABXU0wGazI800.png

五、附錄

5.1參考鏈接

https://www.anquanke.com/post/id/235716#h3-4

https://mp.weixi2n.qq.com/s/6mT0O9eur5-VEs0rbV0-mg

https://github.com/gdabah/win32k-bugs/

http://fuzzysecurity.com/tutorials/expDev/21.html

https://www.wangan.com/p/7fygf309c52e2678

5.2環(huán)境介紹

靶場

HEVD的一個Windows Kernel Exploition訓練項目--HackSysExtremeVulnerableDriver

https://github.com/hacksysteam/HackSysExtremeVulnerableDriver

wKg0C2Q1XXiAPjCQAACoYoHRIJY361.png