WOW64利用技術(shù)原理分析

原創(chuàng)?CNTIC情報組?國家網(wǎng)絡(luò)威脅情報共享開放平臺?2020-11-26 12:35?發(fā)表于北京近來，黑客利用10多年前的“老”技術(shù)—“天堂之門”躲避監(jiān)測的情況引起了眾多安全研究人員的關(guān)注。為此，火眼公司專門發(fā)表了“WoW64 subsystem internals and hooking techniques”[1]一文（以下簡稱為“火文”），對“天堂這門”以及其它WOW64利用技術(shù)進行了詳細介紹，國內(nèi)相關(guān)公眾號也對該文進行了翻譯和轉(zhuǎn)載[2]。因為WOW64是系統(tǒng)級的模擬器，理解和掌握WOW64利用技術(shù)需要許多系統(tǒng)底層的知識。這里，我們對“天堂之門”以及另一項WOW64利用技術(shù)—wow64log.dll劫持技術(shù)的原理作一點粗淺的分析，以方便大家了解相關(guān)技術(shù)。

?1背景

WOW64是Microsoft為了向后兼容，而在64位Windows系統(tǒng)上推出的一套32位系統(tǒng)的模擬器，它使得32位程序在64位系統(tǒng)上運行成為可能。

自WOW64推出以來，對其安全性的研究就一直在持續(xù)，并先后發(fā)掘出了多項利用技術(shù)，其中比較有代表性的有“天堂之門”和wow64log.dll劫持。

“天堂之門”(Heaven’s Gate)是最著名的WOW64利用技術(shù)。早在2006年，該項技術(shù)就已經(jīng)出現(xiàn)在烏克蘭的一家黑客技術(shù)交流網(wǎng)站VxHeaven（Vx意為Virus eXechange）上（注：因該網(wǎng)站已于2012年被烏克蘭警方查封，未見到原始素材）。正如其名字所言，“天堂之門”的利用點發(fā)生在32位模式與64位模式的交界—調(diào)用門（Gate）處。時至今日，“天堂之門”仍被當作規(guī)避安全防護的一種有效技術(shù)，為許多黑客組織所利用，并不時出現(xiàn)在安全研究人員的視野中。

Wow64log.dll劫持是近幾年研究發(fā)掘的另一項WOW64利用技術(shù)。它是通過編寫和劫持wow64log.dll，實現(xiàn)對WOW64進程的注入。

?2?WoW64子系統(tǒng)

2.1 保護模式下的操作系統(tǒng)

我們知道，CPU在發(fā)展到80386以后，引入了保護模式的概念。在保護模式下，程序代碼的運行狀態(tài)可以有ring0~ring3四個特權(quán)級。相應(yīng)地，Windows系統(tǒng)也將程序代碼的運行狀態(tài)分成了2個特權(quán)等級：ring0和ring3。操作系統(tǒng)內(nèi)核工作在ring0（內(nèi)核態(tài)）下；用戶程序，以及操作系統(tǒng)的其它部分，則工作在ring3（用戶態(tài)）下。一個典型的Windows系統(tǒng)，其結(jié)構(gòu)如以下：

在劃分特權(quán)級的情況下，用戶程序只能經(jīng)由操作系統(tǒng)的接口部分（ntdll.dll），以syscall或int 2e的方式通過門（調(diào)用門或中斷門），才能實現(xiàn)對內(nèi)核態(tài)代碼的調(diào)用，這樣就實現(xiàn)了對操作系統(tǒng)內(nèi)核的保護。

比如，一個64位系統(tǒng)上的64位進程，其轉(zhuǎn)入內(nèi)核態(tài)的代碼如下：

但是，由于32位代碼和64位代碼間的差異，對于32位程序以及相應(yīng)的32位Ntdll.dll來說，它不能以syscall或int 2e的方式直接調(diào)用64位內(nèi)核態(tài)代碼。為了32位程序在64位內(nèi)核下也能正常運行，就出現(xiàn)了WOW64子系統(tǒng)。

2.2 WOW64

WOW64子系統(tǒng)，官方的叫法是WOW64模擬器。微軟官網(wǎng)[3]對其描述為：“WOW64模擬器運行于用戶模式，它提供了32位版本Ntdll.dll與處理器內(nèi)核之間的一個接口，并對內(nèi)核調(diào)用進行攔截。”

WOW64支持X64和ARM64兩種架構(gòu)，主要包括以下模塊：

• ? Wow64.dll提供核心模擬架構(gòu)以及Ntoskrnl.exe入口函數(shù)的thunk

• ? Wow64win.dll提供win32k.sys入口函數(shù)的thunk

• （僅X64）Wow64cpu.dll為X86程序在X64上運行提供支持

• （僅Itanium）IA32Exec.bin包含X86軟件模擬器

• （僅Itanium）Wowia32x.dll提供IA32Exec.bin與WOW64間的接口

• （僅ARM64）xtajit.dll包含X86軟件模擬器

• （僅ARM64）Wowarmw.dll為ARM32程序在ARM64上運行提供支持

64位Windows系統(tǒng)增添了WOW64后，就變成了如下架構(gòu)：

從這個圖可以看出：32位進程要轉(zhuǎn)入64位內(nèi)核態(tài)，首先要由WOW64子系統(tǒng)將32位Ntdll.dll的API調(diào)用轉(zhuǎn)換為64位Ntdll.dll的API調(diào)用，再由64位Ntdll.dll的API調(diào)用，以syscall或int 2e的方式轉(zhuǎn)入內(nèi)核態(tài)。

