[[183613]]

前言

Windows內(nèi)核漏洞的利用具有高風(fēng)險，經(jīng)常用于瀏覽器沙箱逃逸。許多年以來,發(fā)現(xiàn)的大多數(shù)漏洞都是來源于Win32k.sys驅(qū)動，它負(fù)責(zé)處理來自GDI32.DLL和user32.dll的調(diào)用。為了緩解這些漏洞,微軟在window10上實現(xiàn)了Win32系統(tǒng)調(diào)用過濾.總體思路是在進(jìn)程入口處嘗試阻止大量的發(fā)往win32.sys的系統(tǒng)調(diào)用,以便阻止未知的漏洞利用。我沒有找到實現(xiàn)的相關(guān)細(xì)節(jié),也不確定效果如何。我發(fā)現(xiàn)的唯一資料就是由Peter Hlavaty發(fā)表在 Rainbow Over the Windows的相關(guān)文章。

系統(tǒng)調(diào)用101

我理解過濾技術(shù)的第一個方法就是研究系統(tǒng)調(diào)用是如何執(zhí)行。分析是基于Windows 10周年更新的64位版本。通常,系統(tǒng)調(diào)用在gdi32.dll或者user32.dll的函數(shù)中被初始化,最終會在win32u.dll中調(diào)用真實的系統(tǒng)調(diào)用。但是，我們可以直接使用匯編來顯示系統(tǒng)調(diào)用，在以下的POC中,我查詢到系統(tǒng)調(diào)用號為0x119E的WIN32K函數(shù)是NtGdiDdDDICreateAllocation。所以我簡單地創(chuàng)建下面的測試應(yīng)用程序：

下圖是NtGdiDdDDICreateAllocation的匯編代碼：

當(dāng)運行syscall指令后,將轉(zhuǎn)入內(nèi)核模式執(zhí)行.真實的系統(tǒng)調(diào)用位于NT!KiSystemStartService。但是，由于有大量的系統(tǒng)調(diào)用，所以我們需要在調(diào)試器中設(shè)置一個條件斷點：

運行POC并開啟斷點

首先顯示的系統(tǒng)調(diào)用號就是我們提供的0x119E，其實參數(shù)1,2,3,4保存在寄存器RCX，RDX，R8和R9中。在IDA中查看相關(guān)代碼：

查閱代碼,我們發(fā)現(xiàn)一個有趣的問題:RBX寄存器的內(nèi)容是什么,這又是從何而來。嘗試引用KiSystemServiceStart,我們發(fā)現(xiàn) RBX在以下函數(shù)中被設(shè)置：

MOV RBX GS：188將Win32SyscallFilter.exe的內(nèi)核線程結(jié)構(gòu)載入RBX中，驗證如下：

研究算法

接下來的問題是RBX + 0x78代表什么，事實證明，它代表一系列的標(biāo)志位。下圖引用的兩個標(biāo)志是GuiThread和RestrictedGuiThread，它們分別位于標(biāo)志的第6位和和19位。

在我們的例子中，標(biāo)志位的值如下：

由于線程不是一個GUI線程，所以會重定向的將它轉(zhuǎn)換成一個GUI線程，然后返回相同的指針。繼續(xù)執(zhí)行會發(fā)生：

Win32kSyscallFilter并沒有做任何事。但是接下來的檢查很有趣。RestrictedGuiThread標(biāo)志指明,如果啟用系統(tǒng)調(diào)用過濾，會在進(jìn)程級別上進(jìn)行檢測：

因此，對于當(dāng)前的進(jìn)程和線程,系統(tǒng)調(diào)用過濾沒有啟用。查看進(jìn)一步執(zhí)行,將體現(xiàn)出這個標(biāo)志位的重要性：

如果開啟了系統(tǒng)調(diào)用過濾功能,KeServiceDescriptorTableFilter將取代KeServiceDescriptorTableShadow，如果沒有開啟過濾,則將使用KeServiceDescriptorTableShadow。接下來要觀察系統(tǒng)調(diào)用表的使用，如下圖所示：

在經(jīng)過運算后,RDI包含系統(tǒng)調(diào)用數(shù)目。在WIN32K系統(tǒng)的情況下,它的值是0x20。所以，取決于系統(tǒng)調(diào)用過濾是否開啟,不同的表會被載入R10.這兩個選項是：

然后該表將轉(zhuǎn)入真實的函數(shù)調(diào)用：

跟隨以上的算法，我們在調(diào)試器中找到：

所以這很顯然,系統(tǒng)調(diào)用號通過負(fù)偏移指向W32pServiceTable結(jié)構(gòu)，然后指向真實的NtGdiDdDDICreateAllocation函數(shù)。這是非常好的，但是如果開啟了系統(tǒng)調(diào)用過濾,會有什么區(qū)別呢，這可以使用W32pServiceTableFilter來進(jìn)行驗證：

我們看到在此之前并沒有什么區(qū)別,這是因為NtGdiDdDDiCreateAllocation并不是過濾的API之一，如果我們選擇其他的系統(tǒng)調(diào)用,比如NtGdiDdDDiCreateAllocation,它的系統(tǒng)調(diào)用號是0x117E。我們基于是否啟用系統(tǒng)調(diào)用過濾來對比以下兩個輸出。

首先是未啟用系統(tǒng)調(diào)用過濾的：

然后是啟用系統(tǒng)調(diào)用過濾：

我們發(fā)現(xiàn)，如果開啟了系統(tǒng)調(diào)用過濾功能，系統(tǒng)調(diào)用是不允許的另一個函數(shù)被調(diào)用的。該過濾函數(shù)驗證是否啟用系統(tǒng)調(diào)用過濾并簡單的結(jié)束系統(tǒng)調(diào)用。

利用的結(jié)果

現(xiàn)在我們了解了系統(tǒng)調(diào)用過濾是如何工作的，我們需要研究它是如何防止內(nèi)核漏洞利用的。首先要看看它保護(hù)的是什么進(jìn)程，到目前為止，僅僅是微軟Edge可以啟用這個功能，目前第三方程序沒有可以啟用它的接口。這意味著系統(tǒng)調(diào)用過濾僅僅關(guān)心Microsoft Edge漏洞并且僅限于內(nèi)核漏洞。下面我們可以看到MicrosoftEdgeCP.exe的進(jìn)程結(jié)構(gòu)，并啟用了系統(tǒng)調(diào)用過濾：

回顧我早期文章，關(guān)于重新啟用tagWND對象作為讀寫原語的用法的，我想知道是否使用這個方法的任意系統(tǒng)調(diào)用都會被過濾，在那個方法中使用的內(nèi)核模式的函數(shù)是：

NtUserCreateWindowEx 
NtUserDestroyWindow 
NtUserSetWindowLongPtr 
NtUserDefSetText 
NtUserInternalGetWindowText 
NtUserMessageCall 

在win32k.sys中沒有stub_*方法的函數(shù)意味著不會被過濾。結(jié)論就是Win32K系統(tǒng)調(diào)用過濾不會阻止可能導(dǎo)致漏洞的系統(tǒng)調(diào)用，但是當(dāng)系統(tǒng)調(diào)用觸發(fā)一個漏洞時,它一定會阻止，可能是write-that-wherer或者是一個緩沖區(qū)溢出。WIN32K系統(tǒng)調(diào)用過濾所提供的保護(hù)是巧妙的，但關(guān)鍵在于是否使用了系統(tǒng)調(diào)用來觸發(fā)漏洞。