压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

一、前言

2018年4月下旬，我們利用沙箱環(huán)境發(fā)現(xiàn)了Internet Explorer（IE）的一個(gè)最新0day漏洞，而這距離IE漏洞上一次在野外被利用（CVE-2016-0189）已經(jīng)過(guò)去了2年時(shí)間。這個(gè)漏洞以及相關(guān)利用技術(shù)在某些方面較為有趣，本文詳細(xì)分析了這個(gè)漏洞（CVE-2018-8174）的根本原因。

二、捕獲0day漏洞

故事開(kāi)始于2018年4月18日，當(dāng)時(shí)有人往VirusTotal（VT）上傳了一個(gè)有趣的漏洞利用程序。包括卡巴斯基在內(nèi)的多個(gè)AV廠(chǎng)商成功檢測(cè)到了這個(gè)利用程序，我們將該程序標(biāo)記為針對(duì)老版本Microsoft Word漏洞的通用啟發(fā)式邏輯類(lèi)別。

圖1. Virustotal上對(duì)CVE-2018-8174的掃描結(jié)果

使用我們的沙箱系統(tǒng)處理這款?lèi)阂鈽颖竞螅覀冏⒁獾郊幢愦蛏贤暾a(bǔ)丁的Microsoft Word也會(huì)被成功利用。根據(jù)這個(gè)信息，我們開(kāi)始深入分析這個(gè)利用程序。我們先來(lái)看一下完整的感染鏈：

圖2. 感染鏈

這條感染鏈包含如下幾個(gè)環(huán)節(jié)：

1、受害者收到一個(gè)惡意Microsoft Word文檔。

2、打開(kāi)這個(gè)惡意文檔后，樣本會(huì)下載第二階段的利用程序，即包含VBScript代碼的HTML頁(yè)面。

3、VBScript代碼會(huì)觸發(fā)UAF（Use After Free，釋放后重用）漏洞并執(zhí)行shellcode。

三、初步分析

我們針對(duì)RTF（Rich Text Format）文檔開(kāi)始研究，攻擊者利用該文檔來(lái)投遞針對(duì)IE的利用程序。該文檔只包含一個(gè)對(duì)象，其內(nèi)容經(jīng)過(guò)混淆處理，這是一種已知的混淆技術(shù)，我們稱(chēng)之為“nibble drop（半字節(jié)）”混淆技術(shù)。

圖3. RTF文檔中經(jīng)過(guò)混淆處理的對(duì)象

去除混淆并解密16進(jìn)制數(shù)據(jù)后，我們發(fā)現(xiàn)這是一個(gè)OLE對(duì)象，其中包含一個(gè)URL Moniker.aspx) CLSID。因此，漏洞利用程序最開(kāi)始的處理方式與之前的一個(gè)漏洞（CVE-2017-0199）類(lèi)似，該漏洞用到了Microsoft HTA處理程序。

圖4&5. 使用URL Moniker來(lái)加載IE漏洞利用載荷

在CVE-2017-0199漏洞中，Word會(huì)嘗試根據(jù)文件的屬性，使用默認(rèn)的文件處理程序來(lái)執(zhí)行文件，比如服務(wù)器響應(yīng)報(bào)文中的Content-Type HTTP頭部字段就是其中一個(gè)屬性。由于application/hta這個(gè)Content-Type所對(duì)應(yīng)的默認(rèn)處理程序?yàn)?code>mshta.exe，因此Word會(huì)選擇其作為OLE服務(wù)器，不受限制地運(yùn)行腳本。這樣攻擊者就可以直接調(diào)用ShellExecute，啟動(dòng)所選擇的攻擊載荷。

然而，如果我們檢查最新利用程序中嵌入的URL時(shí)，我們發(fā)現(xiàn)服務(wù)器響應(yīng)中的Content-Type并非application/hta（CVE-2017-0199漏洞需要滿(mǎn)足這個(gè)條件），而是text/html。與text/html對(duì)應(yīng)的默認(rèn)OLE服務(wù)器為mshtml.dll，這是包含IE后端引擎的一個(gè)程序庫(kù)。

圖6. WINWORD.exe查詢(xún)注冊(cè)表確定正確的OLE服務(wù)器

此外，該頁(yè)面包含一個(gè)VBScript，加載該腳本時(shí)會(huì)使用一個(gè)安全模式標(biāo)志（默認(rèn)值0xE）。這樣一來(lái)攻擊者無(wú)法直接執(zhí)行攻擊載荷，這與HTA處理程序的情況一樣，需要使用一個(gè)IE漏洞才能突破這個(gè)限制。

微軟在針對(duì)Moniker相關(guān)漏洞（CVE-2017-0199、CVE-2017-8570以及CVE-2017-8759）的補(bǔ)丁中引入了激活過(guò)濾器，利用該過(guò)濾器，應(yīng)用程序可以限制在運(yùn)行時(shí)實(shí)例化的COM對(duì)象，因此攻擊者有可能可以使用URL moniker來(lái)加載遠(yuǎn)程web頁(yè)面。

