基于Windows 32k內核提權漏洞的攻防對抗
一、產生原因
1.1 Callback機制
Win32k組件最初的設計和編寫是完全建立的用戶層上的，但是微軟在 Windows NT 4.0 的改變中將 Win32k.sys 作為改變的一部分而引入，用以提升圖形繪制性能并減少 Windows 應用程序的內存需求。窗口管理器（User）和圖形設備接口（GDI）在極大程度上被移出客戶端/服務端運行時子系統（CSRSS）并被落實在它自身的一個內核模塊中。
wKg0C2Q1UZKAI9jFAAA8HhChBCU732.png
這樣的設計無疑是為內核增添了一部分壓力，win32k.sys需要處理大量的用戶層回調，在這之后國外安全研究人員Tarjei Mandt公開了他對Win32k User-Mode Callback機制的研究成果，從此User-Mode Callback的攻擊面得到廣泛關注，UAF的漏洞也不斷的涌現。
下圖代碼為一個經典UAF漏洞，用戶層執行的某個函數通過syscall傳入到內核層，當內核代碼執行到xxxSomeCallback這一句時，用戶層可以在用戶定義的callback函數中獲得代碼執行的機會，如果用戶在callback函數調用了DestroyWindow函數銷毀窗口p，內核層的相應銷毀代碼將會被執行，p的相應內存被釋放，回調執行完畢，NtUserSysCall函數繼續執行，當執行到xxxSetWindowStyle(p)一句時，由于p的內存已經被釋放從而導致UAF漏洞的產生。
wKg0C2Q1UdGAG1l0AAB8AXXrrIM630.png
1.2 GDI對象
在TypeIsolation機制的引入之前，windows內核中以bitmap為代表的GDI對象成為內核漏洞利用時的首選，對于WWW漏洞來說，GDI對象就是它的“左膀右臂”，借助GDI對象可以很容易構造出穩定內核內存的任意地址讀寫原語，以此來繞過Windows的安全機制（KALSR、SMEP等）。
二、利用框架
漏洞成功利用漏洞觸發、漏洞利用這兩大環節，而漏洞利用又有以下三個階段，分別是堆噴射階段、信息泄露階段、代碼執行階段。下面將結合CVE-2019-0808、CVE-2021-1732進行詳細闡述。
2.1 漏洞觸發
漏洞的類型雖然五花八門，但基于win32k的內核漏洞是存在者一些共性的，也就是它的用戶層回調，近年來所爆出的win32k的漏洞，其觸發點大多都在用戶層回調被hook。下面將通過兩個案例來進行介紹。
案例1：
在CVE-2021-1732中，攻擊者正是hook xxxClientAllocWindowClassExtraBytes的用戶層回調函數，強行改變窗口對象tagWND的擴展數據的保存位置以及尋址方式，從而觸發一個任意地址覆蓋寫漏洞。
wKg0C2Q1UrqAce6UAACLexflaGQ178.png
針對這種觸發方式，我們可以直接對用戶層的usertable進行檢測，usertable存在于PEB+0x58偏移處:
案例2：
CVE-2021-40449 是Win32k 的 NtGdiResetDC 函數中的一個釋放后使用漏洞，在執行其自己的回調期間針對同一句柄第二次執行函數 ResetDC 時觸發UAF漏洞。
wKg0C2Q1UuOAZdTrAACPaTgCZog116.png
針對這種觸發方式，可以通過開啟Driver Virifier進行檢測，UAF的漏洞再此環境下會觸發藍屏。
2.2 漏洞利用
漏洞成功被觸發僅僅是一個好的開端，更重要的是漏洞利用點的尋找過程。筆者將此過程大致劃分為信息泄露、堆噴射、原語構造、代碼執行這四個階段。
1.信息泄露階段
在win32k漏洞利用過程中，內核對象的泄漏是至關重要的。可以說成功利用一個漏洞的大前提就是獲取win32k內核對象的地址。
wKg0C2Q1U3aAYy0iAAEH1E9EANQ917.png
上圖是對Windows內核地址泄漏的總結（來自GitHub），表格中包含截止目前泄漏內核對象的各種技巧。下面也是拿兩個demo來闡述內核對象泄露的細節：
- Demo1，通過GdiSharedHandleTable去泄露bitmap對象：
在R3通過CreateBitmap創建位圖成功后會得到一個hBitmap,如果要在R3去泄露該對象在內核中的地址可以通過GdiSharedHandleTable獲取。GdiSharedHandleTable位于PEB+0x94的位置。
wKg0C2Q1U5CAaWhkAAAepg2jbsk966.png
GdiSharedHandleTable的本質是一個指向GDICELL結構體數組的指針。
wKg0C2Q1U6KAT7J1AAA0SxX9GE617.png
同 CreateFile 類似，其實Windows 都用句柄（Handle）來標識用戶態對內核對象的引用。這個句柄低 16 位其實是數組索引。
wKg0C2Q1VAWAfZUXAAANNlwfltw725.png
通過上文，就可以計算出bitmap在內核中的地址。
wKg0C2Q1VBGAQck3AAAUsLBZxA641.png
- Demo2，通過HMValidateHandle函數泄漏內核對象：
HMValidateHandle是微軟未公開的一個函數，憑借此函數可以通過傳入句柄獲取對于內核對象的地址（win32k對象）。HMAllocObject創建了桌面堆類型句柄后，會把tagWND對象放入到內核模式到用戶模式內存映射地址里。 為了驗證句柄的有效性，窗口管理器會調用User32!HMValidateHandle函數讀取這個表。函數將句柄和句柄類型作為參數，并在句柄表中查找對應的項。如果查找到對象, 會返回tagWND只讀映射的對象指針，通過tagWND這個對象我們可以獲取到句柄等一系列窗口信息。
該函數地址是通過R3的user32.dll!IsMenu函數獲取到的。
wKg0C2Q1VDaAOEifAABK7i13EFg646.png
具體獲取方式如下：
wKg0C2Q1VEOAQ8crAADZGjJrmGw662.png
2.堆(池)噴射階段
堆（池）噴射是進行內存布局的常用手段, 通過在分配關鍵的內核對象之前，首先分配和釋放特定長度和數量的其他對象，使內核內存首先處于一個確定的狀態，來確保在分配關鍵的內核對象時，能夠被系統內存管模塊分配到我們所希望其分配到的某些位置，例如接近某些可控對象的位置。攻擊者可利用此種方法構造完美的內存布局從而達到自己的目的。此技術沒有固定的方法（“因地制宜”），但是所要達成的目的比較一致--執行shellcode以及信息泄露。
案例1：
Bitmap對象的地址在RS1中是通過AcceleratorTable獲取到的。先申請大量的AcceleratorTable對象然后釋放其中一個，接著申請大小相等的bitmap對象。通過泄漏AcceleratorTable對象的地址，即可等到bitmap的內核地址。（內存大小計算方式將在下一章節進行詳細闡述）
wKg0C2Q1VFiAatRuAABZb8ZW9wQ135.png
代碼框架如下
wKg0C2Q1VGGAC6cqAACw29G8S0A729.png
3.RW原語構造階段
在win32k內核漏洞利用中，RW原語同樣扮演著重要角色。它可以對所分配的關鍵內核對象后面的內存區域進行操作，以控制原本不能控制的相鄰對象的成員數據，這些數據將作為后續利用操作的重要節點。
下面將對win32k漏洞常用到的讀寫原語進行介紹：
- Bitmap系列：SetBitmapBits/GetBitmapBits可對內核對象bitmap的pvScan0指向的像素數據內存進行修改。
wKg0C2Q1VJ2AUPU9AAE36tbfPzk258.png
此系列一直到RS3微軟把Bitmap header與Bitmap data分離后，徹底失效。
- Palette系列：GetPaletteEntries/SetPaletteEntries可對內核對象Palette的成員pFirstColor（指向4個bytes的數組PALETTENTRY）修改構造RW原語。
wKg0C2Q1VNWAAeetAAB4GMR5X8A958.png
wKg0C2Q1VNqAACqeAACfThupnU170.png
- Wnd系列：SetWindowLog/SetWindowLogPtr對wnd(tagWnd)內核對象的修改能力。
應用場景1：
Wnd->StrName 字段是指向窗?標題名的指針，通過修改此變量，再借助?戶態下 的 InternalGetWindowText 和 NtUserDefSetText 函數則可實現任意內核地址讀寫
wKg0C2Q1VPWAP7o8AABRuCzwQr0810.png
應用場景2：
a)申請兩個連續的Wnd對象（Spray），Wnd0與Wnd1
b)通過漏洞能力將Wnd0的pExtraBytes字段變為可越界讀寫的。
c)通過Wnd0.的越界寫入能力，修改tagWND1.pExtraBytes到指定地址
d)借助SetWindowLongPtr的修改能力，最后使Wnd1獲得任意地址寫入能力。
wKg0C2Q1VSeAbZPuAAAwYN3HNgQ077.png
- Menu系列（最新）：GetMenuBarInfo，當其第二參數、第三參數分別設置成-3,1的時候，可以借助menu bar info獲取16字節的讀取能力。
wKg0C2Q1VTWATycRAACFCy5ktlM232.png
一般僅需tagMenuBarInfo.rcBar.left 和 tagMenuBarInfo.rcBar.top讀取指定地址的8個字節的數據。
wKg0C2Q1VUCAPhNuAACdn1vLEPQ467.png
另外，通過GetMenuBarInfo構造Read Primitive時，需要提前構造Fake Menu（用戶層），再通過SetWindowLongPtr對Target Wnd的Menu（內核層）進行替換，以達到讀取地址可控的目的。
wKg0C2Q1VUuAd8KAACqSW0mBns734.png
4.代碼執行階段
對于win32k內核漏洞，其最終利用方式就是本地提權，而提升權限的主要手法就是進行Token替換，共以下兩種方式：
- Token指針替換（_EX_FAST_REF替換）
wKg0C2Q1VWKASYr9AAA52Kc5NjM556.png
將當前進程 EPROCESS 中存儲的 Token 指針替換為 System 進程的 Token 指針。
wKg0C2Q1VW2AA6MzAACv5Wa8u5Q094.png
wKg0C2Q1VXKALdlUAAEJvY13O8519.png
- Token中的成員替換
將當前進程 EPROCESS 的成員 Token 指針指向的 Token 塊中的數據替換成 System 進程擁有的 Token 塊的數據
wKg0C2Q1VYSAWQaSAABAUD69sOQ973.png
將Present和Enabled的值更改為SYSTEM進程令牌的所有權限。
wKg0C2Q1VY2AK7OpAAA1U2FkTU378.png
三、內核對象
3.1 Bitmap
簡介
GDI（Windows Graphics Device Interface），是windows為應用程序提供圖形、文字顯示的 API 接口。
Bitmap是GDI中的圖形對象，用于創建、操作（縮放、滾動、旋轉和繪制）并將圖像作為文件存儲在磁盤上，其實際上為一個二元數組，去存儲像素、顏色、大小等信息。
- Bitmap關鍵結構體及對象
SURFACE對象（Bitmap在內核中的結構）
wKg0C2Q1VcKAYJpSAAAsz7rKY4c312.png
BaseObject，內核 GDI 對象類的基類都是一個稱作 _BASEOBJECT 的結構。對內核對象進行標記，用于描述最基礎的對象信息
wKg0C2Q1VdCASXVAAAlRzvaNM671.png
SURFOBJ（Bitmap核心結構），用于控制位圖的大小，像素等信息。
wKg0C2Q1VdABlnSAABTSUqvvrg712.png
- CreateBitmap相關
wKg0C2Q1VgCAbkXoAAApoINYtcc373.png
創建具有指定寬度，高度和顏色格式（顏色平面和位每像素）的位圖，而前文中也提過bitmap在內核中關聯的對象SURACE,由SURACE通過CreateBitamp的前4個參數去精確控制分配的內核內存塊的大小。其調用鏈如下：
wKg0C2Q1VhSAUxAQAAB75owvyTw709.png
在GreCreateBitmap函數中，首先根據傳入的 cPlanes 和 cBitsPerPel參數確定位圖的像素位類型，然后創建一個DEVBITMAPINFO對象，通過CreateBitmap前四個參數去內存塊中申請一片內存并且設置位圖數據掃描線的長度。接著lpBits如果不為0，則通過GreSetBitmapBits去設置像素數據。
wKg0C2Q1Vh6AEDA3AABVoGSJSBo274.png
DEVBITMAPINFO的結構：
wKg0C2Q1VieADLBBAABGYsmlzbI562.png
- 掃描線
在 Windows 內核中處理位圖像素數據時，通常是以一行作為單位進行的，像素的一行被稱為掃描線，而掃描線的長度就表示的是在位圖數據中向下移動一行所需的字節數。
位圖數據掃描線的長度被存儲在SURFACE+0x34 字節偏移的成員（即 SURFACE->so.lDelta 成員）中。這樣一來，成員 pvScan0 將指向當前位圖 SURFACE 對象的像素點數據緩沖區的起始位置。在后續對位圖像素點進行讀寫訪問時，系統位圖解析模塊將以該對象的 pvScan0 成員存儲的地址作為像素點數據區域起始地址。
wKg0C2Q1VkiADXVeAABsg3IFe0151.png
3.2 Palette
簡介
調色板是一個數組，其中包含標識當前可以在輸出設備上顯示或繪制的顏色的顏色值。調色板由能夠生成多種顏色但在任何給定時間只能顯示或繪制這些顏色的子集的設備使用。
Palette關鍵結構體及對象
PALETTE對象
wKg0C2Q1VuCAO8nAAE5zXPcDuQ249.png
PALETTE結構中，有三個成員是值得我們關注的分別是cEntries、pFirstColor、apalColors。cEntries指定當前調色板的項數，pFirstColor指向調色板列表起始表項（apalColors）的地址，apalColors是一個結構體數組存儲調色板列表數據。
PALETTEENTRY （調色板列表）
結構體 PALETTEENTRY 大小為 4 字節，其各個成員用于定義調色板表項對應的 24 位 RGB 顏色值等信息
wKg0C2Q1Vu6AZ8bAAApmXRjvG0967.png
Createpalette相關
wKg0C2Q1Vx2AOGL7AAAZ8CsH2YM553.png
Createpalette函數用來創建調色板對象，其只有一個參數lplgpl是指向LOFGPALETTE類型結構體對象的指針。定義如下：
wKg0C2Q1V4SACU02AABEui0D474872.png
這里我們僅需要關注第二個和第三個參數，palPalEntry是可變長度的 PALETTEENTRY 結構體類型數組，而palNumEntries來決定PALETTEENTRY 的個數。也就是說palette對象的大小是由palNumEntries控制的。
wKg0C2Q1V4ABNCAAAD39Rl4gy4172.png
顯然，我們可以得出palette對象大小的計算方式：4 * cEntries + 0x90/PALETTE/
3.3Wnd
簡介
Windows是對象，它們同時具有代碼和數據，但它們不是C++ 類。 相反，程序通過使用名為句柄 的值來引用窗口。句柄是不透明類型。實質上它只是操作系統用來標識對象的數字。可以想象Windows創建的所有窗口都有一個大表。它使用此表按其句柄查找窗口。 (它內部的工作方式是否完全相同都很重要。) 窗口句柄的數據類型是 HWND， 這通常發音為"aitch-wind"。 窗口句柄由創建窗口的函數返回 ：CreateWindow 和CreateWindowEx。
關鍵結構體及對象
這里只介紹tagWnd常用的字段,分別是tagwnd.cbwndextra和tagWND.ExtraBytes。當使用CreateWindowEx創建窗口時，可以在注冊窗口類時通過WNDCLASSEXA結構體中的cbWndExtra字段直接在內存中的tagWND對象之后請求額外的內存字節。
wKg0C2Q1ViAJvcjAAC9fUTdNWI133.png
關鍵函數分析
- CreateWindowEx
CreateWindowEx是用來創建窗口，在漏洞利用的世界中，Wnd地位是非常高的，可被用來進行堆spray，越界寫的容器等等。此次我們僅介紹Wnd的pExtraByte字段，分析它在內核中生成的過程。
wKg0C2Q1WEKAMR2AACNvR70g8412.png
上圖時CreateWindowEx到內核真正調用xxxCreateWindowEx函數的過程，xxxCreateWindowEx中回到tagWND的cbWndExtra字段進行判斷。
wKg0C2Q1WEyAUfiMAABVSsYn8w305.png
如果cbWndExtra不為0，則將其作為參數傳入xxxClientAllocWindowClassExtraBytes，在xxxClientAllocWindowClassExtraBytes中通過KeUserModeCallback進入到R3，最后調用RtlAllocateHeap為其在用戶層的桌面堆上申請一塊內存。
wKg0C2Q1WF6AaVL0AABDDmtkyk581.png
SetWindowLongPtr
對于SetWindowLongPtr函數，最重要的就是其對Wnd的修改能力，下圖xxxSetWindowLongPtr函數的部分反匯編代碼，可以看到當dwExtraFlag被設置為800后，可以直接對位于內核桌面堆的pExtraBytes+Index處的數據進行修改。
wKg0C2Q1WHCALoOMAABs2i1UgSE515.png
xxxSetWindowData
xxxSetWindowData函數可以對Wnd的spMenu進行替換，這是我們能夠利用Menu構造Read Primitive的先決條件。
wKg0C2Q1WIaAJ1E1AABtmMOgRZA040.png
獲取相鄰Wnd
相鄰的窗口中相差的只是一個tagWNDk結構體的大小
3.4Menu
簡介
菜單是為應用程序指定選項或選項組（子菜單）的項目列表。單擊菜單項打開子菜單或使應用程序執行命令。菜單管理也是win32k中最復雜得組件之一，其整體依賴多種十分復雜的函數和結構體。
Menu關鍵結構體及對象
tagMENU，
wKg0C2Q1WTOABfwBAADqVmnN14o150.png
tagPOPUPMENU，
wKg0C2Q1WTyAWWZAADxjkmL5X8350.png
信息泄露能力
通過spMenu泄漏EPROCESS內核地址，用于尋找SYSTEM進程以及Token替換。
wKg0C2Q1WVeAdGtAABRE7Pewxc086.png
四、攻防進化史
漏洞只有能夠被成功利用，才可以體現出它的價值。而對于win32k內核漏洞，最經典也是利用率最高的類型就是“任意地址任意寫(WWW)”漏洞。本章節將圍繞“ArbitraryOverwrite”，對win32k提權利用方式的進化史以及微軟相應的緩解措施進行詳細闡述。
4.1 Win7下的利用模式
緩解措施
個人認為Win7是Win32k內核漏洞利用最理想的環境，因其具有以下幾點特征：
- Win32k.sys未分離
- 信息泄露的方式最多（目前已知技術均兼容win7）
- 0頁內存機制未被緩解
- Win32k 內核對象公開（成員偏移清晰）
綜上，可以更加確認一個win32k內核漏洞在win7的利用率是極高的。
利用思路
我們以“Bitmap”為例，介紹內核提權漏洞在win7上的利用方式：
前提：Arbitrary Memory Write漏洞
- 創建兩個bitmap對象分別為hManager、hWorker,通過GdiSharedHandleTable泄露內核地址。
- 利用任意地址覆蓋寫漏洞，將hManager的pvScan0修改為指向hWorker成員pvScan0的地址。
wKg0C2Q1Wa6AOjwRAAAOHNIDfM234.png
- 構造對內核任意地址的RW原語（GetBitmapBits/SetBitmapBits）
wKg0C2Q1WbyAfWQ0AABWPadb8I609.png
- 本地提權—令牌替換
操作第一個 hManager，可以替換第二個 hWorker->pvScan0地址，再通過第二個 hWorker來將system進程的token寫入當前進程。
wKg0C2Q1WdWAP4PiAAEcglZL8Y656.png
4.2 RS1下的利用模式
緩解措施
GdiSharedHandleTable泄露bitmap的方式被緩解，GdiSharedHandleTable的pKernelAddress 指向一塊無意義的地址。
wKg0C2Q1WkSAW8wyAAGbgyaOwdY153.png
利用思路
結合網上資料，Windows 中存在著 3 種類型的對象，分別為 User object、GDI object、Kernel object，一共有 40 多種對象。
wKg0C2Q1WmaAJkNLAACzMzaa3VU995.png
而bitmap屬于GDI object其存在于換頁會話池中，由于GDI object泄露地址方式在RS1版本中被緩解，因此我們需要從另外兩種類型對象中去尋找替代方案。此次我們使用的是Accelerator table其屬于User object并且也存在于分頁會話池中。
wKg0C2Q1WnKAdfZAAAidc8gxcU837.png
Tips:非分頁池的虛擬地址被物理地址分配,而分頁池對應的虛擬地址和物理地址不存在一一映射，只保證在當前執行會話有效，其余內核操作時，并不要求這些對象必須在內存中。
- User Object地址獲取
在user32.dll中有一個全局變量gSharedInfo，其成員aheList為一個USER_HANDLE_ENTRY的句柄表。
wKg0C2Q1WoOACfYZAABH840fs30887.png
該句柄表的具體結構如下所示，其第一個成員為pKernel作用GdiSharedHandleTable 中的 pKernel 一致，均指向object在內核中的位置（KernelAddress）。
wKg0C2Q1WoyAb2hWAAAOnVvZ8c916.png
因此可通過USER_HANDLE_ENTRY去泄露Accelerator table的內核對象地址。
KernelAddress= SHAREDINFO->USER_HANDLE_ENTRY->pKernel + handle&0xffff
- Accelerator table 對象創建
函數 CreateAcceleratorTable 用來在內核中創建快捷鍵對應表。
wKg0C2Q1Wp2ATnvAAAXHn4ybg394.png
該函數存在 LPACCEL lpaccl 和 int cAccel 兩個參數。參數 lpaccl 作為指向 ACCEL 結構體類型數組的指針，cAccel 表示數組的元素個數。結構體 ACCEL (szie=6)的定義如下:
wKg0C2Q1WqeARsSAAAA5BM3aN0c314.png
- 堆分水
通過1)、2)我們肯定可以想到通過內存分水技術去泄露bitmap內核對象的地址，經筆者分析得出可以控制CreateAcceleratorTable 的參數，來控制其到內核所申請內存的大小。
wKg0C2Q1WxKAGITMAABN5EuR2U269.png
現在，bitmap和AcceleratorTable內核對象的大小均可控，可以進行內存布局。過程如下：
wKg0C2Q1Wx2AOixGAACSUNu5bg788.png
至此，我們就可以成功泄露bitmap內核對象的地址啦！
wKg0C2Q1W0iAdWGnAACTFPUjts242.png
后續提權過程與win7一致。
4.3 RS2 下的利用模式
緩解措施
在RS2中pKernel指向異常地址， AcceleratorTable + 池風水泄露pvScan0的方式失效
利用思路
新的替代方案—桌面堆，更準確一點就在桌面堆上的lpszMenuName。lpszMenuName就是我們創建窗口時wndclass的成員，同bitmap一樣它也存于換頁內存池。
另外，我們還需知道桌面堆是有兩份分別存于用戶態和內核態。
wKg0C2Q1W4SAfnL5AABHHHDvfzk145.png
上圖，在網上流傳的比較火，應該是國外某位大神逆出來，再此稍稍瞻仰一下。有了這個我們就可以通過桌面堆來泄露bitmap的內核地址啦。
- 獲取lpszMenuName的地址.
首先，我們要得到內核態桌面堆到用戶態桌面堆的偏移值ulClientDelta。
wKg0C2Q1W52ATszxAAB0SOVOLXg150.png
通過HMValidateHandle泄露Wnd的內核地址，然后通過用戶態的tagCLS獲取lpszMenuName（0x98）的地址。
wKg0C2Q1W8OAL3mkAACdFHYmuE332.png
泄露結果如下所示：
wKg0C2Q1W86AKpsnAABZVdDesEE087.png
- 堆風水
到這，相信大家都知道可以通過桌面堆對象進行占坑，并控制lpszMenuName的大小與bitmap大小一致。即可成功泄露bitmap的內核地址。lpszMenuName申請內存過程堆棧如下，其大小為實際申請大小。
wKg0C2Q1WCAI0bvAAB69JVUyuc773.png
另外，BitMap的SurFace結構 在RS2上比RS1增大了10。
內存布局如下，申請等大小的lpszMenuName和bitmap。利用UAF技術確保泄露lpszMenuName的地址穩定之后使用bitmap占坑。
wKg0C2Q1WCALEPyAACLaCzLK00651.png
下圖來自fuzzySecurity的blog,精確的展現出通過lpszMenuName進行UAF后泄露bitmap的過程。
wKg0C2Q1WAWHyrAADIeqoA8bM878.png
4.4 RS3 下的利用模式
緩解措施
微軟引入了 TypeIsolation 功能將Bitmap header與Bitmap data分離，無法通過Bitmap header取得pvscan0指針的內核地址。
利用思路
在第三章節介紹過另一個用于WWW漏洞利用的內核對象—Palette，它和bitmap有著異曲同工之妙，palette對象的0x90處是一個4字節的數組apalColors，相當于BitMap里的pixel data，pFirstColor是一個指針，指向apalColors，相當于BitMap里的pvScan0。
wKg0C2Q1XCaAB5nYAAATtJzGCek419.png
因此，我們完全可以按照在RS2中的利用思路，完成在RS3中的提權。
- 創建兩個palette對象分別為hManager、hWorker,并通過桌面堆泄露內核地址。
wKg0C2Q1XLaAOI9AAAx7y9av8004.png
泄露的方法還是采用池分水技術，利用lpszMenuName為palette占坑。
Palette大小的計算方式：LOGPALETTE->palNumEntries進行控制的，具體如下：
- 利用任意地址覆蓋寫漏洞，將hManager的pFirstColor修改為指向hWorker成員pFirstColor的地址。
wKg0C2Q1XO6AR2yHAACUl66GW9A717.png
- 構造對內核任意地址的RW原語（GetPaletteEntries/ SetPaletteEntries）
wKg0C2Q1XPyAWPaJAACkIwPXv2o616.png
- 提權-令牌替換（與bitmap方式一致）
wKg0C2Q1XReAP7maAADQpi2kHrQ470.png
4.5 攻防現狀
緩解措施
RS4:
HMValidateHandle泄露內核方法失效
Palette同樣被TypeIsolation進行header和body分離
RS5:
微軟修改大量API，桌面堆泄露的方法被緩解 。
2.新的思路
到這，已有的所有泄露GDI對象的方法均以被緩解。但車到山前必有路，這也正體現了攻防對抗的魅力，直到2021年CVE-2021-1732的漏洞被爆出，不同于傳統的內核漏洞，需借助“溢出”來完成漏洞利用，該漏洞是由于窗口類型混淆而導致的，通過spMenu的信息泄漏能力和借助GetMenuBarInfo/SetWindowLong函數構造讀寫原語（RW Primitive），最后通過純數據攻擊（DataOnlyAttack，特點不需要執行原語，只操縱操作系統使用的數據結構以實現提權）實現內核提權。
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環境介紹
靶場
HEVD的一個Windows Kernel Exploition訓練項目--HackSysExtremeVulnerableDriver
https://github.com/hacksysteam/HackSysExtremeVulnerableDriver
wKg0C2Q1XXiAPjCQAACoYoHRIJY361.png
