2018年3月末,ESET研究人員發現了一款非常有趣的惡意PDF樣本。經過仔細研究后,我們發現該樣本利用了之前未知的兩個漏洞:Adobe Reader中的一個遠程命令執行漏洞以及Microsoft Windows中的一個權限提升漏洞。
這兩個漏洞組合起來威力巨大,攻擊者可以通過這種方式在存在漏洞的目標上以盡可能高的權限來運行任意代碼,并且整個過程很少需要用戶交互。APT組織通常會使用這種組合拳來發起攻擊,比如去年的Sednit攻擊活動就是非常好的一個例子。
在發現這款PDF樣本后,ESET第一時間聯系了微軟安全響應中心(MSRC)、Windows Defender ATP研究團隊以及Adobe Product安全事件響應團隊,并與這些單位一起協作,直至漏洞被成功修復。
Adobe以及微軟也提供了相應補丁及安全公告,分別如下:
受影響的相關產品版本信息如下:
Acrobat DC (2018.011.20038及更早版本)
Acrobat Reader DC (2018.011.20038及更早版本)
Acrobat 2017 (011.30079及更早版本)
Acrobat Reader DC 2017 (2017.011.30079及更早版本)
Acrobat DC (Classic 2015) (2015.006.30417及更早版本)
Acrobat Reader DC (Classic 2015) (2015.006.30417及更早版本)
Windows 7 for 32-bit Systems Service Pack 1
Windows 7 for x64-based Systems Service Pack 1
Windows Server 2008 for 32-bit Systems Service Pack 2
Windows Server 2008 for Itanium-Based Systems Service Pack 2
Windows Server 2008 for x64-based Systems Service Pack 2
Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1
Windows Server 2008 R2 for x64-based Systems Service Pack 1
本文介紹了這款惡意樣本以及所利用漏洞的技術細節。
PDF(Portable Document Format)是一種電子文檔文件格式,與其他常見文檔格式一樣,攻擊者可以利用該類型文件將惡意軟件傳播至受害者主機。為了執行惡意代碼,攻擊者需要尋找并利用PDF閱讀器軟件中的漏洞。現在有多款PDF閱讀器,其中最常用的就是Adobe Reader。
Adobe Reader軟件中有一個安全功能:沙箱(sandbox),也稱為保護模式(Protected Mode)。Adobe在官方博客上分四部分(Part 1、Part 2、Part 3、Part 4)詳細介紹了沙箱的具體實現。沙箱使漏洞利用過程更加困難:即使攻擊者可以執行代碼,還是必須繞過沙箱的保護機制才能突破運行Adobe Reader的計算機。通常情況下,攻擊者需要借助操作系統本身的漏洞來繞過沙箱保護機制。
當然攻擊者可以同時找到Adobe Reader軟件以及目標操作系統中的漏洞并編寫利用程序,不過這種情況非常罕見。
惡意PDF樣本中嵌入了一段JavaScript代碼,用來控制整個漏洞利用過程。一旦PDF文件被打開,JavaScript代碼就會被執行。
在漏洞利用開頭階段,JavaScript代碼開始操控Button1
對象,該對象包含一個精心構造的JPEG2000圖像,該圖像會觸發Adobe Reader中的雙重釋放(double-free)漏洞。
圖1. 操控Button1
對象的JavaScript代碼
JavaScript代碼中用到了堆噴射(heap-spray)技術以破壞內部數據結構。在這些操作都完成后,攻擊者就實現了他們的主要目標:從JavaScript代碼中實現內存的讀取及寫入。
圖2. 用來讀取及寫入內存JavaScript代碼
利用這兩種方法,攻擊者成功定位EScript.api
插件的內存地址,而該插件正是Adobe JavaScript的引擎。利用該模塊的匯編指令(ROP gadgets),惡意JavaScript成功構造了一條ROP鏈,可以執行本地shellcode。
圖3. 惡意JavaScript成功構造ROP鏈
最后一步,shellcode會初始化PDF中內嵌的一個PE文件,將執行權遞交給該文件。
成功利用Adobe Reader漏洞后,攻擊者必須打破沙箱保護機制,而這正是我們即將討論的第二個利用代碼的目的所在。
這個未知漏洞的源頭在于win32k
Windows內核組件中的NtUserSetImeInfoEx
函數。更具體一些,就是NtUserSetImeInfoEx
的SetImeInfoEx
子例程沒有驗證數據指針的有效性,允許某個NULL指針被解除引用(dereference)。
圖4. 反匯編后的SetImeInfoEx
例程代碼
如圖4所示,SetImeInfoEx
函數的第一個參數為指向經過初始化的WINDOWSTATION
對象的指針。如果攻擊者創建了一個新的window station對象,并將其分配給用戶模式下的當前進程,那么spklList
就會等于0。因此,映射NULL頁面并將指針設置為偏移量0x2C
后,攻擊者就可以利用這個漏洞寫入內核空間中的任一地址。需要注意的是,從Windows 8開始,用戶進程不能再映射NULL頁面。
既然攻擊者具備任意寫入權限,他們就可以使用各種方法實施攻擊,不過在我們分析的這個例子中,攻擊者選擇使用Ivanlef0u以及Mateusz “j00ru” Jurczyk和Gynvael Coldwin介紹的一種技術。攻擊者重寫了全局描述符表(GDT,Global Descriptor Table)來創建Ring 0的一個call gate)(調用門)。為了完成這個任務,攻擊者使用SGDT匯編指令獲取了原始的GDT信息,構造自己的表然后使用前面提到的漏洞重寫了原始的表。
隨后,漏洞利用程序使用CALL FAR
指令執行了跨權限級別的調用。
圖5. 反匯編后的CALL FAR指令
一旦代碼在內核模式執行,漏洞利用程序就會使用system token(令牌)替換掉當前進程的token。
當PDF樣本提交到公共惡意樣本庫時,ESET研究人員就發現了這款樣本。彼時樣本并不包含最終的攻擊載荷,這表明當時樣本很有可能處于早期研發階段。雖然當時樣本并不包含真正的惡意載荷,仍有可能處于早期研發階段,但這也告訴我們樣本的作者在漏洞發現及漏洞利用方面具備較高的水平。
ESET檢測標識:
JS/Exploit.Pdfka.QNV trojan
Win32/Exploit.CVE-2018-8120.A trojan
樣本SHA-1哈希:
C82CFEAD292EECA601D3CF82C8C5340CB579D1C6
0D3F335CCCA4575593054446F5F219EBA6CD93FE
原文:https://www.welivesecurity.com/2018/05/15/tale-two-zero-days/