溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
CVE-2018-8120在Windows 7 x64環境下的漏洞利用分析是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
2018年5月15日，ESET披露了其捕獲的PDF文檔樣本中的兩枚0-day漏洞。其中CVE-2018-4990為Adobe PDF閱讀器的代碼執行漏洞，而CVE-2018-8120則是Windows操作系統Win32k的內核提權漏洞，在獲取代碼執行權限后通過內核提權漏洞繞過Adobe PDF閱讀器的沙盒保護，實現任意代碼執行。
360威脅情報中心在2018年5月25日已經發布了《CVE-2018-4990 Adobe Reader 代碼執行漏洞利用分析》（詳見參考資料[1]），而其中的內核提權漏洞雖然已經有公開的漏洞利用代碼，但僅僅是針對Windows 32位環境下的利用。由于大部分用戶機器已經是64位操作系統，所以泄露的利用代碼危害有限。而在近日，有安全研究人員在GitHub上上傳了針對Windows 7 64位環境下CVE-2018-8120的漏洞利用代碼，經驗證分析該漏洞利用代碼真實可用，考慮到漏洞相關的技術細節和驗證程序已經公開，所以此漏洞接下來極有可能被利用來執行大規模的攻擊。
在本文中我們試圖通過公開的針對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 的發生。
我們使用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 的發生。
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 字節，但實際上僅使用一部分。范圍從 0x000'00000000 至 0x7FF'FFFFFFFF 的 8 TB 用于用戶空間，范圍從 0xFFFF0800'00000000 至 0xFFFFFFFF'FFFFFFFF 的 248 TB 的部分用于系統空間。可以注意到空指針賦值分區，這一分區是進程地址空間中從0x00000000到0x0000FFFF的閉區間，保留該分區的目的是為了幫助程序員捕獲對空指針的賦值。而如果進程中的線程試圖讀取或寫入位于這一分區內的內存地址，則會引發訪問違規異常：
虛擬地址空間分部
而使用ZwAllocateVirtualMemory函數可以在指定進程的虛擬空間中申請一塊內存，該塊內存默認將以64kb大小對齊。將BaseAdress設置為0時，系統會尋找第一個未使用的內存塊來分配，并不能在零頁內存中分配空間。在AllocateType參數中有一個分配類型是MEM_TOP_DOWN,該類型表示內存分配從上向下分配內存。如果指定 BaseAddress為一個低地址，例如 1，同時指定分配內存的大小大于這個值 ，例如8192（一個內存頁），這樣分配成功后 地址范圍就是0xFFFFE001（-8191）到 1把0地址包含在內了，此時再去嘗試向 NULL指針執行的地址寫數據，程序就不會異常了。通過這種方式我們發現在0地址分配內存的同時，也會在高地址（內核空間）分配內存。詳細請參考[11]。
而利用最近幾年提出的通過修改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來讀取/寫入上一步設置的地址
整個利用操作流程如下：
有了上述的所有基礎知識，我們來看看利用程序是如果使用該技術在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 的地址放在零頁內存地址偏移0x50 的地方，NtUserSetImeInfoEx 函數會把它的參數( IMEINFOEX 結構)拷貝到目標鍵盤布局 tagKL 對象的 piiex 成員指向的輸入法信息對象緩沖區中。在win7 x64下面這個字段的偏移就是 0x50：
以下是調試時候獲取到的mpv 和 wpv 的值：
接著構造漏洞利用環境，調用CreateWindowStation 函數創建一個窗口站，調用 SetProcessWindowStation 函數把窗口站和當前進程關聯起來，接著構造一個 tagIMEINFOEX 結構，把 wpv 的地址放到它的 hkl 成員中，調用 NtUserSetImeInfoEx 后，NtUserSetImeInfoEx 函數就會把 wpv 的地址拷貝到 mpv 里面：
在調試器里面我們可以看到 已經成功觸發了NtUserSetImeInfoEx 的漏洞：
當NtUserSetImeInfoEx 執行完后，我們的GDI內核任意讀寫的環境就已經構造好了：
注意：NtUserSetImeInfoEx觸發的拷貝數據長度是不可控的，memmove(piiex, &ime_info_ex, 0x160ui64); 代碼里面可以看到是0x160的長度，也就是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，以實現提權：
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
