使用Windows內核提權0Day漏洞的實例分析

本篇文章為大家展示了使用Windows內核提權0Day漏洞的實例分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

01 背景

2020年12月中旬，安恒威脅情報中心獵影實驗室發布了《蔓靈花（BITTER）組織近期針對我國政府部門、科研機構發起攻擊》，文中已經給出并分析了該組織攻擊的一些組件。

在后續的跟進分析中我們又發現了一個全新的組件，經過分析，我們發現該組件利用了一個未知的Windows內核提權漏洞，且利用代碼適配了Windows10 1909操作系統。我們隨即將相關信息報送給微軟，經過微軟的確認，我們確信這是一個win32kfull模塊的0Day漏洞，在最新版本的Windows10 20H2全補丁環境下也能觸發！

02 事件時間軸

●2020年12月10日，安恒威脅情報中心捕獲到相關樣本

●2020年12月15日，安恒威脅情報中心在分析過程中發現一個可疑的Windows內核提權漏洞，并啟動根因調查

●2020年12月29日，安恒威脅情報中心將漏洞信息報告給MSRC

●2020年12月29日，MSRC確認收到漏洞報告

●2020年12月31日，MSRC確認該漏洞是一個0Day，并開始調查，同時要求提供更多細節

●2020年12月31日，安恒威脅情報中心向MSRC提供該0Day漏洞的更多細節

●2021年1月6日，MSRC就安恒威脅情報中心提供的更多細節表示感謝，并表示漏洞已在修復中

●2021年2月9日，MSRC修復該漏洞，漏洞編號為CVE-2021-1732

03 漏洞特點

根據我們的調查分析，本次捕獲的0Day漏洞具有以下特點：

（1）攻擊目標為最新版Windows 10操作系統

(a)在野樣本攻擊的是當時最新版Windows10 1909 64位操作系統（在野樣本的編譯時間為2020年5月）；

(b)在野樣本適配了從Windows10 1709到Windows10 1909多個版本，且只會在Windows10 1709及以上版本中運行利用代碼；

(c)原始利用代碼經過少量修改后可在最新版Windows10 20H2 64位全補丁環境進行提權。

（2）漏洞質量高，利用手法精湛，穩定性好，動態檢測難度大

(a)在野樣本借助漏洞繞過了最新版Windows 10系統的內核地址空間布局隨機化（KASLR）；

(b)本次漏洞不同于以往的Win32k漏洞，漏洞類型不是UAF，整個利用過程不涉及堆噴射和內存重用，Type Isolation緩解機制對其無效。在野樣本在打開Driver Verifier驗證器的情況下依然可以正常提權，無法通過開啟內核池追蹤檢測到，動態檢測難度大；

(c)在野樣本的任意地址寫入采用了漏洞特性結合SetWindowLong系列函數的手法，令人眼前一亮；

(d)在野樣本借助GetMenuBarInfo實現任意地址讀取，這種手法此前未被公開過，這體現出開發者精湛的利用編寫水平；

(e)在野樣本在構造出任意地址讀寫原語后，采用Data Only Attack的方式替換了當前進程的Token，目前的內核緩解機制無法防御此類攻擊；

(f)在野樣本的漏洞利用成功率幾乎為100%；

(g)在野樣本在完成利用后，將相關內核結構全部還原，整個過程不會對系統造成藍屏影響，工作穩定。

（3）使用謹慎，隱蔽性好

(a)在野樣本在進行漏洞利用前對特定殺毒軟件進行了檢測；

(b)在野樣本對當前操作系統版本進行了判斷，低于Windows 10 1709版本的系統不會調用漏洞利用函數；

(c)在野樣本從2020年5月完成編譯，到2020年12月被我們發現，中間至少存活了7個月，這說明使用者在使用該漏洞時相當謹慎，間接體現出捕獲此類隱蔽性樣本的難度。

04 漏洞觸發效果

在最新版Windows10 1909 x64環境中對在野0Day樣本進行測試，可以看到該進程在初始啟動時為Medium權限，

當漏洞利用代碼執行后，當前進程變為System權限，這表明當前進程的Token已經被替換為System進程的Token，這是內核提權漏洞利用的常見手法。

在最新的Windows10 20H2全補丁環境下啟動該樣本，則會導致系統藍屏。這是因為該利用代碼被編譯時，Windows10 2004和Windows10 20H2還未發布，攻擊者只將利用代碼適配到當時最新的Windows10 1909版本。

