微軟修復(fù)的Office 0day漏洞CVE-2018-0802是怎樣的

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)微軟修復(fù)的Office 0day漏洞CVE-2018-0802是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

簡(jiǎn)介

2018年1月的微軟安全補(bǔ)丁中修復(fù)了360核心安全高級(jí)威脅應(yīng)對(duì)團(tuán)隊(duì)捕獲的office 0day漏洞（CVE-2018-0802），該漏洞幾乎影響微軟目前所支持的所有office版本。這是繼360在全球范圍內(nèi)首家截獲Office 0day漏洞（CVE-2017-11826）在野攻擊以來，發(fā)現(xiàn)的第二起利用零日漏洞的在野高級(jí)威脅攻擊。360核心安全團(tuán)隊(duì)一直與微軟保持積極溝通，一起推進(jìn)該0day漏洞的修復(fù)，讓漏洞得到妥善解決后再披露漏洞信息。該漏洞的技術(shù)原理類似于潛伏了17年的“噩夢(mèng)公式”漏洞(CVE-2017-11882），是黑客利用office內(nèi)嵌的公式編輯器EQNEDT32.EXE再次發(fā)起的攻擊，我們將其命名為“噩夢(mèng)公式二代”（CVE-2018-0802）。

攻擊流程分析

我們捕獲了多個(gè)“噩夢(mèng)公式二代”的在野攻擊，在野樣本嵌入了利用Nday漏洞和0day漏洞的2個(gè)公式對(duì)象同時(shí)進(jìn)行攻擊，Nday漏洞可以攻擊未打補(bǔ)丁的系統(tǒng)，0day漏洞則攻擊全補(bǔ)丁系統(tǒng)，繞過了CVE-2017-11882補(bǔ)丁的ASLR（地址隨機(jī)化）安全保護(hù)措施，攻擊最終將在用戶電腦中植入惡意的遠(yuǎn)程控制程序。

圖：“噩夢(mèng)公式二代”在野樣本攻擊流程

漏洞細(xì)節(jié)分析

“噩夢(mèng)公式二代”為CVE-2017-11882的補(bǔ)丁繞過漏洞，類型為棧溢出，根本原因?yàn)槲④浽凇柏瑝?mèng)公式一代”的補(bǔ)丁中沒有修復(fù)另一處拷貝字體FaceName時(shí)的棧溢出。本次漏洞在未打補(bǔ)丁的版本上只會(huì)造成crash，但在打補(bǔ)丁的版本上可以被完美利用。下面我們通過poc樣本來分析CVE-2018-0802漏洞。

靜態(tài)分析

與CVE-2017-11882一樣，本次漏洞的觸發(fā)數(shù)據(jù)位于所提取OLE對(duì)象的“Equation Native”流內(nèi)。圖1中紅線圈出部分為核心數(shù)據(jù)，共0x99=153字節(jié)。0x08代表font tag，緊隨其后的00 01分別代表字體的typeface和style，從33開始直到25 00的區(qū)域?yàn)镕ont名稱，為棧溢出時(shí)拷貝的數(shù)據(jù)。這部分?jǐn)?shù)據(jù)里面包含了shellcode、bypass ASLR的技巧，進(jìn)程命令行以及相關(guān)用于填充的數(shù)據(jù)，我們將在后面分析它們。

圖1

Equation Native 數(shù)據(jù)結(jié)構(gòu)

據(jù)網(wǎng)上公開的資料，整個(gè)“EquationNative”的數(shù)據(jù)構(gòu)成為：

EquationNative Stream Data = EQNOLEFILEHDR + MTEFData

其中MTEFData =MTEF header + MTEF Byte Stream。

QNOLEFILEHDR的結(jié)構(gòu)如圖2所示：

圖2

MTEF header的結(jié)構(gòu)如表1所示，關(guān)于這個(gè)結(jié)構(gòu)，我們觀察到的實(shí)際數(shù)據(jù)和格式規(guī)范存在差異，下表中以實(shí)際觀察到的為主：

表1 

在攻擊樣本中，MTEF ByteStream結(jié)構(gòu)如表2所示：

表2

FONT記錄及FONT內(nèi)容結(jié)構(gòu)如表3所示：

表3

補(bǔ)丁繞過分析

CVE-2018-0802的漏洞觸發(fā)點(diǎn)位于sub_21E39(在IDA中將模塊基址設(shè)為0)，如圖3所示，可以看出該函數(shù)的功能為根據(jù)公式中的字體數(shù)據(jù)來初始化一個(gè)LOGFONT結(jié)構(gòu)體：

