CVE-2015-1641 Word 利用樣本分析

作者：知道創宇404實驗室

0 引子

本文我們將通過一個惡意文檔的分析來理解漏洞 CVE-2015-1641（MS15-033）的具體利用過程，以此還原它在現實攻擊中的應用。就目前來看，雖然該 Office 漏洞早被修復，但由于其受影響版本多且穩定性良好，相關利用在坊間依舊比較常見，因此作為案例來學習還是很不錯的。

1 樣本信息

分析中用到的樣本信息如下：

SHA256：8bb066160763ba4a0b65ae86d3cfedff8102e2eacbf4e83812ea76ea5ab61a31
大小：967,267 字節
類型：RTF 文檔

和大多數情形一樣，漏洞的利用是借助嵌入OLE對象來實現的，我們可由 oletools 工具包中的rtfobj.py進行查看：

圖0 借助 rtfobj.py 分析樣本

這里我們先對這些嵌入對象做個簡要介紹，詳細的分析見后文。其中otkloadr.WRAssembly.1為ProgID，用于加載 OTKLOADR.DLL 模塊，從而引入 MSVCR71.DLL 模塊來繞過 ASLR 保護。而剩下的3個對象均為 Word 文檔，我們可分別對它們進行提取，id為1的文檔用來進行堆噴布局，id 為2的文檔用來觸發漏洞利用，id 為3的文檔作用未知，樣本中余下的數據為異或加密后的 shellcode、惡意程序以及最終呈現給用戶的 Word 文檔。

此外，由于 rtf 文檔在格式上組織起來比較簡單，有時為了調試的方便，我們可以僅抽取樣本中的部分對象數據進行分析。若無特殊說明，文中的分析環境均為 Win7 x86+Office 2007（wwlib.dll的版本號為12.0.4518.1014）。

2 漏洞原理分析

下面我們來大致看下漏洞的原理，通過rtfobj.py提取上述 id 為2的 Word 文檔，將其后綴改為 zip 后解壓，可在document.xml文件中找到如下的 XML 片段，紅色標注部分即樣本實現利用的關鍵所在：

圖1 引起類型混淆的 smartTag 標簽

簡單來說，此漏洞是由于 wwlib.dll 模塊在處理標簽內容時存在的類型混淆錯誤而造成的任意內存寫，即用于處理 customXml 標簽的代碼沒有進行嚴格的類型檢查，導致其錯誤處理了 smartTag 標簽中的內容。

我們來具體跟下，首先將樣本中id為2的這部分內容手動抽取（非rtfobj.py提取）出來另存為一個rtf文檔，然后作為winword.exe的打開參數載入 WinDbg，直接運行可以看到程序在如下位置處崩潰了，注意此時 ecx 寄存器的值對應第一個 smartTag 標簽中的 element 值：

圖2 程序的崩潰點

我們在上述崩潰點下條件斷點，同時將 id 為 0 的內容也添加到該 rtf 文檔中，重新載入 WinDbg。單步往下跟可以來到如下計算待寫入內存地址的函數，可以看到該內存地址是根據 smartTag 標簽中的 element 值計算出來的：

圖3 計算待寫入的內存地址

而后程序會調用 memcpy 函數向待寫入內存進行數據拷貝，拷貝的內容即為 moveFromRange* 標簽的 id 值，因此通過控制上述 smartTag 標簽的兩個特定值能實現任意內存地址寫入，樣本中的這幾個值都是精心構造的：

圖4 向待寫入內存地址寫入特定數據

針對該漏洞的補丁如下圖所示，為了盡可能減少不相關因素的影響，這里比對的 wwlib.dll 版本號分別為12.0.6718.5000 和 12.0.6720.5000。可以看出，在處理 customXml 標簽的代碼中多了一個條件判斷：

圖5 補丁前后的比對結果

如果存在類型混淆的情況，那么該條件是不會滿足的，即相應的處理函數不一致，也就不會對樣本中的 smartTag 標簽內容進行處理了：

圖6 補丁后原漏洞點的執行流程

3 漏洞利用分析

3.1 執行流控制

接著我們看下樣本如何實現程序執行流的控制，首先需要繞過 ASLR 保護，可以知道id為0的OLE對象其 CLSID 如下：

圖7 otkloadr.WRAssembly.1 對應的 CLSID

我們在 ole32 模塊的 CoCreateInstance 函數上下斷，此函數的作用是初始化 OLE 對象，可以看到程序會加載 OTKLOADR.DLL 模塊，而 OTKLOADR.DLL 模塊又引用了 MSVCR71.DLL 模塊中導出的接口函數，所以該模塊也會被加載：