關(guān)于WOW64的實現(xiàn)細節(jié)，微軟的描述簡短且隱晦：

• “啟動時，Wow64.dll載入X86版的Ntdll.dll并運行其初始化代碼，初始化代碼將載入所有必需的32位dll”

• “執(zhí)行系統(tǒng)調(diào)用的32位代碼不是使用X86的系統(tǒng)服務(wù)調(diào)用序列，而是被改造為使用一種特定的調(diào)用序列。該調(diào)用序列將被WOW64攔截，并由WOW64CPU轉(zhuǎn)換為64位調(diào)用“

• “thunk從32位棧中提取參數(shù)，將參數(shù)擴展位64位，?然后執(zhí)行64位系統(tǒng)調(diào)用“

?3?WOW64利用技術(shù)

現(xiàn)有的WOW64利用技術(shù)，主要就是圍繞微軟的以上描述展開。

3.1?“天堂之門”

“天堂之門”圍繞的主要問題是：32位代碼調(diào)用系統(tǒng)服務(wù)時的特定調(diào)用序列到底是什么，轉(zhuǎn)入64位系統(tǒng)是如何達成的。

這個在火文和其它文章中都有較詳細的介紹，簡單來說（以NtResumeThread為例）就是：

• （特定調(diào)用序列）NtResumeThread調(diào)用Wow64SystemService

• （至64位模式的轉(zhuǎn)換函數(shù)Thunk）Wow64SystemService調(diào)用Wow64Transition

• （從32位模式轉(zhuǎn)移至64位模式）Wow64Transition指向wow64cpu!KiFastSystemCall，后者通過遠跳轉(zhuǎn)(far jmp)實現(xiàn)X86到X64的轉(zhuǎn)移

從這里可以看出：實現(xiàn)X86到X64轉(zhuǎn)換的關(guān)鍵就是遠跳轉(zhuǎn)，即形如jmp cs:eip的跳轉(zhuǎn)。其中，CS為段選擇子：

• 當cs=0x33時，對應(yīng)64位模式

• 當cs=0x23時，對應(yīng)32位模式

“天堂之門”就是利用far jmp，或者等價的Call、retf，不通過32位ntdll.dll，直接實現(xiàn)對64位系統(tǒng)服務(wù)的調(diào)用。因為實現(xiàn)技術(shù)上的原因，許多防護軟件都是通過注入32位ntdll.dll來對程序的運行行為進行監(jiān)控，由于“天堂之門”不調(diào)用322位ntdll.dll中的API函數(shù)，這樣就達到了躲避監(jiān)控的目的。

以下是(ReWolf) [4]A PoC heaven’s gate implementation中的一個POC：

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

#define EM(a) __asm __emit (a)
#define X64_Start_with_CS(_cs) { ?EM(0x6A) EM(_cs) ? ? ? ? ? ? ? ? ? ? ?/* ?push ? _cs ? ? ? ? ? ? ? ? ? */ ?EM(0xE8) EM(0) EM(0) EM(0) EM(0) ? ? ? /* ?call ? $+5 ? ? ? ? ? ? ? ? ? */ ?EM(0x83) EM(4) EM(0x24) EM(5) ? ? ? ? ?/* ?add ? ?dword [esp], 5 ? ? ? ?*/ ?EM(0xCB) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* ?retf ? ? ? ? ? ? ? ? ? ? ? ? */ }
#define X64_End_with_CS(_cs) \{ \ ?EM(0xE8) EM(0) EM(0) EM(0) EM(0) ? ? ? /* ?call ? $+5 ? ? ? ? ? ? ? ? ? */ ?EM(0xC7) EM(0x44) EM(0x24) EM(4) ? ? ? /* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? */ ?EM(_cs) EM(0) EM(0) EM(0) ? ? ? ? ? ? ?/* ?mov ? ?dword [rsp + 4], _cs ?*/ ?EM(0x83) EM(4) EM(0x24) EM(0xD) ? ? ? /* ?add ? ?dword [rsp], 0xD ? ? ?*/ ?EM(0xCB) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ?retf ? ? ? ? ? ? ? ? ? ? ? ? */ }
#define X64_Start() X64_Start_with_CS(0x33)#define X64_End() X64_End_with_CS(0x23)
3.2 WOW64log.dll劫持

Wow64log.dll圍繞的是另一個問題：WOW64的初始化過程執(zhí)行了哪些操作，期間有沒有可以利用的地方。

對于該問題最詳細的解答，可以參考火文提供的另一鏈接(wbenny)[5]：An extremely detailed view of WOW64 internals on ARM。

透過Wbenny的這篇文章，可以知道：在WOW64初始化過程中，會載入wow64log.dll，而且該dll會被每個WOW64進程裝載。但在發(fā)布的Windows系統(tǒng)中，該dll并不存在（疑為開發(fā)過程中使用）。

這樣，通過編寫該dll并放入適當位置，就可以實現(xiàn)對所有WOW64進程的注入。

?4?參考鏈接

[1]https://www.fireeye.com/blog/threat-research/2020/11/wow64-subsystem-internals-and-hooking-techniques.html

[2]https://www.anquanke.com/post/id/222243[3]https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details[4]http://blog.rewolf.pl/blog/?p=102[5]https://wbenny.github.io/2018/11/04/wow64-internals.html