一、產(chǎn)生原因

1.1 Callback機(jī)制

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

wKg0C2Q1UZKAI9jFAAA8HhChBCU732.png

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

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

wKg0C2Q1UdGAG1l0AAB8AXXrrIM630.png

1.2 GDI對(duì)象

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

二、利用框架

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

2.1 漏洞觸發(fā)

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

案例1：

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

wKg0C2Q1UrqAce6UAACLexflaGQ178.png

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

案例2：

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

wKg0C2Q1UuOAZdTrAACPaTgCZog116.png

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

2.2 漏洞利用

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

1.信息泄露階段

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

wKg0C2Q1U3aAYy0iAAEH1E9EANQ917.png

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

• Demo1，通過(guò)GdiSharedHandleTable去泄露bitmap對(duì)象：

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

wKg0C2Q1U5CAaWhkAAAepg2jbsk966.png

GdiSharedHandleTable的本質(zhì)是一個(gè)指向GDICELL結(jié)構(gòu)體數(shù)組的指針。

wKg0C2Q1U6KAT7J1AAA0SxX9GE617.png

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

wKg0C2Q1VAWAfZUXAAANNlwfltw725.png

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

wKg0C2Q1VBGAQck3AAAUsLBZxA641.png

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

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

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

wKg0C2Q1VDaAOEifAABK7i13EFg646.png

具體獲取方式如下：

wKg0C2Q1VEOAQ8crAADZGjJrmGw662.png

2.堆(池)噴射階段

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

案例1：

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

wKg0C2Q1VFiAatRuAABZb8ZW9wQ135.png

代碼框架如下

wKg0C2Q1VGGAC6cqAACw29G8S0A729.png

3.RW原語(yǔ)構(gòu)造階段

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

下面將對(duì)win32k漏洞常用到的讀寫原語(yǔ)進(jìn)行介紹：

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

wKg0C2Q1VJ2AUPU9AAE36tbfPzk258.png

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

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

wKg0C2Q1VNWAAeetAAB4GMR5X8A958.png

wKg0C2Q1VNqAACqeAACfThupnU170.png

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

應(yīng)用場(chǎng)景1：

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

wKg0C2Q1VPWAP7o8AABRuCzwQr0810.png

應(yīng)用場(chǎng)景2：

a)申請(qǐng)兩個(gè)連續(xù)的Wnd對(duì)象（Spray），Wnd0與Wnd1

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

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

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

wKg0C2Q1VSeAbZPuAAAwYN3HNgQ077.png

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

wKg0C2Q1VTWATycRAACFCy5ktlM232.png

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

wKg0C2Q1VUCAPhNuAACdn1vLEPQ467.png

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

wKg0C2Q1VUuAd8KAACqSW0mBns734.png

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

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

• Token指針替換（_EX_FAST_REF替換）

wKg0C2Q1VWKASYr9AAA52Kc5NjM556.png

將當(dāng)前進(jìn)程 EPROCESS 中存儲(chǔ)的 Token 指針替換為 System 進(jìn)程的 Token 指針。

wKg0C2Q1VW2AA6MzAACv5Wa8u5Q094.png

wKg0C2Q1VXKALdlUAAEJvY13O8519.png

• Token中的成員替換

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

wKg0C2Q1VYSAWQaSAABAUD69sOQ973.png

將Present和Enabled的值更改為SYSTEM進(jìn)程令牌的所有權(quán)限。

wKg0C2Q1VY2AK7OpAAA1U2FkTU378.png

三、內(nèi)核對(duì)象

3.1 Bitmap

簡(jiǎn)介

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

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

• Bitmap關(guān)鍵結(jié)構(gòu)體及對(duì)象

SURFACE對(duì)象（Bitmap在內(nèi)核中的結(jié)構(gòu)）

wKg0C2Q1VcKAYJpSAAAsz7rKY4c312.png

BaseObject，內(nèi)核 GDI 對(duì)象類的基類都是一個(gè)稱作 _BASEOBJECT 的結(jié)構(gòu)。對(duì)內(nèi)核對(duì)象進(jìn)行標(biāo)記，用于描述最基礎(chǔ)的對(duì)象信息

wKg0C2Q1VdCASXVAAAlRzvaNM671.png

SURFOBJ（Bitmap核心結(jié)構(gòu)），用于控制位圖的大小，像素等信息。

wKg0C2Q1VdABlnSAABTSUqvvrg712.png

• CreateBitmap相關(guān)

wKg0C2Q1VgCAbkXoAAApoINYtcc373.png

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

wKg0C2Q1VhSAUxAQAAB75owvyTw709.png

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

wKg0C2Q1Vh6AEDA3AABVoGSJSBo274.png

DEVBITMAPINFO的結(jié)構(gòu)：

wKg0C2Q1VieADLBBAABGYsmlzbI562.png

• 掃描線

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

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

wKg0C2Q1VkiADXVeAABsg3IFe0151.png

3.2 Palette

簡(jiǎn)介

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

Palette關(guān)鍵結(jié)構(gòu)體及對(duì)象

PALETTE對(duì)象

wKg0C2Q1VuCAO8nAAE5zXPcDuQ249.png

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

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

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

wKg0C2Q1Vu6AZ8bAAApmXRjvG0967.png

Createpalette相關(guān)

wKg0C2Q1Vx2AOGL7AAAZ8CsH2YM553.png

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

wKg0C2Q1V4SACU02AABEui0D474872.png

