乾貨分享丨Office漏洞分析（上篇）

今天的文章是 i 春秋論壇作者ERFZE表哥發佈的文章，關於CVE-2017-11882及利用樣本分析，文章篇幅較長，閱讀約12分鐘。

漏洞描述

成因：Windows的公式編輯器EQNEDT32.EXE讀入包含MathType的OLE數據，在拷貝公式字體名稱時沒有對名稱長度進行校驗，使得攻擊者可以通過刻意構造的數據內容覆蓋棧上的函數返回地址，從而劫持程序流程。

影響版本：Microsoft Office 2007 Service Pack 3, Microsoft Office 2010 Service Pack 2, Microsoft Office 2013 Service Pack 1, Microsoft Office 2016

漏洞分析

筆者復現及分析環境：Windows 7 Service Pack 1、Microsoft Office 2010、x32dbg、IDA 7.0

EQUATION.exe存在：

設置註冊表項

HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\EQNEDT32.EXE：

Debugger鍵值為x32dbg路徑。

生成POC：

打開該文檔，於WinExec( )函數處設斷：

成功斷下後，查看棧中返回地址：

繼續向上查看棧，發現調用WinExec( )的函數：

通過IDA分析sub_4115A7功能：

跟進sub_41160F查看：

未校驗長度，直接使用strcpy( )函數，此處應該就是漏洞觸發位置。進一步確定具體位置：

於0x411658處設斷，重新運行。第二次成功斷下後，查看ESI寄存器指向內存內容：

此時ECX寄存器值為0xC，即複製48個字節到EDI寄存器指向內存，而var_28實際大小隻有36個字節：

到達函數結束處：

leave指令執行完畢後，棧頂0x18F1D0處值為0x430C12，即調用WinExec( )。而傳遞參數正是0x18F350指向內存中的cmd指令：

成功彈出計算器：

下面對使用到的POC進行簡要分析，各變量含義由命名可知，RTF文檔格式並非本文重點。

首先判斷命令長度是否小於43，而43這個數字是因為：

上圖選中部分是插入命令處，具體偏移由POC中COMMAND_OFFSET(0x949*2)變量給出。

將命令插入到構造數據中之後，函數返回拼接好的OLE。下面將OLE嵌入到RTF文檔中：

摩訶草(APT-C-09)組織某樣本分析

MD5：0D38ADC0B048BAB3BD91861D42CD39DF

於0x411658處設斷，在第二次斷下時，各寄存器值如下：

繼續執行到函數結束處leave指令：

0x18F230地址處值0x430C47即覆蓋後的函數返回地址：

而該地址處指令是ret，有些出乎意料。繼續向下執行，來到0x18F3B0處，正是0x18F234地址處值：

這方才是構造者意欲執行的指令。經過藍色方框中的一系列運算後，EBX指向是真正的Shellcode：

上述內容均可在OLE中查看(路徑\\\\xl\\embeddings)：

將OLE0x1000—0x1520中數據複製到一bin文件後，通過IDA查看。sub_247功能如下：

該函數接受的第二個參數即上文提到的EBX指向地址，於OLE中位置是0x1040，而0x1040+0x558處內容如下：

故該函數第一個功能是修正PE文件頭。第二個功能流程如下：

將0x1040+0x558後的PE文件數據寫入到%APPDATA%\\MSBuild.exe中。第三個功能流程如下：

將%APPDATA%\\MSBuild.exe寫入註冊表run項鍵值lollipop中。

由於文章篇幅較長，我們分了上/下篇為大家分享，請大家持續關注哦~

閱讀更多 i春秋論壇 的文章

關鍵字: 乾貨 微軟 Windows