如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析

蝸牛 互聯網技術資訊 2021-12-21 145 0

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

0x1實驗環境:Win7_32位,Office2007

0x2工具:Windbg,OD,火絨劍,UltraEdit,oletools;

0x3漏洞簡述:word在解析docx文檔的displacedByCustomXML屬性時未對customXML對象進行驗證,可以傳入其他標簽對象進行處理,造成類型混淆,通過在word中嵌入構造好的RTF文件,其中經過精心構造的標簽以及對應的屬性值被displacedByCustomXML解析以及后續函數處理后會造成任意內存寫入。

0x4 樣本hash值:8bb066160763ba4a0b65ae86d3cfedff8102e2eacbf4e83812ea76ea5ab61a31


下載鏈接:https://github.com/houjingyi233/ ... 76ea5ab61a31.bin.gz

0x5:分析記錄:

??在分析前先做好虛擬機快照,獲取RTF樣本后使用oletools工具中的rtfobj.pyc腳本分析,這里將文件命名為aa.doc,在cmd命令模式中來到rtfobj.pyc所在的目錄,并將aa.doc一塊放到該目錄,接著執行命令“rtfobj.pyc aa.doc”,得到分析結果如下:一共四個文件,id為0的是“otkloadr.wRAssembly.1”,用來加載 OTKLOADR.DLL 模塊,其功能會在之后分析到:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第1張


把其他三個OLE對象分別根據他們各自的id用“rtfobj.pyc-s [id] aa.doc”命令依次分離并保存,其中有兩個是”.doc”文件,現在樣本已經被分離,雙擊執行也不會有危險,

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第2張


將其中id為2的"aa.doc_object_0002042c.doc"的后綴改為“.docx”后,打開word就會奔潰,可以預測,漏洞就在這個OLE里面觸發的:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第3張


??在分析這個樣本的過程中,由于對RTF文件構造方式不熟悉,使得我在構造樣本的時候阻滯了很長時間,東拼西湊就是不能制造crash,后邊把問題放到了看雪論壇,前輩們一下就解決了,其實RTF文件的構造不復雜:將原始rtf 樣本用文本方式打開,搜索 “objdata” 字符串,可找到與 rtfobj.py 提取后相應 id 的內容,手動抽取對應id的內容另存為一個合法的 rtf 文件即可。前面提到,這個RTF樣本一共由四個OLE對象組成,用notepad++打開原始樣本,然后搜索“objdata” 字符串,發現一共有四個這樣的字符串,也就是那四個OLE,觸發漏洞的OLE的id為2,也就是原始樣本中的第三個OLE,長這樣:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第4張


抽取復制OEL的時候一定要把括號成對匹配好,把這個OLE復制出來,即它的開頭到下一個OLE的開頭的部分,然后新建一個文本文檔,并把后綴改為”.rtf”格式,然后在這個文檔中先寫好“{\rtf}”,然后粘貼OLE進去即可:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第5張


然后把這個RTF文件用word打開,就會奔潰;中間失敗過幾次,后來發現是復制OLE的時候括號復制多了。


接著來定位漏洞觸發的位置,先打開Windbg,再打開Winword.exe,用調試器附加Winword.exe后運行存在漏洞的OLE文件,程序在“0x67C39d30“這個地址出現異常,導致奔潰,原因是[ECX]引用了一個不存在的地址;

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第6張


這個指針[7C38BD50]會指向哪里?,先把這個存在漏洞的OLE解壓,在解壓目錄的資源組織文件“document.xml”中發現如下的代碼:上面ECX的值被內嵌成smarttTag標簽的element的屬性值

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第7張


martTag標簽是一個智能標簽,可對名字、地址等自動識別,displacedByCumtomXml屬性表示此處要替換為另一個customxml標簽,”next”表示后一個,”prev“表示前一個;樣本作者在smartTag的element中構造了0x7C38BD50,Word在解析docx文檔處理displacedByCustomXML屬性時未對customXML對象進行驗證,所以能傳入smartTag標簽對象。


單獨加載觸發漏洞的OLE時索引到一個不存在的地址,因為這個地址位于” MSVCR71.DLL”中,而這個DLL正是通過第一個OLE對象“otkloadr.wRAssembly.1”引入的。將第一個OLE對象:{\object\objocx{\*\objdata0105000002000000160000006f746b6c6f6164722e5752417373656d626c792e3100000000000000000001000000410105000000000000}},添加到觸發漏洞的OLE前面,然后重新加載合并后的RTF運行,通過windbg下條件斷點,這里先記錄下crash發生的時候“0x7C38BD50“所在的模塊地址,待會通過它來下條件斷點:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第8張

條件斷點:

bp wwlib!DllGetClassObject+0x50e6".if(ecx=7c38BD50){}.else{gc}"

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第9張



0x7C38BD50是smartTag標簽的element值,0xFFFFE696(十進制為4294960790)是moveFromRangeStart的值,隨后對這兩個值進行計算得到一個地址0x7C38BD74。計算過程如下:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第10張

隨后開始解析第二個smartTag,smartTag標簽的element值此時為0x7C38BD68,moveFromRangeStart的值為0x7C376FC3(十進制為2084007875),計算出的地址為0x7C38A428,最后通過memcpy函數將0x7C376FC3覆蓋到地址0x7C38A428中,在調試器可以看到,0x7C38A428為虛表指針:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第11張


而在7C38A428被覆蓋之前,它指向的是kernel32!FlsGetValue:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第12張


