CVE-2018-8120在Windows 7 x64環(huán)境下的漏洞利用分析是怎樣的

CVE-2018-8120在Windows 7 x64環(huán)境下的漏洞利用分析是怎樣的，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

背景

2018年5月15日，ESET披露了其捕獲的PDF文檔樣本中的兩枚0-day漏洞。其中CVE-2018-4990為Adobe PDF閱讀器的代碼執(zhí)行漏洞，而CVE-2018-8120則是Windows操作系統(tǒng)Win32k的內(nèi)核提權(quán)漏洞，在獲取代碼執(zhí)行權(quán)限后通過(guò)內(nèi)核提權(quán)漏洞繞過(guò)Adobe PDF閱讀器的沙盒保護(hù)，實(shí)現(xiàn)任意代碼執(zhí)行。

360威脅情報(bào)中心在2018年5月25日已經(jīng)發(fā)布了《CVE-2018-4990 Adobe Reader 代碼執(zhí)行漏洞利用分析》（詳見(jiàn)參考資料[1]），而其中的內(nèi)核提權(quán)漏洞雖然已經(jīng)有公開(kāi)的漏洞利用代碼，但僅僅是針對(duì)Windows 32位環(huán)境下的利用。由于大部分用戶機(jī)器已經(jīng)是64位操作系統(tǒng)，所以泄露的利用代碼危害有限。而在近日，有安全研究人員在GitHub上上傳了針對(duì)Windows 7 64位環(huán)境下CVE-2018-8120的漏洞利用代碼，經(jīng)驗(yàn)證分析該漏洞利用代碼真實(shí)可用，考慮到漏洞相關(guān)的技術(shù)細(xì)節(jié)和驗(yàn)證程序已經(jīng)公開(kāi)，所以此漏洞接下來(lái)極有可能被利用來(lái)執(zhí)行大規(guī)模的攻擊。

漏洞分析

在本文中我們?cè)噲D通過(guò)公開(kāi)的針對(duì)Windows 7 64位環(huán)境的內(nèi)核提權(quán)POC對(duì)漏洞原理和利用過(guò)程進(jìn)行詳細(xì)分析，并記錄整個(gè)分析過(guò)程。如有分析不當(dāng)之處敬請(qǐng)諒解。

分析環(huán)境：分析和調(diào)試的過(guò)程將在 Windows 7 x64 為基礎(chǔ)的環(huán)境中進(jìn)行

樣本來(lái)源：https://github.com/unamer/CVE-2018-8120

補(bǔ)丁比較

通過(guò)分析安全公告補(bǔ)丁程序可以知道，本次漏洞主要修復(fù)了系統(tǒng)中的win32k.sys內(nèi)核模塊文件，我們將64位Windows 7中的win32k.sys文件與未打補(bǔ)丁的文件進(jìn)行對(duì)比，發(fā)現(xiàn)本次針對(duì) win32k.sys 的NtUserSetImeInfoEx函數(shù)做了以下修補(bǔ)：

可以明顯看到，補(bǔ)丁后的函數(shù)代碼在函數(shù)中增加了對(duì)窗口站對(duì)象tagWINDOWSTATION的成員域spklList的值是否為0的校驗(yàn)，如果值為0則函數(shù)直接返回：

修補(bǔ)前的代碼：

修補(bǔ)后的代碼：

漏洞細(xì)節(jié)

根據(jù)以上對(duì)win32k.sys補(bǔ)丁前后改動(dòng)的代碼對(duì)比可知，漏洞發(fā)生在函數(shù)NtUserSetImeInfoEx中。NtUserSetImeInfoEx 是操作系統(tǒng)提供的接口函數(shù)，用于將用戶進(jìn)程定義的輸入法擴(kuò)展信息對(duì)象設(shè)置在與當(dāng)前進(jìn)程關(guān)聯(lián)的窗口站中。

窗口站

窗口站是和當(dāng)前進(jìn)程和會(huì)話(session)相關(guān)聯(lián)的一個(gè)內(nèi)核對(duì)象，它包含剪貼板(clipboard)、原子表、一個(gè)或多個(gè)桌面(desktop)對(duì)象等。窗口站 tagWINDOWSTATION 結(jié)構(gòu)體的定義如下：

NtUserSetImeInfoEx執(zhí)行過(guò)程分析

知道了補(bǔ)丁代碼修復(fù)的部分，我們來(lái)看下漏洞函數(shù)NtUserSetImeInfoEx的具體實(shí)現(xiàn)，此函數(shù)只有一個(gè)tagIMEINFOEX類型的參數(shù)：