這里我們僅需要關(guān)注第二個(gè)和第三個(gè)參數(shù)，palPalEntry是可變長(zhǎng)度的 PALETTEENTRY 結(jié)構(gòu)體類型數(shù)組，而palNumEntries來(lái)決定PALETTEENTRY 的個(gè)數(shù)。也就是說(shuō)palette對(duì)象的大小是由palNumEntries控制的。

wKg0C2Q1V4ABNCAAAD39Rl4gy4172.png

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

3.3Wnd

簡(jiǎn)介

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

關(guān)鍵結(jié)構(gòu)體及對(duì)象

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

wKg0C2Q1ViAJvcjAAC9fUTdNWI133.png

關(guān)鍵函數(shù)分析

• CreateWindowEx

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

wKg0C2Q1WEKAMR2AACNvR70g8412.png

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

wKg0C2Q1WEyAUfiMAABVSsYn8w305.png

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

wKg0C2Q1WF6AaVL0AABDDmtkyk581.png

SetWindowLongPtr

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

wKg0C2Q1WHCALoOMAABs2i1UgSE515.png

xxxSetWindowData

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

wKg0C2Q1WIaAJ1E1AABtmMOgRZA040.png

獲取相鄰Wnd

相鄰的窗口中相差的只是一個(gè)tagWNDk結(jié)構(gòu)體的大小

3.4Menu

簡(jiǎn)介

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

Menu關(guān)鍵結(jié)構(gòu)體及對(duì)象

tagMENU，

wKg0C2Q1WTOABfwBAADqVmnN14o150.png

tagPOPUPMENU，

wKg0C2Q1WTyAWWZAADxjkmL5X8350.png

信息泄露能力

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

wKg0C2Q1WVeAdGtAABRE7Pewxc086.png

四、攻防進(jìn)化史

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

4.1 Win7下的利用模式

緩解措施

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

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

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

利用思路

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

前提：Arbitrary Memory Write漏洞

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

wKg0C2Q1Wa6AOjwRAAAOHNIDfM234.png

• 構(gòu)造對(duì)內(nèi)核任意地址的RW原語(yǔ)（GetBitmapBits/SetBitmapBits）

wKg0C2Q1WbyAfWQ0AABWPadb8I609.png

• 本地提權(quán)—令牌替換

操作第一個(gè) hManager，可以替換第二個(gè) hWorker->pvScan0地址，再通過(guò)第二個(gè) hWorker來(lái)將system進(jìn)程的token寫入當(dāng)前進(jìn)程。

wKg0C2Q1WdWAP4PiAAEcglZL8Y656.png

4.2 RS1下的利用模式

緩解措施

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

wKg0C2Q1WkSAW8wyAAGbgyaOwdY153.png

利用思路

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

wKg0C2Q1WmaAJkNLAACzMzaa3VU995.png

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

wKg0C2Q1WnKAdfZAAAidc8gxcU837.png

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

• User Object地址獲取

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

wKg0C2Q1WoOACfYZAABH840fs30887.png

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

wKg0C2Q1WoyAb2hWAAAOnVvZ8c916.png

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

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

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

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

wKg0C2Q1Wp2ATnvAAAXHn4ybg394.png

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

wKg0C2Q1WqeARsSAAAA5BM3aN0c314.png

• 堆分水

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

wKg0C2Q1WxKAGITMAABN5EuR2U269.png

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

wKg0C2Q1Wx2AOixGAACSUNu5bg788.png

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

wKg0C2Q1W0iAdWGnAACTFPUjts242.png

后續(xù)提權(quán)過(guò)程與win7一致。

4.3 RS2 下的利用模式

緩解措施

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

利用思路

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

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

wKg0C2Q1W4SAfnL5AABHHHDvfzk145.png

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

• 獲取lpszMenuName的地址.

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

wKg0C2Q1W52ATszxAAB0SOVOLXg150.png

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

wKg0C2Q1W8OAL3mkAACdFHYmuE332.png

泄露結(jié)果如下所示：

wKg0C2Q1W86AKpsnAABZVdDesEE087.png

• 堆風(fēng)水

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

wKg0C2Q1WCAI0bvAAB69JVUyuc773.png

另外，BitMap的SurFace結(jié)構(gòu) 在RS2上比RS1增大了10。

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

wKg0C2Q1WCALEPyAACLaCzLK00651.png

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

wKg0C2Q1WAWHyrAADIeqoA8bM878.png

4.4 RS3 下的利用模式

緩解措施

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

利用思路

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

wKg0C2Q1XCaAB5nYAAATtJzGCek419.png

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

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

wKg0C2Q1XLaAOI9AAAx7y9av8004.png

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

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

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

wKg0C2Q1XO6AR2yHAACUl66GW9A717.png

• 構(gòu)造對(duì)內(nèi)核任意地址的RW原語(yǔ)（GetPaletteEntries/ SetPaletteEntries）

wKg0C2Q1XPyAWPaJAACkIwPXv2o616.png

• 提權(quán)-令牌替換（與bitmap方式一致）

wKg0C2Q1XReAP7maAADQpi2kHrQ470.png

4.5 攻防現(xiàn)狀

緩解措施

RS4:

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

Palette同樣被TypeIsolation進(jìn)行header和body分離

RS5:

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

2.新的思路

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

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)境介紹

靶場(chǎng)

HEVD的一個(gè)Windows Kernel Exploition訓(xùn)練項(xiàng)目--HackSysExtremeVulnerableDriver

https://github.com/hacksysteam/HackSysExtremeVulnerableDriver

wKg0C2Q1XXiAPjCQAACoYoHRIJY361.png