深入剖析最新IE0day漏洞


在2018年4月下旬,我們使用沙箱發現了IE0day漏洞;自從在野外發現上一個樣本(CVE-2016-0189)已經有兩年多了。從許多方面來看,這個特別的漏洞及其后續的開發比較有趣。下一篇文章將分析最新的漏洞背后的核心原因,CVE-2018-8174。

尋找0day漏洞

我們從VirusTotal (VT)開始搜尋0day漏洞,有人在2018年4月18日上傳了一個有趣的漏洞。這一漏洞被包括卡巴斯基在內的幾家AV供應商發現,特別是我們的通用啟發式邏輯,用於一些較老的Microsoft Word漏洞。

深入剖析最新IE0day漏洞

Virustotal對CVE-2018-8174的掃描結果

在我們的沙箱系統中處理了惡意軟件樣本后,我們注意到微軟Word的一個完全補丁版本被成功開發。從這一點開始,我們開始對漏洞進行了更深層次的分析。讓我們看一下完整的感染鏈:

深入剖析最新IE0day漏洞

感染鏈

感染鏈包括以下步驟:

· 受害者會收到惡意的微軟Word文檔。

· 在打開惡意文檔后,將下載該漏洞的第二階段;包含VBScript代碼的HTML頁面。

· VBScript代碼觸發Use After Free (UAF)漏洞后,並執行shellcode。

初步分析

我們將使用初始Rich Text Format (RTF) 文檔開始分析,該文檔用於傳遞IE的實際漏洞。它只包含一個對象,並且其內容是利用我們稱為“nibble drop”的已知混淆技術來進行混淆的。

深入剖析最新IE0day漏洞

在RTF文檔中混淆對象數據

在對對象數據進行了反混淆和十六進制解碼后,我們可以看到這是個OLE對象,其包含一個URL Moniker CLSID。正因為如此,這一漏洞最初類似於利用微軟HTA處理器的一個舊漏洞(CVE-2017-0199)。

深入剖析最新IE0day漏洞

URL Moniker被用來加載IE漏洞

使用CVE-2017-0199漏洞,Word嘗試根據其屬性,通過默認的文件處理程序,來執行文件;服務器響應中的Content-Type (內容類型)HTTP頭是其中之一。由於“application/hta”內容類型的默認處理程序是mshta.exe,該程序也是OLE的服務器,可以讓OLE不受限制地運行腳本。這一特點允許攻擊者直接調用ShellExecute並啟動選擇的有效負載。

但是,如果追蹤一下最新發現的漏洞中嵌入的URL,可以看到服務器響應中的內容類型不是“application/hta”,而是 “text/html”,這是CVE-2017-0199開發的需求。“text/html”的默認OLE服務器是mshtml.dll,它是一個包含引擎的庫,在Internet Explorer后面。

深入剖析最新IE0day漏洞

WINWORD.exe為正確的OLE服務器查詢注冊表

此外,該頁面包含VBScript,它利用安全模式標志加載,以將其默認值設為“0xE”。由於這一操作使得攻擊者不能直接執行有效負載,就像HTA處理程序一樣,需要利用Internet Explorer漏洞來克服這一點。

像上面一樣,使用一個URL名字對象來加載遠程web頁面是可能實現的,因為針對Moniker相關漏洞(CVE-2017-0199, CVE-2017-8570和CVE-2017-8759)的微軟補丁,引入了一個激活過濾器,它允許應用程序指定哪些COM對象在運行時被禁止實例化。

深入剖析最新IE0day漏洞

一些過濾后的COM對象,被限制IActivationFilter在MSO.dll中創建

