這篇文章將為大家詳細(xì)講解有關(guān)Office公式編輯器漏洞二代的原理分析、利用與防護(hù)方案是怎樣的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)洛隆,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575

在2018年1月9日的微軟例行更新中，微軟再一次對Office中的公式編輯器3.0產(chǎn)生的多個內(nèi)存破壞漏洞進(jìn)行了修補(bǔ)，并將這一系列漏洞歸類于編號CVE-2018-0802。

漏洞披露后，金睛安全研究團(tuán)隊(duì)及時對漏洞相關(guān)安全事件進(jìn)行了跟進(jìn)。

漏洞影響版本：

Office 365

Microsoft Office 2000      

Microsoft Office 2003      

Microsoft Office 2007 Service Pack 3

Microsoft Office 2010 Service Pack 2

Microsoft Office 2013 Service Pack 1

Microsoft Office 2016

漏洞事件分析：

目前已知的漏洞觸發(fā)方式存在兩種。

其中一種由國內(nèi)安全公司的研究員提出，利用了公式的FONT記錄解析漏洞，與之前的CVE-2017-11882漏洞較為接近。目前已經(jīng)存在此種方式進(jìn)行利用的在野樣本，由于新的利用方式在未打CVE-2017-11882補(bǔ)丁的機(jī)器上會造成崩潰，所以需要搭配之前的漏洞利用公式一同使用。

另一種由國外安全公司的研究員提出，使用了公式的MATRIX記錄(原報(bào)告中誤認(rèn)為是SIZE記錄)解析漏洞來造成棧溢出。目前尚未發(fā)現(xiàn)利用此種方式的樣本。由于此種方式對ASLR機(jī)制的繞過需要暴力枚舉，會導(dǎo)致打開文檔的時間變得極長。

由于前者的報(bào)告已經(jīng)非常詳細(xì)，且原理與CVE-2017-11882較為接近，本文將主要分析后者。

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

在CVE-2017-11882漏洞的一處修補(bǔ)(0x4164FA)中，修補(bǔ)代碼通過增加額外的參數(shù)(拷貝字符數(shù))以及增加判斷語句、截?cái)嗾Z句的方式，修正了所產(chǎn)生的棧溢出。

修補(bǔ)前后的代碼如下圖所示：

   
   

圖 1 - 修補(bǔ)前后的代碼對比

但問題正出在這個修補(bǔ)方式上，由于利用類似讀入方式的代碼有多處，難免存在漏網(wǎng)之魚。通過對GetByte函數(shù)(0x416352)的XREF進(jìn)行查看，可以查找到另一處可能產(chǎn)生越界拷貝的ReadData函數(shù)(0x443F6C)。

 

圖 2 - 存在漏洞的ReadData函數(shù)

實(shí)際拷貝的數(shù)據(jù)大小(real_size)的值經(jīng)傳入的參數(shù)(size)計(jì)算后得出，但這個傳入的參數(shù)是在公式中的可控?cái)?shù)據(jù)。因此將該值更改為較大的值，便會覆蓋掉棧上隨后的數(shù)據(jù)。