圖3 

我們來看一下微軟對(duì)于LOGFONT結(jié)構(gòu)體的說明(圖4)。可以看到這個(gè)結(jié)構(gòu)體的最后一個(gè)成員為lfFaceName，

圖4：LOGFONT結(jié)構(gòu)體

我們?cè)倏匆幌挛④泴?duì)lfFaceName成員的說明(圖5)?？梢钥吹絣fFaceName代表了字體的typeface名稱，在所分析的版本上，它是一個(gè)以空結(jié)尾的char型字符串，最大長(zhǎng)度為32，其中包含終止符NULL。

圖5 

問題很明顯：圖3紅框內(nèi)的代碼在拷貝字體FaceName時(shí)并沒有限制拷貝長(zhǎng)度，而拷貝的源數(shù)據(jù)為用戶提供的字體名稱，目的地址為父函數(shù)傳遞進(jìn)來的一個(gè)LOGFONT結(jié)構(gòu)體地址。我們回溯到sub_21E39的父函數(shù)來看一下(圖6)，可以看到這個(gè)地址位于父函數(shù)開辟的棧上，是父函數(shù)的一個(gè)局部變量。攻擊者通過構(gòu)造惡意數(shù)據(jù)，覆蓋了父函數(shù)(sub_21774)的返回地址的后兩個(gè)字節(jié)，然后將控制流導(dǎo)向了位于棧上的shellcode。

圖6

分析過程中我們發(fā)現(xiàn)一處疑似遞歸的地方，圖7為sub_21774的反匯編代碼，可以看到sub_21774先是調(diào)用了漏洞函數(shù)sub_21E39去初始化一個(gè)LOGFONT結(jié)構(gòu)體，然后調(diào)用相關(guān)API，傳入這個(gè)結(jié)構(gòu)體，從系統(tǒng)獲取到一個(gè)字體名稱保存到Name。隨后，它將獲取到的Name和用戶提供的lpLogFont作對(duì)比，如果不一致(并且sub_115A7函數(shù)需要返回False)，會(huì)再根據(jù)a3指定的條件來繼續(xù)調(diào)用或者不調(diào)用自身，而a3為sub_21E39函數(shù)的第3個(gè)參數(shù)。

圖7

我們來看一下第3個(gè)參數(shù)的傳參，否則可能存在多次遞歸，不能有效利用本次溢出。根據(jù)之前CVE-2017-11882的調(diào)試結(jié)果(圖8)，我們可以看到，在解析用戶提供的font數(shù)據(jù)時(shí)，調(diào)用sub_21774的函數(shù)為sub_214C6。我們回溯到sub_214C6看一下(圖9)，sub_214C6調(diào)用sub_21774前給第三個(gè)參數(shù)傳的值為1，所以圖7中的if(a3)為真。我們?cè)賮砜匆幌聢D7，sub_21774遞歸調(diào)用自己時(shí)對(duì)第3個(gè)參數(shù)傳的值為0，這意味著sub_21774不會(huì)再次調(diào)用自己，遞歸層級(jí)只會(huì)有1級(jí)。分析到這里，遞歸的疑惑解決了。

圖8：CVE-2017-11882觸發(fā)執(zhí)行流

圖9 

分析到這里還有一個(gè)問題，那就是在_strcmpi(lpLogfont,&Name)不成立的情況下(如果font數(shù)據(jù)為用戶偽造，此處肯定不成立)，sub_115A7會(huì)被調(diào)用，這意味著會(huì)走到CVE-2017-11882的溢出點(diǎn)。在未打11月補(bǔ)丁的版本上，如果要成功利用CVE-2017-11882，CVE-2018-0802的點(diǎn)就不會(huì)發(fā)生溢出，因?yàn)榍罢咝枰囊绯鲩L(zhǎng)度比后者小很多，且拷貝最后有一個(gè)NULL符截?cái)?我們知道溢出到CVE-2017-11882的可控eip只需要0x2C個(gè)字節(jié)，而通過下文(圖11)的分析我們可以知道溢出到CVE-2018-0802的可控eip需要0x94字節(jié))。另一方面，在未打11月補(bǔ)丁的版本上，想要觸發(fā)CVE-2018-0802，就必然會(huì)先觸發(fā)CVE-2017-11882?？傊珻VE-2018-0802在11補(bǔ)丁前的版本上無法利用。