05 技術分析

0x01漏洞成因

該漏洞是win32kfull!xxxCreateWindowEx函數內，一處由用戶態回調導致的flag位設置與對應offset設置不同步導致的漏洞。

win32kfull.sys模塊的xxxCreateWindowEx函數在創建帶窗口擴展內存的窗口時，會調用xxxClientAllocWindowClassExtraBytes用戶態回調函數，返回用戶態創建窗口擴展內存。攻擊者可在回調函數內調用NtUserConsoleControl并傳入當前窗口的句柄，將當前窗口內核結構中的一個成員(用于指明窗口擴展內存的區域)修改為offset，并修改相應的flag，指明該成員是一個offset。隨后，攻擊者可在回調函數中調用NtCallbackReturn返回任意值，回調結束后，該返回值會覆寫之前的offset，但對應的flag并未被清除，隨后未經校驗的offset直接被內核代碼用于堆內存尋址，引發越界訪問。

0x02漏洞觸發邏輯

我們完全逆向了在野樣本的漏洞利用代碼，在此基礎上構造了該漏洞的poc，下圖是poc的主要執行邏輯，我們將結合此圖對漏洞觸發邏輯進行解釋：

在win32kfull!xxxCreateWindowEx 函數中，

窗口擴展內存默認會使用xxxClientAllocWindowClassExtraBytes 函數回調用戶態函數，該回調函數的返回值是一個指針，返回的是從用戶態創建的內存，這個值會被保存到內核結構中。

當我們在自定義的xxxClientAllocWindowClassExtraBytes回調函數中調用 win32kfull!xxxConsoleControl 函數后,窗口擴展內存的flag會被置位(|=0x800)，并將保存在內核地址的用戶態地址修改成一個offset，以便使用內核的堆管理器管理。

在poc中，我們選擇在銷毀窗口時觸發漏洞， win32kfull!xxxFreeWindow 函數會判斷上述flag是否被設置，若被設置，則代表對應的內核結構中存儲的是offset，調用RtlFreeHeap函數釋放相應的內存；若未被設置，則代表對應的內核結構中存儲的是內存地址，調用xxxClientFreeWindowClassExtraBytes借助用戶態回調函數進行釋放。

在xxxClientAllocWindowClassExtraBytes回調函數內，可以借助NtCallbackReturn控制返回值，回調結束后，會用返回值覆寫之前的offset，但并未清除相應的flag。在poc中，我們返回了一個用戶態堆地址，從而將原來的offset覆寫為一個用戶態堆地址(fake_offset)。這最終導致win32kfull!xxxFreeWindow在用RtlFreeHeap釋放內核堆時出現了越界訪問。

RtlFreeHeap所期望的釋放地址是RtlHeapBase+offset

RtlFreeHeap實際釋放的地址是RtlHeapBase+fake_offset

只要調用此處的RtlFreeHeap，就會導致越界釋放，從而導致BSOD。

0x03在野利用

在野樣本是一個64位的程序，它首先調用CreateToolhelp32Snapshot等函數遍歷所有進程，查找“avp.exe”進程（“avp.exe”是卡巴斯反病毒軟件進程）。

在野樣本在檢測“avp.exe”進程后，只會對一些自定義結構進行賦值，并不會退出進程，后續的提權函數仍會被調用。我們在裝有卡巴斯基反病毒軟件的環境中進行了實驗，在野樣本可以正常提權，如下圖所示。

隨后，在野樣本調用IsWow64Process以判斷當前所運行的環境，并依據結果對一些偏移進行修正。這里代碼編寫者似乎在邏輯判斷時存在一些問題，按照下面的源碼示意，下圖中的g_x64應理解為g_x86，但后續的調用表明此變量代表x64環境。

代碼編寫者在初始化時強制給g_x64賦值為TRUE，所以此處對IsWow64Process的調用可以忽略，不過這似乎暗示開發者還寫了另一個32位版本的提權組件。

在修正偏移后，在野樣本動態獲取了RtlGetNtVersionNumbers，NtUserConsoleControl和NtCallbackReturn三個函數。隨后調用RtlGetNtVersionNumbers函數獲取當前系統版本號，檢查當前系統版本號是否大于等于16353（Windows10 1709），只有大于該版本號時，漏洞利用代碼才會被調用，接著又判斷當前系統版本號是否大于等于18204（Windows10 1903），如果大于，則修正一些內核結構的偏移，便于后面的利用。