圖7. 被過(guò)濾的某些COM對(duì)象，限制使用MSO.dll中的IActivationFilter來(lái)創(chuàng)建這些對(duì)象

在分析樣本時(shí)，過(guò)濾后的CLSID列表包含16個(gè)表項(xiàng)。MSHTML CLSID（{{25336920-03F9-11CF-8FD0-00AA00686F13}}）不在該列表中，因此攻擊者可以在Word上下文環(huán)境中成功創(chuàng)建MSHTML COM服務(wù)器。

現(xiàn)在起事情開(kāi)始變得有趣起來(lái)。盡管Word文檔是攻擊者使用的最初攻擊媒介，但漏洞實(shí)際上位于VBScript中，而非Microsoft Word中。這是我們第一次看到有攻擊者使用URL Moniker來(lái)加載IE漏洞利用載荷，我們相信惡意軟件開(kāi)發(fā)者會(huì)在未來(lái)大量應(yīng)用這種技術(shù)。利用這種技術(shù)，攻擊者可以使用IE引擎加載并渲染web頁(yè)面，即便受害者主機(jī)上的默認(rèn)瀏覽器并非IE瀏覽器。

下載的HTML頁(yè)面中的VBScript包含一些函數(shù)名及整數(shù)值，這些信息都經(jīng)過(guò)混淆處理。

圖8. 經(jīng)過(guò)混淆處理的IE漏洞利用載荷

四、漏洞原理分析

為了分析漏洞原理，我們只需查看去混淆后腳本中的第一個(gè)函數(shù)（即TriggerVuln），程序在調(diào)用RandomizeValues以及CookieCheck函數(shù)后就會(huì)調(diào)用該函數(shù)。

圖9&圖10. 去混淆腳本中的漏洞觸發(fā)過(guò)程

為了獲得所需的堆布局，確保已被釋放的類(lèi)對(duì)象內(nèi)存會(huì)被ClassToReuse對(duì)象再次復(fù)用，漏洞利用程序會(huì)分配一些類(lèi)對(duì)象。觸發(fā)漏洞的代碼可以精簡(jiǎn)為如下PoC代碼：

圖11. CVE-2018-8174漏洞PoC代碼

當(dāng)我們使用啟用了頁(yè)堆的IE瀏覽器運(yùn)行這個(gè)PoC時(shí)，我們可以觀(guān)察到OLEAUT32!VariantClear函數(shù)會(huì)發(fā)生崩潰：

圖12. 調(diào)用被釋放的內(nèi)存時(shí)出現(xiàn)訪(fǎng)問(wèn)沖突（Access Violation）異常

圖13. 當(dāng)銷(xiāo)毀第二個(gè)數(shù)組（ArrB）時(shí)會(huì)復(fù)用被釋放的內(nèi)存指針

利用這個(gè)PoC代碼我們成功觸發(fā)了一個(gè)UAF漏洞，ArrA(1)以及ArrA(2)都會(huì)引用內(nèi)存中的同一個(gè)ClassVuln對(duì)象。這種情況有可能會(huì)出現(xiàn)，因?yàn)楫?dāng)Erase ArrA被調(diào)用時(shí)，vbscript!VbsErase函數(shù)會(huì)確定待刪除的對(duì)象類(lèi)型為SafeArray，然后再調(diào)用OLEAUT32!SafeArrayDestroy。

然后函數(shù)會(huì)檢查指向tagSafeArray.aspx)結(jié)構(gòu)的指針不為NULL，同時(shí)檢查指針的引用計(jì)數(shù)（存儲(chǔ)在cLocks字段中）是否為0，然后繼續(xù)調(diào)用ReleaseResources。

圖14. ArrA(1)的VARTYPE為VT_DISPATCH，因此會(huì)調(diào)用VBScriptClass::Release來(lái)銷(xiāo)毀對(duì)象

而ReleaseResources會(huì)檢查fFeatures這個(gè)標(biāo)志變量，由于我們有一個(gè)VARIANT數(shù)組，因此該函數(shù)隨后會(huì)調(diào)用VariantClear，VariantClear函數(shù)會(huì)遍歷數(shù)組中的每個(gè)成員，執(zhí)行必要的去初始化操作，并且根據(jù)需要調(diào)用相關(guān)的類(lèi)析構(gòu)函數(shù)。在我們分析的這種情況中，由于ArrA(1)的VARTYPE為VT_DISPATCH，因此程序會(huì)調(diào)用VBScriptClass::Release來(lái)正確銷(xiāo)毀對(duì)象，處理類(lèi)似Class_Terminate之類(lèi)的析構(gòu)函數(shù)。

圖15. CVE-2018-8174的根本原因：在TerminateClass函數(shù)之前只檢查一次reCount

這正是這個(gè)漏洞的根源所在。在VBScriptClass::Release函數(shù)內(nèi)部，程序只在函數(shù)開(kāi)頭檢查了一次引用計(jì)數(shù)值。即使該值很有可能會(huì)在重載的TerminateClass函數(shù)中遞增（PoC代碼中的確這么處理），最終釋放類(lèi)對(duì)象前并沒(méi)有再做任何檢查。