可是，從圖10可以看到，在11月的補(bǔ)丁中，微軟在CVE-2017-11882溢出點(diǎn)的拷貝前，對(duì)拷貝長(zhǎng)度進(jìn)行了0x20的長(zhǎng)度限制，并且拷貝完成后，在拷貝最后手動(dòng)加了一個(gè)NULL，從而使CVE-2017-11882失效。這直接導(dǎo)致打補(bǔ)丁前無法被利用的CVE-2018-0802可以被利用了！現(xiàn)在，只要sub_115A7返回False，漏洞就可以得到完美利用，而實(shí)際調(diào)試發(fā)現(xiàn)，sub_115A7返回False。

圖10

動(dòng)態(tài)分析

溢出點(diǎn)的數(shù)據(jù)拷貝

有了上面的分析，動(dòng)態(tài)分析就變得很簡(jiǎn)單了。既然本次溢出點(diǎn)會(huì)拷貝數(shù)據(jù)，我們來監(jiān)控一下每次拷貝時(shí)的源字符串和相應(yīng)的?；厮?，我們先進(jìn)入OLE數(shù)據(jù)相關(guān)的Load函數(shù)(sub_6881)，然后在拷貝數(shù)據(jù)前下斷點(diǎn)并進(jìn)行輸出，結(jié)果如代碼所示：

從日志中可以看到存在兩次拷貝，通過?；厮菸覀兛梢灾肋@兩次拷貝正是靜態(tài)分析中對(duì)sub_21174的兩次調(diào)用。第一次是sub_214c6對(duì)sub_21174的調(diào)用，第二次是sub_21174對(duì)自身的調(diào)用?？梢钥吹降谝淮慰截悤r(shí)明顯發(fā)生了棧溢出。這里稍微提一下，cb ce cc e5代表的是宋體。

我們來詳細(xì)計(jì)算一下需要溢出多少長(zhǎng)度才能控制父函數(shù)(sub_21174)的返回地址(這個(gè)問題的結(jié)論在“補(bǔ)丁繞過分析”一節(jié)已被提及)，由圖11可知，從lfFaceName(-0x90)溢出到ret_addr(+0x4)，一共需要0x94字節(jié)，超出0x94部分的字節(jié)會(huì)逐個(gè)從低地址開始覆蓋返回地址。

圖11

我們對(duì)照poc里面的數(shù)據(jù)來看一下，如圖12所示，藍(lán)色部分為溢出的前0x94字節(jié)，25 00 為溢出的最后兩個(gè)字節(jié)，00為終止符，拷貝時(shí)遇到00就停止。按照小端地址布局，poc運(yùn)行時(shí)，EIP只會(huì)被覆蓋低位的2個(gè)字節(jié)。為什么這樣做？答案是為了繞過ASLR。

圖12

Bypass ASLR

我們來看一下為什么區(qū)區(qū)兩個(gè)字節(jié)就可以繞過ASLR。

首先我們要清楚，補(bǔ)丁文件是開啟了ASLR的，如圖13所示。這樣一來每次加載EQNEDT32.EXE時(shí)的基址都是隨機(jī)的，所以溢出時(shí)需要考慮的第一個(gè)問題就是如何繞過ASLR。(至于DEP，由圖14可以看到，補(bǔ)丁文件的EQNEDT32.EXE未開啟DEP，所以正常情況下無需考慮DEP)

不幸的是，攻擊者顯然對(duì)Windows系統(tǒng)機(jī)制和防御措施非常了解。因?yàn)樵赪indows平臺(tái)上，32位進(jìn)程的ASLR每次只隨機(jī)化地址的高2個(gè)字節(jié)，而低2個(gè)字節(jié)保持不變。假如能在被覆蓋的地址的同一片低0xFFFF空間內(nèi)找到一個(gè)ret指令，并且滿足形如0xABCD00XY的這種地址(其中ABCD及XY為6個(gè)任意16進(jìn)制數(shù)，地址中倒數(shù)第二個(gè)字節(jié)必須為0x00，因?yàn)閺?fù)制完后需要精確截?cái)?，就可以直接利用這個(gè)ret跳轉(zhuǎn)到棧上。由于無需繞過DEP，所以可以在棧上直接執(zhí)行shellcode。

圖13：EQNEDT32.EXE的ASLR狀態(tài)為啟用，DEP為非永久DEP

圖14: EQNEDT32.EXE的DEP狀態(tài)為停用