校驗通過后，在野樣本開始調用利用代碼，它首先動態搜索得到HmValidateHandle函數的地址，并hook USER32!_xxxClientAllocWindowClassExtraBytes回調函數。

利用代碼隨后注冊了兩種窗口類，其中一種用于創建漏洞窗口，類名為“magicClass”，另一種窗口類名為“normalClass”，用于創建一般窗口，用以輔助后續的任意地址寫入。

接著，利用代碼借助normalClass創建10個窗口，調用HmValidateHandle函數泄露這些窗口的用戶態tagWND結構體地址，并泄露結構體內的offset偏移，隨后銷毀第3-10個窗口，只保留窗口0和窗口1。

如果當前環境為64位，則調用NtUserConsoleControl將窗口0對應的flag從pointer改為offset，這樣，窗口0的內核tagWND結構尋址方式變為offset，而窗口1的尋址方式仍為pointer。

隨后，利用代碼借助magicClass創建一個帶特定長度窗口擴展內存的窗口2，在窗口2創建過程中觸發xxxClientAllocWindowClassExtraBytes回調,進入自定義回調函數，在自定義函數中，首先判斷當前窗口擴展內存長度是否為特定長度，隨后判斷當前環境是否為x64，校驗通過后，調用NtUserConsoleControl將窗口2的的內核tagWND結構尋址方式變為offset；隨后調用NtCallbackReturn將窗口2的窗口擴展內存對應的offset改為窗口0的tagWND對應的offset，這導致后續對窗口2的窗口擴展內存的讀寫都變為了對窗口0的tagWND結構的讀寫，到這里已經成功使用漏洞。

回調結束后，利用代碼已經可以借助SetWindowLongW對窗口0的內核tagWND成員進行修改。

利用代碼首先調用SetWindowLongW將窗口0的cbWndExtra設置為0xFFFFFFF，從而使窗口0具備越界寫入能力。隨后借助窗口0令窗口1的dwStyle|=WS_CHILD，隨后用fake_spmenu替換窗口1原有的spmenu，在fake_spmenu的基礎上實現任意地址讀寫原語。

利用代碼的任意地址讀原語借助fake_spmenu，

配合GetMenuBarInfo讀取tagMenuBarInfo.rcBar.left和tagMenuBarInfo.rcBar.top兩個成員進行實現，這種方式此前未被公開使用過，但和2016年ZeroNight的《LPE vulnerabilities exploitation on Windows 10 Anniversary Update》中提到的思路類似。

利用代碼的任意地址寫原語借助窗口0和窗口1，配合SetWindowLongPtrA進行封裝，具體實現如下。

構造出任意地址讀寫原語后，利用代碼從窗口1的原始spmenu結構中泄露出一個內核地址，借助該地址逐步定位到當前進程的EPROCESS，隨后遍歷進程鏈，找到System進程的Token指針和當前進程EPROCESS結構內存儲Token的地址，并將當前進程的Token改寫System進程的Token，實現權限提升。

完成提權后，利用代碼借助任意地址寫入原語將之前被修改的窗口0，窗口1，窗口2成員進行還原，例如原始的spmenu和導致漏洞的flag，以確保利用完成后不會產生藍屏異常。整個漏洞利用過程非常穩定。

0x04 結論

該漏洞是win32k子系統內一個通過CallBack回調機制引發的漏洞，該漏洞可以被用作IE、Adobe Reader等沙箱環境的逃逸。該漏洞質量較高，在野樣本利用手法高超，威脅組織可能招募了具有一定實力的成員，也不排除從專業的漏洞中間商處購買，該在野樣本的使用體現出背后APT組織較強的0day漏洞儲備能力。

06 總結思考

0Day在網絡空間隱蔽戰場上具有舉足輕重的作用，0Day通常作為攻擊組織的戰略儲備，具有特殊使命和戰略意義。為了充分合理發揮其價值，一般只會在針對極特殊的目標條件下才會使用。

隨著軟硬件不斷的成熟和防御體系的提升，一些重點軟硬件、系統的0Day挖掘成本和利用成本已經變得非常高，使用條件變得更為苛刻，再譬如多年來各廠商對APT攻擊檢測的投入和能力加強，使得APT組織對0Day的使用變得更加謹慎，稍有不慎就會使得0Day的的價值生命周期縮水。

0Day仍是“核武器”，發現并不一定等于檢出，而是有可能在其它蛛絲馬跡中窺見的端倪。最直接的例子就是永恒之藍所利用的遠程代碼漏洞，在被曝光前已經潛伏了許久。

對0Day或其它隱蔽攻擊的檢測能力提升仍是APT對抗過程中需要持續精進、不斷提高、必不可少的重要環節。

0Day的產生不會停止，使用漏洞進行的攻擊不會停止。在去年（2020年）就曝光了多起涉及在野0Day/1Day漏洞的攻擊行動，僅安恒威脅情報中心追蹤到的就有3起，除此之外，全球至少還披露了十余起在野漏洞利用事件。并從披露漏洞的趨勢來看，瀏覽器、沙箱逃逸、提權漏洞將會進一步增加。

除了端上的攻擊利用之外，邊界系統、臨界設備、集控系統也是需要關注的點。去年就有多起此類安全事件的發生。其中更需要注意的是起到安全防護的邊界系統，更需要關注、加強和保障自身質量。

未被發現并不表示不存在，可能更多的是處于潛伏狀態。在高級威脅、隱蔽攻擊、0Day攻擊的發現、檢測與防御上，需要在博弈過程中不斷迭代強化。需要積極思考在各環節、各區塊、各點位上對防御體系、防御能力、防御方位上的把握。網絡安全任重而道遠，共勉之。

07 自查方案

這次Bitter APT組織攻擊的樣本默認會存在如下目錄：

c:\intel\logs

如自查的時候，發現存在相關目錄或文件，用戶可以提交樣本到安恒威脅情報中心平臺進行檢測，平臺地址：

https://ti.dbappsecurity.com.cn/

也可聯系我們處理

聯系方式：400 6059 110

如果客戶有購買安恒APT攻擊預警平臺，可以直接上傳進行檢測。

攻擊者使用0day進行攻擊是為了提權，一般是為了獲取更多、更高的權限，比如為了內網橫向滲透做準備。如果發現同時還存在某國外VPN程序，不排除該單位的內網存在被橫向滲透的風險。

08 防御建議

升級安恒APT攻擊預警平臺以及明御主機安全及管理系統EDR到最新版本可進行檢測。

請確認是最新版本:

1、APT攻擊預警平臺版本大于等于V2.0.66.23509.210119

2、EDR版本大于等于v2.0.15.34

安恒APT攻擊預警平臺能夠發現已知或未知威脅，平臺能實時監控、捕獲和分析惡意文件或程序的威脅性，并能夠對郵件投遞、漏洞利用、安裝植入、回連控制等各個階段關聯的木馬等惡意樣本進行強有力的監測。同時，平臺根據雙向流量分析、智能的機器學習、高效的沙箱動態分析、豐富的特征庫、全面的檢測策略、海量的威脅情報等，對網絡流量進行深度分析。檢測能力完整覆蓋整個APT攻擊鏈，有效發現APT攻擊、未知威脅及用戶關心的網絡安全事件。

安恒明御主機安全及管理系統是一款集成了豐富的系統加固與防護、網絡加固與防護等功能的主機安全產品。業界獨有的高級威脅模塊，專門應對攻防對抗場景； 明御主機安全及管理系統通過自主研發的專利級文件誘餌引擎，有著業界領先的勒索專防專殺能力；通過內核級東西向流量隔離技術，實現網絡隔離與防護；擁有補丁修復、外設管控、文件審計、違規外聯檢測與阻斷等主機安全能力。目前產品廣泛應用在服務器、桌面PC、虛擬機、工控系統、容器安全、攻防對抗等各個場景。

09 檢測策略

YARA

rule apt_bitter_win32k_0day {

meta:

author = "dbappsecurity_lieying_lab"

data = "2021-01-01"

strings:

$s1 ="NtUserConsoleControl" ascii wide

$s2 = "NtCallbackReturn" ascii wide

$s3 ="CreateWindowEx"ascii wide

$s4 ="SetWindowLong"ascii wide 

$a1 ={48 C1 E8 02 48 C1 E9 02 C7 04 8A }

$a2 ={66 0F 1F 44 00 00 80 3C 01 E8 74 22 FF C2 48 FF C1}

$a3 = {48 63 05 CC 69 05 00 8B 0D C2 69 05 00 48 C1 E0 20 48 03 C1}

condition:

uint16(0) == 0x5a4d and all of ($s*) and 1 of ($a*)

}

上述內容就是使用Windows內核提權0Day漏洞的實例分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。