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

如何進行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 模塊，其功能會在之后分析到：

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

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

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

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

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

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

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

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“所在的模塊地址，待會通過它來下條件斷點：

條件斷點：

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

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

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

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

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

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

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

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

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

執行完“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保護：

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

首先獲取kernel32.dll基址：

接著比較API的hash值來獲取所需API函數，這樣的好處在于減少了shellcode的大小：

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

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

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

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

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

但是在之后的分析中，多次調試也沒有跟到真實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：

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

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

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

接著創建文件，釋放payload：

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

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

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

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

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

原始樣本所在的word文檔：

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