圖8 OTKLOADR.DLL 模塊的加載

而 MSVCR71.DLL 模塊并未啟用 ASLR 保護，樣本將借此繞過 ASLR 保護：

圖9 MSVCR71.DLL 模塊未啟用 ASLR 保護

對于僅抽取樣本中id為0和2這兩部分對象內容的 rtf 文檔來說，最終會觸發程序的內存訪問違規，從函數的調用棧可以看出其上層應為虛函數調用，這種情況一般通過進程的棧空間來查找函數返回地址，以此分析調用關系。這里顯然不能通過目前的 esp 進行查找，我們回溯幾條指令后下斷并重新執行：

圖10 程序出現內存訪問違規

此時再查看棧空間中的符號信息如下：

圖11 查看棧空間中的符號信息

進一步分析可知，下述紅色標識的指令即為相應的虛函數調用指令，其中，跳轉的目的地址為 0x7c376fc3，同時壓入的參數為 0x09000808，我們注意到這兩個值就是 smartTag 標簽中 moveFromRange* 的id值：

圖12 相應的上層虛函數調用

這與樣本借助此漏洞實現的內存寫入操作正好是相對應的，因此，通過覆蓋 MSVCR71.DLL 模塊中的虛表指針，樣本獲得了 eip 控制權，另一方面，覆蓋后的入參則是與下小節討論的堆噴布局有關：

圖13 利用此漏洞實現的內存寫入操作

當然，根據Office分析環境的不同，上述獲取 eip 的流程會存在差異，應該是樣本出于兼容性方面的考慮。

3.2 shellcode

再接著我們來看一下 shellcode，此樣本中有兩部分 shellcode，第一部分會由堆噴布局到內存中。Office的堆噴一般通過 activeX 控件來實現，我們借助rtfobj.py提取樣本中id為1的Word文檔，解壓后可在 activeX 目錄得到如下文件列表，其中布局數據保存在 activeX.bin 文件中，更多相關討論可參考此blog：

圖14 用于實現堆噴的文件列表

堆噴后進程空間的分布情況如下：

圖15 堆噴后的進程空間

因此，程序通過堆噴能將 activeX.bin 文件中的數據精確布局到內存空間上，其中包含了 ROP 鏈和 shellcode。而樣本在獲得 eip 后會進行棧轉移操作，也就是將前面的入參 0x09000808 賦給 esp，從而將其引到 ROP 鏈上執行：

圖16 activeX.bin 文件中的布局數據

不用想ROP鏈的作用肯定就是調用 VirtualProtect 函數來改變內存頁的屬性，使之擁有執行權限以繞過DEP保護，不過分析環境中的 Word 2007 并未啟用此保護：

圖17 Word 2007 進程未啟用 DEP

這里提及的棧轉移和 ROP 鏈操作我們就不再贅述了，接下去把重點放到 shellcode 的理解上，其實方法無它，單步跟即可。對于第一部分 shellcode，它首先會通過查找 LDR 鏈的方式來獲取 kernel32 模塊的基址，因為后面會用到此模塊導出的接口函數：

圖18 獲取 kernel32 模塊的基址

而對于 kernel32 模塊中導出函數的查找過程實際上就是PE文件結構中導出表的解析過程，如下為PE頭的解析：

圖19 解析 kernel32 模塊的導出信息

目標函數名將以 hash 值的方式給出，如下就是查找相應目標函數名的過程，而在找到目標函數名后，將會從 AddressOfNameOrdinals 數組中取出對應的值，以此作為 AddressOfFunctions 數組中的索引，再加上模塊基址就得到了此目標函數的導出地址：

圖20 查找 kernel32 模塊中的目標函數名

第一部分 shellcode 的作用是為了引出第二部分 shellcode，由于這部分數據是加密后保存在樣本文件中的，因此首先需要獲取打開的樣本文件句柄，在 shellcode 中會遍歷進程中打開的文件句柄，并通過調用 GetFileSize 找出其中符合條件的句柄進行下一步的判斷：

圖21 查找符合條件大小的文件句柄

隨后會通過調用 CreateFileMapping 和 MapViewOfFile 函數將此特定大小的文件映射到內存中，如果前4個字節為 “{\rt”，即表示內存中映射的為目標樣本文件，之后通過字符串 “FEFEFEFEFEFEFEFEFFFFFFFF” 定位到第二部分 shellcode 的起始位置：