覆蓋之后的0x7c38a428指向的便是攻擊者想要執行的代碼位置:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第13張


接著往下執行會先經過一大片地址為“7C342404”的“ret”,然后進入ROP鏈,再往后就是shellcode。

將id為1的OLE解壓后,在解壓目錄的“activeX1.bin“中看到用來堆噴的數據塊:nop指令上面的是ROP鏈,heapspary前會使用大量地址為0x7c342404 的ret-sled,

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第14張


通過XML來加載“activeXL.bin”的堆數據:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第15張


在堆噴數據看到ROP鏈之前有大量的“ret sled”,可以通過這個地址來下斷點進入shellcode,方法為:在進入MSVCR71.dll后,通過“uf 7C342304 ”命令來查看它所在的模塊地址:MSVCR71!calloc+0xb1,并在該處下斷;然后用“bd”命令禁用之前的條件斷點,F10執行后就能來到地址0x7C342404。如下圖,當程序在“0x7C342404”處斷下時,通過“Memory”窗口輸入Virtual為“ESP”可以看到堆噴數據,如果不能進入到堆噴數據,有兩種解決方案:可以將虛擬機的內存設置為2G;或者找到rop鏈在堆中的位置,接著在執行“ret”準備跳進堆噴數據的時候將棧頂值修改為ROP鏈的起始位置;

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第16張

執行完“0x7C342404”處的“ret”后,便可以接著跟到ROP鏈,F10單步執行:然后通過NOP進入shellcode。

在Windbg中分析shellcode的時候一直沒能順利跟下去,于是在OD中來分析,斷點還是在“0x7C342404”:打開OD和Winword.exe后,用OD附加Winword.exe,接著把完整樣本拖進word,這個時就可以下斷點,因為shellcode是最后執行,在這之前要先進行堆噴,再觸發漏洞,時間上來得及。當程序在“0x7C342404”處斷下后,發現很久也跟不到ROP鏈,這時可以借助之前Windbg的分析結果,發現ROP鏈的首個位置為“0x7C3651EB”,然后在該位置下斷,同時把“0x7C342404”處的斷點禁用,接著F9執行,便能來到ROP鏈的開頭。

在ROP鏈中通過調用VirtualProtect關閉起始地址0x090008b4后的DEP保護:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第17張


接著執行地址0x090008b4處的“nop+shellcode”:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第18張


首先獲取kernel32.dll基址:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第19張

接著比較API的hash值來獲取所需API函數,這樣的好處在于減少了shellcode的大?。?/p>

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第20張


接著用VirtualAlloc分配可執行的內存空間,為執行shellcode做準備:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第21張


接著通過調用 GetFileSize遍歷進程中打開的文件句柄,獲取打開的樣本文件的句柄:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第22張


CreateFileMapping創建該文件的共享文件數據:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第23張


MapViewOfFile來獲取共享數據的內存地址:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第24張


判斷幾個標志位是否為“{\rt,0xfefefefe,0xfe,0xffffffff”,是則將shellcode拷貝到VirtualAlloc分配的可執行的內存空間:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第25張


但是在之后的分析中,多次調試也沒有跟到真實shellcode的位置,于是嘗試用Windbg來分析,根據上一階段的分析可知,第一階段的shellcoed先判斷幾個標志字符串是否為“{\rt,0xfefefefe,0xfe,0xffffffff”,是的話就將真實shellcode拷貝到VirtualAlloc分配的可執行的內存空間,如上圖所示:順利的話就會執行“0x090009F9”(偏移0x09F9)地址處的指令。


然后關掉OD,打開Windbg和Winword.exe,用Windbg附加Winword.exe,先在“0x7C342404”,即“ret”鏈的位置下斷,然后將原始樣本附加到Winword.exe,執行后來到“ret”,接著在“0x7C3651EB”,即ROP鏈的開頭下斷,并用“bd 0”禁用之前的斷點,執行后來到ROP鏈的開頭,根據上面的分析,真實shellcode會在偏移“0x09F9”處開始執行,用“bc 0”,“bc 1”先將之前的斷點刪除,再在“0x090009F9”下斷,執行后順利來到第二階段的shellcode:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第26張


接著將后面的4KB的數據,即第二部分 shellcode,拷貝到函數 VirtualAlloc 申請的具有可執行權限的內存中,然后跳轉過去執行

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第27張



之后會在這部分shellcode的偏移0x2e處解密shellcode,解密的大小為0x3CC字節:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第28張


接著根據標志字符串“0xBABABABABA”獲得payload的起始位置,然后xor 0xCAFEBABE解碼payload,終止標志為0xBBBBBBBB:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第29張


接著創建文件,釋放payload:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第30張


可以根據API參數在UE編輯器看到路徑和創建的文件“svchost.exe”:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第31張


??接著用WinExec函數執行“svchost.exe”:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第32張


WinExec函數執行后,在監控軟件(火絨劍)中可以看到釋放的惡意程序,它的作用主要是進行信息的竊取,:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第33張


在惡意payload 執行后會對樣本中的部分數據進行異或操作,目的是使其成為看上去正常的word,這部分機器碼的開頭是“0xBB”,結尾是“0xBCBC”,

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第34張


重寫之后看到的word就是正常打開的空白文檔:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第35張


原始樣本所在的word文檔:

如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析  shellcode 第36張

關于如何進行CVE-2015-1641 Office類型混淆漏洞及shellcode分析問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注蝸牛博客行業資訊頻道了解更多相關知識。

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:niceseo99@gmail.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

評論

日本韩欧美一级A片在线观看