更加不幸的是，在EQNEDT32.EXE模塊內(nèi)，微軟還真給且僅給了這樣一個(gè)地址(圖15)，滿足條件的地址有且僅有一個(gè)，即20025，eip中被覆蓋的兩個(gè)字節(jié)25 00是唯一的，沒有第二個(gè)滿足條件的ret。

圖15

我們來思考一下sub_21174原來的返回地址是什么？當(dāng)然是sub_214C6調(diào)用sub_21174的下一條指令的地址，由圖16可以看到這個(gè)地址的偏移為214E2，按照?qǐng)D12的覆蓋方式，覆蓋后的偏移變成了20025，由上面的分析及圖17中可以看到，這個(gè)地址是一條ret指令。這條指令會(huì)彈出sub_214C6給sub_21174的第1個(gè)參數(shù)，并且將控制流切換到這個(gè)值去執(zhí)行。雪上加霜的是，這第1個(gè)參數(shù)恰好為lpLogFont，正是用戶所提供的FontName。所以ret執(zhí)行后，控制流會(huì)被轉(zhuǎn)移到棧上，并且恰好開始執(zhí)行用戶提供的FontName的第一個(gè)字節(jié)。

圖16

圖17

樣本A的Shellcode分析

在針對(duì)樣本A改造的poc中，控制流劫持及shellcode部分的執(zhí)行如圖18所示：

圖18：由于遞歸的存在，從sub_21774函數(shù)中需要返回兩次，這解釋了前兩個(gè)ret

         jmpeax指令后會(huì)馬上調(diào)用WinExec，而命令行參數(shù)恰好為calc.exe，如圖19所示：

圖19

樣本B的Shellcode分析

樣本B繞過ASLR的方式和樣本A一致，但shellcode部分與樣本A不一樣。樣本B的shellcode會(huì)通過PEB找到kernel32.dll的導(dǎo)出表(圖20和圖21)，然后通過特定的hash算法(圖21)在導(dǎo)出表中搜索比較所需函數(shù)的哈希值，所需函數(shù)的哈希值在shellcode中所給出。隨后，shellcode會(huì)將查找到的函數(shù)地址保存到之前存放hash值的地方(圖22)。

圖20：樣本B的shellcode中所給出的hash值及拷貝的路徑名稱

圖21：通過hash值在kernel32.dll的導(dǎo)出表中查找所需函數(shù)

圖22：查找函數(shù)地址前后棧上數(shù)據(jù)的對(duì)比

 在成功查找到函數(shù)并且將地址保存到棧上后，先調(diào)用ExpandEnvironmentStringsA函數(shù)展開短路徑(短路徑保存在shellcode中)，再調(diào)用CopyFileA將payload拷貝到word插件目錄下，從而讓payload隨著word下次啟動(dòng)自動(dòng)加載到內(nèi)存。最后調(diào)用ExitProcess退出公式編輯器進(jìn)程(圖23)。整個(gè)過程并不影響文檔的正常打開。

圖23：展開短路徑，拷貝文件，退出進(jìn)程

“噩夢(mèng)公式二代”（CVE-2018-0802）所使用的0day漏洞堪稱CVE-2017-11882的雙胞胎漏洞，攻擊樣本中的一個(gè)漏洞針對(duì)未打補(bǔ)丁前的系統(tǒng)，另外一個(gè)漏洞針對(duì)打補(bǔ)丁后的系統(tǒng)，利用兩個(gè)OLE同時(shí)進(jìn)行攻擊，黑客精心構(gòu)造的攻擊完美兼容了系統(tǒng)漏洞補(bǔ)丁環(huán)境的不同情況。這個(gè)漏洞的利用技巧和Bypass ASLR的方式都帶有一定的巧合性，假如EQNEDT32.EXE模塊內(nèi)沒有一條滿足條件的ret指令可以用來繞過ASLR，假如lpLogFont不是sub_21774的第一個(gè)參數(shù)，假如CVE-2017-11882的補(bǔ)丁修復(fù)方式強(qiáng)制開啟了DEP保護(hù)，“噩夢(mèng)公式二代”將沒有可乘之機(jī)。

最新的360安全產(chǎn)品已可以檢測(cè)并防止此0day漏洞的攻擊，同時(shí)我們建議用戶及時(shí)更新2018年1月的微軟安全補(bǔ)丁。

上述就是小編為大家分享的微軟修復(fù)的Office 0day漏洞CVE-2018-0802是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。