Class_Terminate是一個(gè)被棄用的方法，現(xiàn)在已經(jīng)被Finalize過(guò)程所取代。在對(duì)象銷(xiāo)毀過(guò)程中，程序會(huì)使用該函數(shù)來(lái)釋放已獲取的資源，一旦對(duì)象被設(shè)置為空并且該對(duì)象沒(méi)有其他引用時(shí)就會(huì)立即執(zhí)行該函數(shù)。在我們的例子中，Class_Terminate被代碼重載，當(dāng)調(diào)用VBScriptClass::TerminateClass時(shí)，會(huì)轉(zhuǎn)到對(duì)應(yīng)的重載方法。在重載方法內(nèi)部又創(chuàng)建了ArrA(1)成員的另一個(gè)引用。此時(shí)ArrB(1)引用了ArrA(1)，其中包含一個(gè)即將被釋放的ClassVuln對(duì)象。

圖16. 釋放第二個(gè)對(duì)象時(shí)調(diào)用了無(wú)效的虛方法而導(dǎo)致崩潰

當(dāng)Class_Terminate子函數(shù)處理完畢后，Arr(1)所對(duì)應(yīng)的對(duì)象被釋放，但ArrB(1)仍然保持被釋放的類(lèi)對(duì)象的引用。當(dāng)執(zhí)行流程繼續(xù)時(shí)，ArrB會(huì)被擦除，再次執(zhí)行類(lèi)似邏輯，不過(guò)這一次ArrB(1)引用了一個(gè)被釋放的ClassVuln對(duì)象，因此當(dāng)程序調(diào)用ClassVuln vtable中的某個(gè)虛方法時(shí)，我們就可以觀(guān)察到崩潰現(xiàn)象。

五、總結(jié)

在這篇文章中，我們分析了CVE-2018-8174漏洞背后的核心原因，這是一個(gè)特別有趣的UAF漏洞，漏洞成因在于Class_Terminate這個(gè)VBScript方法沒(méi)有正確處理相關(guān)對(duì)象的生命周期。漏洞利用過(guò)程與我們?cè)谥奥┒矗–VE-2016-0189以及CVE-2014-6332）中看到的利用過(guò)程不一樣，原因在于Godmode（上帝模式）技術(shù)已經(jīng)不再適用。整個(gè)漏洞利用鏈與漏洞本身一樣有趣，但本文對(duì)此不再贅述。

CVE-2018-8174漏洞是利用URL moniker來(lái)加載IE漏洞載荷的第一款漏洞，除非這種技術(shù)被修復(fù)，否則我們認(rèn)為攻擊者未來(lái)將大量濫用這種技術(shù)，無(wú)視受害者系統(tǒng)上的默認(rèn)瀏覽器設(shè)置，強(qiáng)制使用IE來(lái)加載攻擊頁(yè)面。

我們預(yù)計(jì)該漏洞將在不久的將來(lái)成為攻擊者最喜歡的突破口，相信漏洞利用工具包開(kāi)發(fā)者很快就會(huì)在驅(qū)動(dòng)式（通過(guò)瀏覽器感染）以及漁叉式釣魚(yú)（通過(guò)文檔感染）攻擊活動(dòng)中濫用這種技術(shù)。為了保證自身安全，我們建議大家采用最新的安全更新，適用具備行為檢測(cè)功能的安全解決方案。

在我們看來(lái)，這個(gè)漏洞實(shí)際上就是360核心安全團(tuán)隊(duì)最近發(fā)現(xiàn)的瀏覽器“雙殺”漏洞。雖然漏洞利用技術(shù)并不限于瀏覽器范疇，但仍被歸類(lèi)為IE 0Day漏洞，這給安全社區(qū)帶來(lái)了一些混亂。

發(fā)現(xiàn)這個(gè)漏洞后，我們第一時(shí)間與微軟分享了相關(guān)信息，微軟確認(rèn)該漏洞為CVE-2018-8174漏洞。

六、檢測(cè)方法

卡巴斯基實(shí)驗(yàn)室產(chǎn)品可以成功檢測(cè)并阻止整個(gè)利用鏈及相關(guān)載荷，具體如下：

1、將RTF文檔標(biāo)記為HEUR:Exploit.MSOffice.Generic

2、將IE漏洞利用技術(shù)標(biāo)記為PDM:Exploit.Win32.Generic，可以使用自動(dòng)漏洞防護(hù)技術(shù)來(lái)防護(hù)

3、將IE漏洞利用技術(shù)標(biāo)記為HEUR:Exploit.Script.Generic

4、將攻擊載荷標(biāo)記為HEUR:Trojan.Win32.Generic

七、IOC

RTF文檔：

b48ddad351dd16e4b24f3909c53c8901

IE漏洞利用技術(shù)（CVE-2018-8174）

15eafc24416cbf4cfe323e9c271e71e7

攻擊載荷

1ce4a38b6ea440a6734f7c049f5c47e2

相關(guān)網(wǎng)址

autosoundcheckers[.]com

原文：https://securelist.com/root-cause-analysis-of-cve-2018-8174/85486/