整理后的漏洞函數(shù)執(zhí)行過(guò)程分析如下：

l  函數(shù)先獲取當(dāng)前的窗口站rpwinsta，并從rpwinsta指向的窗口站對(duì)象中獲取spklList成員

spklList 是指向關(guān)聯(lián)的鍵盤(pán)布局 tagKL 對(duì)象鏈表首節(jié)點(diǎn)的指針。鍵盤(pán)布局 tagKL 結(jié)構(gòu)體的定義如下：

l  然后函數(shù)從首節(jié)點(diǎn)開(kāi)始遍歷鍵盤(pán)布局對(duì)象鏈表，直到節(jié)點(diǎn)對(duì)象的pklNext成員指回到首節(jié)點(diǎn)對(duì)象為止。函數(shù)判斷每個(gè)被遍歷的節(jié)點(diǎn)對(duì)象的hkl成員是否與參數(shù) ime_info_ex 指向的源輸入法擴(kuò)展信息對(duì)象的hkl成員相等

l  接下來(lái)函數(shù)判斷目標(biāo)鍵盤(pán)布局對(duì)象的piiex成員是否為空，且成員變量 fLoadFlag 值是否為 FALSE。如果是，則把參數(shù) ime_info_ex 的數(shù)據(jù)拷貝到目標(biāo)鍵盤(pán)布局對(duì)象的piiex成員中

函數(shù)的實(shí)現(xiàn)過(guò)程比較簡(jiǎn)單，在這里我們可以清楚的看到分析過(guò)程的第2步中導(dǎo)致漏洞產(chǎn)生的原因：

在遍歷鍵盤(pán)布局對(duì)象鏈表 spklList 的時(shí)候并沒(méi)有判斷 spklList 地址是否為 NULL，假設(shè)此時(shí) spklList 為空的話，接下來(lái)對(duì) spklList 訪問(wèn)的時(shí)候?qū)⒂|發(fā)訪問(wèn)異常，導(dǎo)致系統(tǒng) BSOD 的發(fā)生。

POC驗(yàn)證

我們使用PowerShell腳本來(lái)測(cè)試驗(yàn)證該漏洞，以下PowerShell腳本使用CreateWindowStation創(chuàng)建了一個(gè)窗口站，并調(diào)用函數(shù) SetProcessWindowStation 將創(chuàng)建的窗口站與當(dāng)前進(jìn)程關(guān)聯(lián)起來(lái)，然后打印出窗口站的HANDLE，最后調(diào)用 NtUserSetImeInfoEx 函數(shù)觸發(fā)漏洞：

打印出窗口站HANDLE后我們使用PCHunter找到窗口站的內(nèi)核地址0xfffffA801a1c4270：

在WinDbg中使用win32k!tagWINDOWSTATION結(jié)構(gòu)類型查看創(chuàng)建的窗口站句柄0xfffffA801a1c4270地址：

這時(shí)我們可以看到spklList 在創(chuàng)建的窗口站中默認(rèn)初始化為空的。結(jié)合上面的我們對(duì) NtUserSetImeInfoEx 函數(shù)的分析可知，如果此時(shí)我們接著調(diào)用 NtUserSetImeInfoEx 函數(shù)的話, 就會(huì)導(dǎo)致系統(tǒng) BSOD 的發(fā)生：

異常代碼：

總結(jié)整個(gè)漏洞成因：

l  當(dāng)用戶進(jìn)程調(diào)用CreateWindowStation 等函數(shù)創(chuàng)建新的窗口站時(shí)，最終在內(nèi)核會(huì)執(zhí)行窗口站創(chuàng)建的操作。在該函數(shù)執(zhí)行期間，新的窗口站對(duì)象的 spklList 成員并沒(méi)有被初始化，將始終指向 NULL 地址。

l  而NtUserSetImeInfoEx并沒(méi)有對(duì)窗口站對(duì)象的 spklList 成員做空指針判斷，由于當(dāng)前進(jìn)程關(guān)聯(lián)的窗口站對(duì)象的 spklList 成員指向 NULL 地址，而空地址所在的零頁(yè)內(nèi)存此時(shí)并沒(méi)有映射，因此當(dāng)內(nèi)核函數(shù) NtUserSetImeInfoEx 在試圖訪問(wèn)零頁(yè)內(nèi)存時(shí)，將觸發(fā)訪問(wèn)異常，導(dǎo)致BSOD 的發(fā)生。

Windows 7 x64環(huán)境下的漏洞利用

2018年5月20日，@unamer 在 github 上傳了一份使用CVE-2018-8120針對(duì)Windows 7、Windows 2008 32位和64位系統(tǒng)下的提權(quán)利用代碼。此章節(jié)我們通過(guò)公開(kāi)的樣本來(lái)分析Windows 7 x64環(huán)境下使用該漏洞的提權(quán)利用過(guò)程。

分配零頁(yè)內(nèi)存

由前面的分析可知，由于代碼設(shè)計(jì)不當(dāng)，當(dāng)內(nèi)核中某個(gè)對(duì)象指針指向空地址這樣的位于用戶地址空間的內(nèi)存地址時(shí)，用戶進(jìn)程中的利用代碼將能夠通過(guò)分配這樣的內(nèi)存頁(yè)并進(jìn)行巧妙的內(nèi)存布局來(lái)實(shí)現(xiàn)任意內(nèi)核代碼執(zhí)行的能力，從而實(shí)現(xiàn)提權(quán)操作。

而漏洞觸發(fā)的時(shí)候NtUserSetImeInfoEx 函數(shù)會(huì)把可控參數(shù)拷貝到零地址上，了解虛擬地址空間分布知識(shí)的話都應(yīng)該知道，在32位 Windows系統(tǒng)中，可用的虛擬地址空間共計(jì)為 2^32 字節(jié)（4 GB）。通常低地址的2GB用于用戶空間，高地址的2GB 用于系統(tǒng)內(nèi)核空間。而在64位 Windows系統(tǒng)中，虛擬地址空間的理論大小為 2^64 字節(jié)，但實(shí)際上僅使用一部分。范圍從 0x000'00000000 至 0x7FF'FFFFFFFF 的 8 TB 用于用戶空間，范圍從 0xFFFF0800'00000000 至 0xFFFFFFFF'FFFFFFFF 的 248 TB 的部分用于系統(tǒng)空間。可以注意到空指針賦值分區(qū)，這一分區(qū)是進(jìn)程地址空間中從0x00000000到0x0000FFFF的閉區(qū)間，保留該分區(qū)的目的是為了幫助程序員捕獲對(duì)空指針的賦值。而如果進(jìn)程中的線程試圖讀取或?qū)懭胛挥谶@一分區(qū)內(nèi)的內(nèi)存地址，則會(huì)引發(fā)訪問(wèn)違規(guī)異常：

虛擬地址空間分部

而使用ZwAllocateVirtualMemory函數(shù)可以在指定進(jìn)程的虛擬空間中申請(qǐng)一塊內(nèi)存，該塊內(nèi)存默認(rèn)將以64kb大小對(duì)齊。將BaseAdress設(shè)置為0時(shí)，系統(tǒng)會(huì)尋找第一個(gè)未使用的內(nèi)存塊來(lái)分配，并不能在零頁(yè)內(nèi)存中分配空間。在AllocateType參數(shù)中有一個(gè)分配類型是MEM_TOP_DOWN,該類型表示內(nèi)存分配從上向下分配內(nèi)存。如果指定 BaseAddress為一個(gè)低地址，例如 1，同時(shí)指定分配內(nèi)存的大小大于這個(gè)值 ，例如8192（一個(gè)內(nèi)存頁(yè)），這樣分配成功后 地址范圍就是0xFFFFE001（-8191）到 1把0地址包含在內(nèi)了，此時(shí)再去嘗試向 NULL指針執(zhí)行的地址寫(xiě)數(shù)據(jù)，程序就不會(huì)異常了。通過(guò)這種方式我們發(fā)現(xiàn)在0地址分配內(nèi)存的同時(shí)，也會(huì)在高地址（內(nèi)核空間）分配內(nèi)存。詳細(xì)請(qǐng)參考[11]。

Bitmap GDI函數(shù)實(shí)現(xiàn)內(nèi)核任意地址讀/寫(xiě)

而利用最近幾年提出的通過(guò)修改Bitmap GDI函數(shù)關(guān)鍵對(duì)象的方式則可以將有限的任意地址寫(xiě)漏洞轉(zhuǎn)化為內(nèi)核任意地址讀/寫(xiě)。此技術(shù)關(guān)鍵在當(dāng)創(chuàng)建一個(gè)bitmap時(shí)，我們可以泄露出其在內(nèi)核中的地址。這一泄露在Windows10的v1607版本之后才被打上補(bǔ)丁。

當(dāng)創(chuàng)建一個(gè)bitmap時(shí)，一個(gè)結(jié)構(gòu)被附加到了進(jìn)程PEB的GdiSharedHandleTable成員中。GdiSharedHandleTable是一個(gè)GDICELL64結(jié)構(gòu)體數(shù)組的指針：

我們可以以下方式找到Bitmap的內(nèi)核地址：

使用WinDbg來(lái)驗(yàn)證整個(gè)過(guò)程：

l  首先用以下PowerShell腳本創(chuàng)建一個(gè)Bitmap對(duì)象，并打印內(nèi)核對(duì)象句柄，然后用工具找到這個(gè)的對(duì)象以便后面做對(duì)比

打印出Bitmap內(nèi)核對(duì)象句柄：

切換進(jìn)程：

獲取GdiSharedHandleTable地址：

獲取Bitmap 句柄地址：

可以看到地址fffff900`c1ca6000和上面圖片里用工具獲取的一致，Bitmap內(nèi)核地址有了，該怎么用呢？GDICELL結(jié)構(gòu)的 pKernelAddress 成員指向 BASEOBJECT 結(jié)構(gòu)，不過(guò)我們關(guān)心的是在這一頭部之后，有一個(gè)特定的結(jié)構(gòu)體，它的類型是由 wType 成員決定的：

位圖結(jié)構(gòu)：

pvScan0 成員就是我們需要利用的，因?yàn)镚etBitmapBits 和 SetBitmapBits 這兩個(gè)API能操作這個(gè)成員。GetBitmapBits 允許我們?cè)?pvScan0 地址上讀任意字節(jié)，SetBitmapBits 允許我們?cè)?pvScan0 地址上寫(xiě)任意字節(jié)。如果我們有一個(gè)漏洞(例如：CVE-2018-8120)可以修改一次內(nèi)核地址, 把 pvScan0 改成我們想要操作的內(nèi)核地址，這樣是不是就實(shí)現(xiàn)了可以重復(fù)利用的內(nèi)核任意讀寫(xiě)呢？

有了這些基礎(chǔ)知識(shí)，我們整理出使用該方法并配合某個(gè)任意地址寫(xiě)的漏洞來(lái)將GetBitmapBits / SetBitmapBits改造成可以實(shí)現(xiàn)任意地址讀寫(xiě)的利用函數(shù)，具體步驟：

l  創(chuàng)建2個(gè)位圖（Manager/Worker）

l  使用句柄查找GDICELL64，分別計(jì)算兩個(gè)位圖的pvScan0 地址

l  使用漏洞將 WorkerpvScan0 偏移量地址寫(xiě)入 Manager 的 pvScan0 值

l  使用 Manager 上的SetBitmapBits 來(lái)選擇地址

l  在 Worker 上使用GetBitmapBits/ SetBitmapBits來(lái)讀取/寫(xiě)入上一步設(shè)置的地址

整個(gè)利用操作流程如下：

利用Bitmap GDI實(shí)現(xiàn)CVE-2018-8120在Windows 7 x64環(huán)境下的漏洞利用

有了上述的所有基礎(chǔ)知識(shí)，我們來(lái)看看利用程序是如果使用該技術(shù)在Windows 7 64位環(huán)境下利用CVE-2018-8120實(shí)現(xiàn)提權(quán)攻擊的。

第一步，首先利用ZwAllocateVirtualMemory分配基地址位于零頁(yè)的內(nèi)存塊，以使零頁(yè)完成映射：

調(diào)用NtAllocateVirtualMemory函數(shù)成功在零地址上面分配了一塊空間：

第二步，創(chuàng)建創(chuàng)建2個(gè)位圖（Manager/Worker）對(duì)象，并使用CVE-2018-8120漏洞將 WorkerpvScan0偏移量地址寫(xiě)入Manager 的 pvScan0 值，創(chuàng)建內(nèi)核任意地址讀寫(xiě)能力，具體操作如下：

l  創(chuàng)建兩個(gè)bitmap對(duì)象

l  泄露出各自的內(nèi)核地址，得到mpv 和 wpv 兩個(gè)指針：

l  使用任意寫(xiě)來(lái)設(shè)置 mpv 去指向 wpv 的地址，實(shí)現(xiàn)可重用的內(nèi)核任意讀寫(xiě)

先要構(gòu)造環(huán)境讓函數(shù)運(yùn)行到下面拷貝數(shù)據(jù)的地方，還記得上面我們對(duì) NtUserSetImeInfoEx 函數(shù)漏洞原理的分析嗎？ NtUserSetImeInfoEx 函數(shù)從首節(jié)點(diǎn)開(kāi)始遍歷鍵盤(pán)布局對(duì)象鏈表，直到節(jié)點(diǎn)對(duì)象的pklNext成員指回到首節(jié)點(diǎn)對(duì)象為止。然后判斷每個(gè)被遍歷的節(jié)點(diǎn)對(duì)象的 hkl 成員是否與參數(shù) ime_info_ex 指向的源輸入法擴(kuò)展信息對(duì)象的 hkl 成員相等。為了觸發(fā)后面的拷貝操作，我們需要跳過(guò)這個(gè)循環(huán)

要跳過(guò)這個(gè)循環(huán)很簡(jiǎn)單，我們讓 pkl->hkl 和 NtUserSetImeInfoEx 函數(shù)的參數(shù)地址相等就行了。下面的代碼就是在零頁(yè)地址位置偽造了一個(gè)和 tagIMEINFOEX 結(jié)構(gòu)體 spklList 成員類型一樣的 tagKL 結(jié)構(gòu)體，然后把它的 hkl 字段設(shè)置為 wpv 的地址。后面我們把 wpv 的地址放在 NtUserSetImeInfoEx 函數(shù)的參數(shù) ime_info_ex 的第一個(gè)成員里面。這樣就不會(huì)進(jìn)入 while ( pkl->hkl != ime_info_ex ) 這個(gè)循環(huán)了：

然后再把 mpv 的地址放在零頁(yè)內(nèi)存地址偏移0x50 的地方，NtUserSetImeInfoEx 函數(shù)會(huì)把它的參數(shù)( IMEINFOEX 結(jié)構(gòu))拷貝到目標(biāo)鍵盤(pán)布局 tagKL 對(duì)象的 piiex 成員指向的輸入法信息對(duì)象緩沖區(qū)中。在win7 x64下面這個(gè)字段的偏移就是 0x50：

以下是調(diào)試時(shí)候獲取到的mpv 和 wpv 的值：

接著構(gòu)造漏洞利用環(huán)境，調(diào)用CreateWindowStation 函數(shù)創(chuàng)建一個(gè)窗口站，調(diào)用 SetProcessWindowStation 函數(shù)把窗口站和當(dāng)前進(jìn)程關(guān)聯(lián)起來(lái)，接著構(gòu)造一個(gè) tagIMEINFOEX 結(jié)構(gòu)，把 wpv 的地址放到它的 hkl 成員中，調(diào)用 NtUserSetImeInfoEx 后，NtUserSetImeInfoEx 函數(shù)就會(huì)把 wpv 的地址拷貝到 mpv 里面：

在調(diào)試器里面我們可以看到 已經(jīng)成功觸發(fā)了NtUserSetImeInfoEx 的漏洞：

當(dāng)NtUserSetImeInfoEx 執(zhí)行完后，我們的GDI內(nèi)核任意讀寫(xiě)的環(huán)境就已經(jīng)構(gòu)造好了：

注意：NtUserSetImeInfoEx觸發(fā)的拷貝數(shù)據(jù)長(zhǎng)度是不可控的，memmove(piiex, &ime_info_ex, 0x160ui64); 代碼里面可以看到是0x160的長(zhǎng)度，也就是sizeof(tagIMEINFOEX),我們要在這個(gè)地方修改Worker Bitmap的 pvScan0的地址，就會(huì)把 SURFACE 結(jié)構(gòu)里面的其它數(shù)據(jù)給覆蓋掉。后面調(diào)用Gdi32 的 GetBitmapBits/SetBitmapBits 這兩個(gè)函數(shù)就會(huì)不成功，因?yàn)檫@兩個(gè)函數(shù)操作pvScan0 的方式是和 SURFOBJ 結(jié)構(gòu)的 lDelta、iBitmapFormat、iType、fjBitmap 還有 SURFACE 結(jié)構(gòu)的 flags 字段相關(guān)的。關(guān)于該結(jié)構(gòu)的詳細(xì)信息可以參考[10]。

以下代碼是需要修復(fù)成員的對(duì)應(yīng)值：

最后一步，使用 Gdi32 的GetBitmapBits/SetBitmapBits API調(diào)用來(lái)讀寫(xiě)內(nèi)核地址空間，實(shí)現(xiàn)任意代碼執(zhí)行：

下面的代碼實(shí)現(xiàn)了替換HalDispatchTable 里面的 NtQueryIntervalProfile 函數(shù)為我們的提權(quán)ShellCode的地址，調(diào)用NtQueryIntervalProfile 以達(dá)到執(zhí)行ShellCode的目的：

最終在ShellCode中替換SYSTEM進(jìn)程的token為當(dāng)前進(jìn)程的token，以實(shí)現(xiàn)提權(quán)：

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。