基于Windows 32k內(nèi)核提權(quán)漏洞的攻防對(duì)抗

作者：SecIN技術(shù)社區(qū) 2023-09-11 06:59:59

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

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

下圖代碼為一個(gè)經(jīng)典UAF漏洞，用戶層執(zhí)行的某個(gè)函數(shù)通過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漏洞來說，GDI對(duì)象就是它的“左膀右臂”，借助GDI對(duì)象可以很容易構(gòu)造出穩(wěn)定內(nèi)核內(nèi)存的任意地址讀寫原語，以此來繞過Windows的安全機(jī)制（KALSR、SMEP等）。

二、利用框架

2.1 漏洞觸發(fā)

漏洞的類型雖然五花八門，但基于win32k的內(nèi)核漏洞是存在者一些共性的，也就是它的用戶層回調(diào)，近年來所爆出的win32k的漏洞，其觸發(fā)點(diǎn)大多都在用戶層回調(diào)被hook。下面將通過兩個(gè)案例來進(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)行檢測，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ā)方式，可以通過開啟Driver Virifier進(jìn)行檢測，UAF的漏洞再此環(huán)境下會(huì)觸發(fā)藍(lán)屏。

2.2 漏洞利用

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

1.信息泄露階段

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

wKg0C2Q1U3aAYy0iAAEH1E9EANQ917.png

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

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

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

wKg0C2Q1U5CAaWhkAAAepg2jbsk966.png

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

wKg0C2Q1U6KAT7J1AAA0SxX9GE617.png

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

wKg0C2Q1VAWAfZUXAAANNlwfltw725.png

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

wKg0C2Q1VBGAQck3AAAUsLBZxA641.png

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

HMValidateHandle是微軟未公開的一個(gè)函數(shù)，憑借此函數(shù)可以通過傳入句柄獲取對(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ì)象指針，通過tagWND這個(gè)對(duì)象我們可以獲取到句柄等一系列窗口信息。

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

wKg0C2Q1VDaAOEifAABK7i13EFg646.png

具體獲取方式如下：

wKg0C2Q1VEOAQ8crAADZGjJrmGw662.png

2.堆(池)噴射階段

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

案例1：

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

wKg0C2Q1VFiAatRuAABZb8ZW9wQ135.png

代碼框架如下

wKg0C2Q1VGGAC6cqAACw29G8S0A729.png

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

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

下面將對(duì)win32k漏洞常用到的讀寫原語進(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原語。

wKg0C2Q1VNWAAeetAAB4GMR5X8A958.png

wKg0C2Q1VNqAACqeAACfThupnU170.png

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

應(yīng)用場景1：

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

wKg0C2Q1VPWAP7o8AABRuCzwQr0810.png

應(yīng)用場景2：

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

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

c)通過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

另外，通過GetMenuBarInfo構(gòu)造Read Primitive時(shí)，需要提前構(gòu)造Fake Menu（用戶層），再通過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

簡介

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

wKg0C2Q1VhSAUxAQAAB75owvyTw709.png

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

wKg0C2Q1Vh6AEDA3AABVoGSJSBo274.png

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

wKg0C2Q1VieADLBBAABGYsmlzbI562.png

掃描線

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

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

wKg0C2Q1VkiADXVeAABsg3IFe0151.png

3.2 Palette

簡介

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

wKg0C2Q1V4SACU02AABEui0D474872.png

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

wKg0C2Q1V4ABNCAAAD39Rl4gy4172.png

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

3.3Wnd

簡介

Windows是對(duì)象，它們同時(shí)具有代碼和數(shù)據(jù)，但它們不是C++ 類。相反，程序通過使用名為句柄的值來引用窗口。句柄是不透明類型。實(shí)質(zhì)上它只是操作系統(tǒng)用來標(biāo)識(shí)對(duì)象的數(shù)字。可以想象Windows創(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í)，可以在注冊窗口類時(shí)通過WNDCLASSEXA結(jié)構(gòu)體中的cbWndExtra字段直接在內(nèi)存中的tagWND對(duì)象之后請求額外的內(nèi)存字節(jié)。

wKg0C2Q1ViAJvcjAAC9fUTdNWI133.png

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

CreateWindowEx

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

wKg0C2Q1WEKAMR2AACNvR70g8412.png

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

wKg0C2Q1WEyAUfiMAABVSsYn8w305.png

如果cbWndExtra不為0，則將其作為參數(shù)傳入xxxClientAllocWindowClassExtraBytes，在xxxClientAllocWindowClassExtraBytes中通過KeUserModeCallback進(jìn)入到R3，最后調(diào)用RtlAllocateHeap為其在用戶層的桌面堆上申請一塊內(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

簡介

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

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

tagMENU，

wKg0C2Q1WTOABfwBAADqVmnN14o150.png

tagPOPUPMENU，

wKg0C2Q1WTyAWWZAADxjkmL5X8350.png

信息泄露能力

通過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頁內(nèi)存機(jī)制未被緩解
Win32k 內(nèi)核對(duì)象公開（成員偏移清晰）

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

利用思路

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

前提：Arbitrary Memory Write漏洞

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

wKg0C2Q1Wa6AOjwRAAAOHNIDfM234.png

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

wKg0C2Q1WbyAfWQ0AABWPadb8I609.png

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

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

wKg0C2Q1WdWAP4PiAAEcglZL8Y656.png

4.2 RS1下的利用模式

緩解措施

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

wKg0C2Q1WkSAW8wyAAGbgyaOwdY153.png

利用思路

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

wKg0C2Q1WmaAJkNLAACzMzaa3VU995.png

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

wKg0C2Q1WnKAdfZAAAidc8gxcU837.png

Tips:非分頁池的虛擬地址被物理地址分配,而分頁池對(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

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

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

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

函數(shù) CreateAcceleratorTable 用來在內(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

堆分水

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

wKg0C2Q1WxKAGITMAABN5EuR2U269.png

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

wKg0C2Q1Wx2AOixGAACSUNu5bg788.png

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

wKg0C2Q1W0iAdWGnAACTFPUjts242.png

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

4.3 RS2 下的利用模式

緩解措施

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

利用思路

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

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

wKg0C2Q1W4SAfnL5AABHHHDvfzk145.png

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

獲取lpszMenuName的地址.

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

wKg0C2Q1W52ATszxAAB0SOVOLXg150.png

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

wKg0C2Q1W8OAL3mkAACdFHYmuE332.png

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

wKg0C2Q1W86AKpsnAABZVdDesEE087.png

堆風(fēng)水

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

wKg0C2Q1WCAI0bvAAB69JVUyuc773.png

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

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

wKg0C2Q1WCALEPyAACLaCzLK00651.png

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

wKg0C2Q1WAWHyrAADIeqoA8bM878.png

4.4 RS3 下的利用模式

緩解措施

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

利用思路

在第三章節(jié)介紹過另一個(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,并通過桌面堆泄露內(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原語（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)核漏洞，需借助“溢出”來完成漏洞利用，該漏洞是由于窗口類型混淆而導(dǎo)致的，通過spMenu的信息泄漏能力和借助GetMenuBarInfo/SetWindowLong函數(shù)構(gòu)造讀寫原語（RW Primitive），最后通過純數(shù)據(jù)攻擊（DataOnlyAttack，特點(diǎn)不需要執(zhí)行原語，只操縱操作系統(tǒng)使用的數(shù)據(jù)結(jié)構(gòu)以實(shí)現(xiàn)提權(quán)）實(shí)現(xiàn)內(nèi)核提權(quán)。

wKg0C2Q1XTAMRovAABXU0wGazI800.png