在分析時,篩選的CLSID列表包含16個條目。TheMSHTML CLSID ({{25336920-03F9-11CF-8FD0-00AA00686F13})不在列表中,這就是為什么MSHTML COM服務器在Word上下文中成功創建的原因。

這就是它變得有趣的地方。盡管Word文檔是初始攻擊向量,但漏洞實際上是在VBScript中,而不是在Microsoft Word中。這是我們第一次見到利用URL Moniker加載IE漏洞,我們相信在不久的將來這一技術將會被惡意軟件作者大量使用。這種技術允許使用IE引擎加載並呈現一個web頁面,即使受害者機器上的默認瀏覽器設置為別的瀏覽器。

下載的HTML頁面中的VBScript包含了函數名和混淆的整數值。

深入剖析最新IE0day漏洞

混淆的IE漏洞

漏洞根本原因分析

對於根本原因分析,我們只需要看去混淆版本中的第一個函數(“TriggerVuln”),該函數是在“RandomizeValues”和“CookieCheck”之后被調用的。

深入剖析最新IE0day漏洞

去混淆后的漏洞觸發程序

為了實現所需的堆布局,並確保釋放的類對象內存將被“ClassToReuse”對象重用,該漏洞分配了一些類對象。為了觸發這個漏洞,這個代碼可以最小化到以下的概念驗證(PoC):

深入剖析最新IE0day漏洞

CVE – 2018 – 8174的概念驗證

當我們通過啟用頁面堆,在Internet Explorer中啟動這個PoC時,我們可以觀察到OLEAUT32!VariantClear函數的崩潰。

深入剖析最新IE0day漏洞

訪問關於釋放內存調用的違例

深入剖析最新IE0day漏洞

當第二個數組(ArrB)被破壞時,釋放的內存指針被重用

通過這個PoC,我們就能夠觸發一個Use-after-free漏洞;ArrA(1)和ArrB(1)在內存中引用相同的“ClassVuln”對象。這種情況是可能的,因為當調用“Erase ArrA”時,vbscript!VbsErase函數確定要刪除的對象類型是SafeArray,然后調用OLEAUT32!SafeArrayDestroy。

它檢查是否指向tagSafeArray結構的指針不是NULL,以及它的引用計數,存儲在時鍾字段中的是零,然后繼續調用ReleaseResources。

深入剖析最新IE0day漏洞

ArrA(1)的VARTYPE是VT_DISPATCH,因此調用VBScriptClass::Release來破壞對象

反過來,ReleaseResources將會檢查fFeatures標志變量,由於我們有VARIANT的一個數組,隨后它將調用VariantClear;它是一個函數,該函數迭代數組中的每個成員並執行必要的初始化,並在必要時調用相關的類析構函數。在本例中,VBScriptClass::Release被調用來正確地破壞對象,並且處理像Class_Terminate這樣的破壞者,因為ArrA(1)的VARTYPE是VT_DISPATCH。

深入剖析最新IE0day漏洞

在TerminateClass函數之前,只檢查一次CVE-2018-8174 -“refCount”的根本原因

這最終成為了漏洞的根源所在。在VBScriptClass::Release函數中,在函數開始時對引用計數只檢查一次。盡管可以(實際上是在PoC中)在一個超載的TerminateClass函數中增加檢查次數,但是在最終釋放類對象之前不會進行檢查。

Class_Terminate是一種過時的方法,現在被“Finalize”程序取代。在對象破壞期間,它被用來釋放獲得的資源,一旦對象被設置為空,該程序就會被執行,並且不再有對該對象的引用。在我們的例子中,Class_Terminate方法是超載的,當對VBScriptClass::TerminateClass執行調用時,就會為其分派超載的方法。在該超載方法的內部,為ArrA(1)成員創建了另一個引用。在這個點ArrB(1)引用ArrA(1),ArrA(1)擁有一個很快被釋放的ClassVuln對象。

深入剖析最新IE0day漏洞

崩潰,由於在釋放第二個對象時調用一個無效的虛擬方法

在Class_Terminate子完成之后,Arr(1)中的對象被釋放,但是ArrB(1)仍然保留對被釋放類對象的引用。當繼續執行,並且ArrB被擦除時,整個循環會重復,除了這一次,ArrB(1)引用了一個已釋放的ClassVuln對象,因此當調用ClassVuln vtable中的一個虛擬方法時,我們觀察到了崩潰。

總結

在本文中,我們分析了CVE-2018-8174背后的核心原因,Use-After-Free是一個特別有趣的漏洞,這可能是由於在Class_Terminate VBScript方法中錯誤的對象周期處理造成的。其漏洞利用過程不同於我們在過去的漏洞(CVE-2016-0189和CVE-2014-6332)中所看到的,因為該漏洞不再使用Godmode技術。完整的開發鏈和漏洞本身一樣有趣,但是超出了本文的范圍。

CVE – 2018 – 8174是首個使用URL名字對象在Word中加載一個IE漏洞的公開漏洞,我們相信,除非被固定,不然未來攻擊者將大量的使用這種技術進行攻擊,因為它允許在無視受害者系統默認瀏覽器設置的情況下,強迫IE加載。

鑒於距離漏洞攻擊開發者開始濫用這一技術進行路過式攻擊(通過瀏覽器)以及網絡釣魚攻擊(通過文檔)活動,不會太久,我們預計該漏洞將成為近期利用最多的工具之一。為了保持安全,我們建議應用最新的安全更新,並使用帶有行為檢測功能的安全解決方案。

在我們看來,這一漏洞和Qihoo360核心安全團隊在其最近的出版物中所稱的“Double Kill”是同一漏洞。雖然這一漏洞並不局限於瀏覽器利用,但它被報告為IE0day漏洞,這一舉動在安全社區中引起了一定的混亂。

在發現這一漏洞后,我們立即與微軟分享了相關信息,並且微軟確認這實際上是CVE-2018-8174。

該漏洞在野外被發現,並被一個APT行動者使用。對卡巴斯基情報報告服務的客戶來說,可以獲得更多關於該APT行動者的信息以及該漏洞的使用信息。聯系:intelreports@kaspersky.com

檢測

卡巴斯基實驗室的產品成功地檢測並阻斷了所有的開發鏈和有效載荷的所有階段,並進行了如下的判決:

HEUR:Exploit.MSOffice.Generic—— RTF文檔

PDM:Exploit.Win32.Generic——IE漏洞——采用漏洞自動預防技術檢測。

HEUR:Exploit.Script.Generic——IE漏洞

HEUR:Trojan.Win32.Generic ——有效載荷

IOCs

b48ddad351dd16e4b24f3909c53c8901 ——RTF文檔

15eafc24416cbf4cfe323e9c271e71e7 ——IE漏洞 (CVE-2018-8174)

1ce4a38b6ea440a6734f7c049f5c47e2 ——有效載荷


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM