漏洞分析
在本文中我們試圖通過公開的針對Windows 7 64位環境的內核提權POC對漏洞原理和利用過程進行詳細分析，並記錄整個分析過程。如有分析不當之處敬請諒解。
分析環境：分析和調試的過程將在 Windows 7 x64 為基礎的環境中進行
樣本來源：https://github.com/unamer/CVE-2018-8120
補丁比較
通過分析安全公告補丁程序可以知道，本次漏洞主要修復了系統中的win32k.sys內核模塊文件，我們將64位Windows 7中的win32k.sys文件與未打補丁的文件進行對比，發現本次針對 win32k.sys 的NtUserSetImeInfoEx函數做了以下修補：
可以明顯看到，補丁後的函數代碼在函數中增加了對窗口站對象tagWINDOWSTATION的成員域spklList的值是否為0的校驗，如果值為0則函數直接返回：
修補前的代碼：
修補後的代碼：
漏洞細節
根據以上對win32k.sys補丁前後改動的代碼對比可知，漏洞發生在函數NtUserSetImeInfoEx中。NtUserSetImeInfoEx 是操作系統提供的接口函數，用於將用戶進程定義的輸入法擴展信息對象設置在與當前進程關聯的窗口站中。
窗口站
窗口站是和當前進程和會話(session)相關聯的一個內核對象，它包含剪貼板(clipboard)、原子表、一個或多個桌面(desktop)對象等。窗口站 tagWINDOWSTATION 結構體的定義如下：
NtUserSetImeInfoEx執行過程分析
知道了補丁代碼修復的部分，我們來看下漏洞函數NtUserSetImeInfoEx的具體實現，此函數只有一個tagIMEINFOEX類型的參數：
整理後的漏洞函數執行過程分析如下：
l 函數先獲取當前的窗口站rpwinsta，並從rpwinsta指向的窗口站對象中獲取spklList成員
spklList 是指向關聯的鍵盤佈局 tagKL 對象鏈表首節點的指針。鍵盤佈局 tagKL 結構體的定義如下：
l 然後函數從首節點開始遍歷鍵盤佈局對象鏈表，直到節點對象的pklNext成員指回到首節點對象為止。函數判斷每個被遍歷的節點對象的hkl成員是否與參數 ime_info_ex 指向的源輸入法擴展信息對象的hkl成員相等
l 接下來函數判斷目標鍵盤佈局對象的piiex成員是否為空，且成員變量 fLoadFlag 值是否為 FALSE。如果是，則把參數 ime_info_ex 的數據拷貝到目標鍵盤佈局對象的piiex成員中
函數的實現過程比較簡單，在這裡我們可以清楚的看到分析過程的第2步中導致漏洞產生的原因：
在遍歷鍵盤佈局對象鏈表 spklList 的時候並沒有判斷 spklList 地址是否為 NULL，假設此時 spklList 為空的話，接下來對 spklList 訪問的時候將觸發訪問異常，導致系統 BSOD 的發生。
POC驗證
我們使用PowerShell腳本來測試驗證該漏洞，以下PowerShell腳本使用CreateWindowStation創建了一個窗口站，並調用函數 SetProcessWindowStation 將創建的窗口站與當前進程關聯起來，然後打印出窗口站的HANDLE，最後調用 NtUserSetImeInfoEx 函數觸發漏洞：
打印出窗口站HANDLE後我們使用PCHunter找到窗口站的內核地址0xfffffA801a1c4270：
在WinDbg中使用win32k!tagWINDOWSTATION結構類型查看創建的窗口站句柄0xfffffA801a1c4270地址：
這時我們可以看到spklList 在創建的窗口站中默認初始化為空的。結合上面的我們對 NtUserSetImeInfoEx 函數的分析可知，如果此時我們接著調用 NtUserSetImeInfoEx 函數的話, 就會導致系統 BSOD 的發生：
異常代碼：
總結整個漏洞成因：
l 當用戶進程調用CreateWindowStation 等函數創建新的窗口站時，最終在內核會執行窗口站創建的操作。在該函數執行期間，新的窗口站對象的 spklList 成員並沒有被初始化，將始終指向 NULL 地址。
l 而NtUserSetImeInfoEx並沒有對窗口站對象的 spklList 成員做空指針判斷，由於當前進程關聯的窗口站對象的 spklList 成員指向 NULL 地址，而空地址所在的零頁內存此時並沒有映射，因此當內核函數 NtUserSetImeInfoEx 在試圖訪問零頁內存時，將觸發訪問異常，導致BSOD 的發生。
Windows 7 x64環境下的漏洞利用
2018年5月20日，@unamer 在 github 上傳了一份使用CVE-2018-8120針對Windows 7、Windows 2008 32位和64位系統下的提權利用代碼。此章節我們通過公開的樣本來分析Windows 7 x64環境下使用該漏洞的提權利用過程。
分配零頁內存
由前面的分析可知，由於代碼設計不當，當內核中某個對象指針指向空地址這樣的位於用戶地址空間的內存地址時，用戶進程中的利用代碼將能夠通過分配這樣的內存頁並進行巧妙的內存佈局來實現任意內核代碼執行的能力，從而實現提權操作。
而漏洞觸發的時候NtUserSetImeInfoEx 函數會把可控參數拷貝到零地址上，瞭解虛擬地址空間分佈知識的話都應該知道，在32位 Windows系統中，可用的虛擬地址空間共計為 2^32 字節（4 GB）。通常低地址的2GB用於用戶空間，高地址的2GB 用於系統內核空間。而在64位 Windows系統中，虛擬地址空間的理論大小為 2^64 字節，但實際上僅使用一部分。範圍從 0×000’00000000 至 0x7FF’FFFFFFFF 的 8 TB 用於用戶空間，範圍從 0xFFFF0800’00000000 至 0xFFFFFFFF’FFFFFFFF 的 248 TB 的部分用於系統空間。可以注意到空指針賦值分區，這一分區是進程地址空間中從0×00000000到0x0000FFFF的閉區間，保留該分區的目的是為了幫助程序員捕獲對空指針的賦值。而如果進程中的線程試圖讀取或寫入位於這一分區內的內存地址，則會引發訪問違規異常：
虛擬地址空間分部
而使用ZwAllocateVirtualMemory函數可以在指定進程的虛擬空間中申請一塊內存，該塊內存默認將以64kb大小對齊。將BaseAdress設置為0時，系統會尋找第一個未使用的內存塊來分配，並不能在零頁內存中分配空間。在AllocateType參數中有一個分配類型是MEM_TOP_DOWN,該類型表示內存分配從上向下分配內存。如果指定 BaseAddress為一個低地址，例如 1，同時指定分配內存的大小大於這個值 ，例如8192（一個內存頁），這樣分配成功後 地址範圍就是0xFFFFE001（-8191）到 1把0地址包含在內了，此時再去嘗試向 NULL指針執行的地址寫數據，程序就不會異常了。通過這種方式我們發現在0地址分配內存的同時，也會在高地址（內核空間）分配內存。詳細請參考[11]。
Bitmap GDI函數實現內核任意地址讀/寫
而利用最近幾年提出的通過修改Bitmap GDI函數關鍵對象的方式則可以將有限的任意地址寫漏洞轉化為內核任意地址讀/寫。此技術關鍵在當創建一個bitmap時，我們可以洩露出其在內核中的地址。這一洩露在Windows10的v1607版本之後才被打上補丁。
當創建一個bitmap時，一個結構被附加到了進程PEB的GdiSharedHandleTable成員中。GdiSharedHandleTable是一個GDICELL64結構體數組的指針：
我們可以以下方式找到Bitmap的內核地址：
使用WinDbg來驗證整個過程：
l 首先用以下PowerShell腳本創建一個Bitmap對象，並打印內核對象句柄，然後用工具找到這個的對象以便後面做對比
打印出Bitmap內核對象句柄：
切換進程：
獲取GdiSharedHandleTable地址：
獲取Bitmap 句柄地址：
可以看到地址fffff900`c1ca6000和上面圖片裡用工具獲取的一致，Bitmap內核地址有了，該怎麼用呢？GDICELL結構的 pKernelAddress 成員指向 BASEOBJECT 結構，不過我們關心的是在這一頭部之後，有一個特定的結構體，它的類型是由 wType 成員決定的：
位圖結構：
pvScan0 成員就是我們需要利用的，因為GetBitmapBits 和 SetBitmapBits 這兩個API能操作這個成員。GetBitmapBits 允許我們在 pvScan0 地址上讀任意字節，SetBitmapBits 允許我們在 pvScan0 地址上寫任意字節。如果我們有一個漏洞(例如：CVE-2018-8120)可以修改一次內核地址, 把 pvScan0 改成我們想要操作的內核地址，這樣是不是就實現了可以重複利用的內核任意讀寫呢？
有了這些基礎知識，我們整理出使用該方法並配合某個任意地址寫的漏洞來將GetBitmapBits / SetBitmapBits改造成可以實現任意地址讀寫的利用函數，具體步驟：
l 創建2個位圖（Manager/Worker）
l 使用句柄查找GDICELL64，分別計算兩個位圖的pvScan0 地址
l 使用漏洞將 WorkerpvScan0 偏移量地址寫入 Manager 的 pvScan0 值
l 使用 Manager 上的SetBitmapBits 來選擇地址
l 在 Worker 上使用GetBitmapBits/ SetBitmapBits來讀取/寫入上一步設置的地址
整個利用操作流程如下：
利用Bitmap GDI實現CVE-2018-8120在Windows 7 x64環境下的漏洞利用
有了上述的所有基礎知識，我們來看看利用程序是如果使用該技術在Windows 7 64位環境下利用CVE-2018-8120實現提權攻擊的。
第一步，首先利用ZwAllocateVirtualMemory分配基地址位於零頁的內存塊，以使零頁完成映射：
調用NtAllocateVirtualMemory函數成功在零地址上面分配了一塊空間：
第二步，創建創建2個位圖（Manager/Worker）對象，並使用CVE-2018-8120漏洞將 WorkerpvScan0偏移量地址寫入Manager 的 pvScan0 值，創建內核任意地址讀寫能力，具體操作如下：
l 創建兩個bitmap對象
l 洩露出各自的內核地址，得到mpv 和 wpv 兩個指針：
l 使用任意寫來設置 mpv 去指向 wpv 的地址，實現可重用的內核任意讀寫
先要構造環境讓函數運行到下面拷貝數據的地方，還記得上面我們對 NtUserSetImeInfoEx 函數漏洞原理的分析嗎？ NtUserSetImeInfoEx 函數從首節點開始遍歷鍵盤佈局對象鏈表，直到節點對象的pklNext成員指回到首節點對象為止。然後判斷每個被遍歷的節點對象的 hkl 成員是否與參數 ime_info_ex 指向的源輸入法擴展信息對象的 hkl 成員相等。為了觸發後面的拷貝操作，我們需要跳過這個循環
要跳過這個循環很簡單，我們讓 pkl->hkl 和 NtUserSetImeInfoEx 函數的參數地址相等就行了。下面的代碼就是在零頁地址位置偽造了一個和 tagIMEINFOEX 結構體 spklList 成員類型一樣的 tagKL 結構體，然後把它的 hkl 字段設置為 wpv 的地址。後面我們把 wpv 的地址放在 NtUserSetImeInfoEx 函數的參數 ime_info_ex 的第一個成員裡面。這樣就不會進入 while ( pkl->hkl != ime_info_ex ) 這個循環了：
然後再把 mpv 的地址放在零頁內存地址偏移0×50 的地方，NtUserSetImeInfoEx 函數會把它的參數( IMEINFOEX 結構)拷貝到目標鍵盤佈局 tagKL 對象的 piiex 成員指向的輸入法信息對象緩衝區中。在win7 x64下面這個字段的偏移就是 0×50：
以下是調試時候獲取到的mpv 和 wpv 的值：
接著構造漏洞利用環境，調用CreateWindowStation 函數創建一個窗口站，調用 SetProcessWindowStation 函數把窗口站和當前進程關聯起來，接著構造一個 tagIMEINFOEX 結構，把 wpv 的地址放到它的 hkl 成員中，調用 NtUserSetImeInfoEx 後，NtUserSetImeInfoEx 函數就會把 wpv 的地址拷貝到 mpv 裡面：
在調試器裡面我們可以看到 已經成功觸發了NtUserSetImeInfoEx 的漏洞：
當NtUserSetImeInfoEx 執行完後，我們的GDI內核任意讀寫的環境就已經構造好了：
注意：NtUserSetImeInfoEx觸發的拷貝數據長度是不可控的，memmove(piiex, &ime_info_ex, 0x160ui64); 代碼裡面可以看到是0×160的長度，也就是sizeof(tagIMEINFOEX),我們要在這個地方修改Worker Bitmap的 pvScan0的地址，就會把 SURFACE 結構裡面的其它數據給覆蓋掉。後面調用Gdi32 的 GetBitmapBits/SetBitmapBits 這兩個函數就會不成功，因為這兩個函數操作pvScan0 的方式是和 SURFOBJ 結構的 lDelta、iBitmapFormat、iType、fjBitmap 還有 SURFACE 結構的 flags 字段相關的。關於該結構的詳細信息可以參考[10]。
以下代碼是需要修復成員的對應值：
最後一步，使用 Gdi32 的GetBitmapBits/SetBitmapBits API調用來讀寫內核地址空間，實現任意代碼執行：
下面的代碼實現了替換HalDispatchTable 裡面的 NtQueryIntervalProfile 函數為我們的提權ShellCode的地址，調用NtQueryIntervalProfile 以達到執行ShellCode的目的：
最終在ShellCode中替換SYSTEM進程的token為當前進程的token，以實現提權：
閱讀更多 網絡安全晴雨表 的文章