ReadData函數(shù)在0x443E34函數(shù)中被調(diào)用，繼續(xù)向上XREF發(fā)現(xiàn)僅有0x454F50地址處提到了該函數(shù)。向上查看可以發(fā)現(xiàn)0x454F30處是一個結(jié)構(gòu)體，通過對這一部分進(jìn)行逆向可以得到以下內(nèi)容(參考http://rtf2latex2e.sourceforge.net/MTEF3.html)。

   

圖 3 - 對TAG進(jìn)行解析的函數(shù)

而0x454F30處的結(jié)構(gòu)體對應(yīng)的是case 4，即MATRIX記錄。通過查閱可以發(fā)現(xiàn)MATRIX記錄的結(jié)構(gòu)如下：

偏移(以字節(jié)為單位)	字段名	說明
-1(已經(jīng)讀入)	TAG	低4位為0101(即5)高4位為可選標(biāo)志位(optional flags)文檔中所提到的“[nudge]if xfLMOVE is set”也在此字段
0	valign	指定對齊方式
1	h_just
2	v_just
3	rows	矩陣的行數(shù)和列數(shù)對這個數(shù)值未進(jìn)行檢驗(yàn)，所以會發(fā)生棧溢出
4	cols
5	row_parts	矩陣的行數(shù)據(jù)和列數(shù)據(jù)的類型
	col_parts
…	lines	矩陣的行數(shù)據(jù)和列數(shù)據(jù)

由于ProcessMatrixRecord(0x443E34)函數(shù)對rows和cols兩個變量的數(shù)值未進(jìn)行檢驗(yàn)，通過real_size = (2 * size + 9) / 8可以計(jì)算出實(shí)際復(fù)制的數(shù)據(jù)大小。

 通過實(shí)際的調(diào)試，可以得到棧上的內(nèi)存布局如下：

EBP - 0x14	row_data
EBP - 0x10
EBP - 0x0C	col_data
EBP - 0x08
EBP - 0x04
EBP
EBP + 0x04	返回地址

 為rows指定0x1C(28)，即實(shí)際復(fù)制(2 * 28 + 9) / 8 = 8個字節(jié)，然后為cols指定一個較大的數(shù)值(本例中0x94，即復(fù)制38個字節(jié))則會覆蓋掉棧上原本的內(nèi)容。

假定基址為0x400000，首先先用一定的數(shù)據(jù)覆蓋到棧上，結(jié)果如下。

   

圖 4 - ret時各寄存器的狀態(tài)

   

圖 5 - ret時EAX寄存器所指向的地址

在執(zhí)行ret語句時，EAX寄存器所指向的地址離樣本中可控的輸入數(shù)據(jù)相差0x32個字節(jié)。攻擊者可以通過構(gòu)造ROP鏈，對EAX寄存器的值進(jìn)行抬高，從而實(shí)現(xiàn)執(zhí)行任意命令。Check Point所給出的思路如下：

   

圖 6 - ROP鏈構(gòu)造思路

大體思路是通過將EAX寄存器的值兩次抬高(0x32 / 2 = 0x19)，然后使用其值作為WinExec的參數(shù)進(jìn)行調(diào)用。

中間出現(xiàn)了一個地址值0x455B28。原因要從處理MATRIX記錄的函數(shù)ProcessMatrixRecord(0x443E34)說起。

 

圖 7 - 對MATRIX記錄進(jìn)行解析的函數(shù)(ProcessMatrixRecord, 0x443E34)      

在上圖的第26行可以看到對sub_4428F0函數(shù)的調(diào)用，該調(diào)用有對a1(ebp+8)的讀寫操作(該數(shù)據(jù)是一個地址)，而在ReadData之后，我們所構(gòu)造的數(shù)據(jù)已經(jīng)覆寫了這塊內(nèi)存，破壞了原有數(shù)據(jù)。所以，我們應(yīng)該至少保證這四個字節(jié)的數(shù)據(jù)是一個可讀寫的地址。

由于微軟在CVE-2017-11882的修補(bǔ)程序中已經(jīng)強(qiáng)制開啟了ASLR機(jī)制，所以使exploit奏效仍需繞過此機(jī)制。這種方法利用了Word的一個特性：當(dāng)公式編輯器產(chǎn)生異常時，Word會接管異常并不給出任何提示信息。而EQNEDT32.exe是一個32位進(jìn)程，ASLR空間對應(yīng)的基址尚且處于可以枚舉的范圍內(nèi)——通過構(gòu)造大量的公式，使用不同的基址構(gòu)造ROP鏈即可繞過ASLR機(jī)制。

但在Check Point的POC演示視頻中可以發(fā)現(xiàn)，Word的加載窗口始終沒有消失，即Word一直在嘗試加載RTF文件，而計(jì)算器是在這個過程中被彈出的。筆者自己根據(jù)這種方法嘗試構(gòu)造的POC有3MB的大小，觸發(fā)也需要數(shù)分鐘的時間，在實(shí)際的攻擊樣本中，利用此種溢出方式的樣本可能需要其他的方式繞過ASLR機(jī)制。

解決方案：

1、下載微軟最新補(bǔ)丁

(1) https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

(2)開啟Windows自動更新。微軟最新版本已經(jīng)去掉了該模塊微軟將EQNEDT32.EXE從產(chǎn)品中刪除，并不再支持舊版本的公式格式。

2、在注冊表中取消該模塊的注冊

reg add “HKLM\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{0002CE02-0000-0000-C000-000000000046}” /v “Compatibility Flags” /t REG_DWORD /d 0x400

對于在64位操作系統(tǒng)上的32位的Office，執(zhí)行下列操作

   

reg add “HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{0002CE02-0000-0000-C000-000000000046}” /v “Compatibility Flags” /t REG_DWORD /d 0x400

關(guān)于Office公式編輯器漏洞二代的原理分析、利用與防護(hù)方案是怎樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

當(dāng)前標(biāo)題：Office公式編輯器漏洞二代的原理分析、利用與防護(hù)方案是怎樣的
網(wǎng)站鏈接：http://aaarwkj.com/article2/goojoc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、商城網(wǎng)站、網(wǎng)站營銷、用戶體驗(yàn)、網(wǎng)頁設(shè)計(jì)公司、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)