CVE-2017-11882及利用樣本分析是怎樣的

這期內容當中小編將會給大家帶來有關CVE-2017-11882及利用樣本分析是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

CVE-2017-11882及利用樣本分析

0x01 漏洞描述

• 成因：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

• POC：https://github.com/Ridter/CVE-2017-11882

0x02 漏洞分析

筆者復現及分析環境：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文檔格式并非本文重點，如讀者此前對RTF文檔格式沒有了解，建議先閱讀文末參考鏈接中有關RTF文檔格式的文章后再看POC源碼。

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

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

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

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

MD5：0D38ADC0B048BAB3BD91861D42CD39DF

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

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

0x18F230地址處值0x430**7即覆蓋后的函數返回地址：

而該地址處指令是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中。

0x04 響尾蛇(SideWinder)組織某樣本分析

將文檔拖進WinHex查看：

可以看出該文檔實質是一RTF格式文檔。

用rtfobj.py分析如下：

Package后文會提到，先來看其CVE-2017-11882利用部分。

同樣是第二次斷下時：

其后的執行流程與上一樣本相似：

經過綠色方框中的一系列運算后，調用GlobalLock()函數，傳遞參數如下：

接下來跳轉到GlobalLock()函數返回內存區域中：

經過兩次call調用：

修正內存中的字符串：

接下來尋址kernel32.dll：

其所調用的函數功能如下：

兩次call調用之后：

其功能為返回某函數調用地址，此次是LoadLibrayW()：

接下來，返回GetProcAddress()調用地址：

繼續call調用：

其后流程如圖所示：

下面將字符串解密，并覆蓋原CommandLine內容：

執行完結果如下：

最后實際執行部分：

javascript:eval("sa=ActiveXObject;ab=new sa(\"Scripting.FileSystemObject\");
eval(ab.OpenTextFile(ab.GetSpecialFolder(2)+\"\\\\1.a\",1).ReadAll());windowclose()")

其后調用RunHTMLApplication()：

1.a就是之前提到RTF文檔中的Package，其實質是一JS文件：

最后，其執行結果大體如下圖所示：

0x05 蔓靈花(Bitter)組織某樣本分析

通過遠程模板注入的方式下載一RTF格式文檔：

拖進WinHex查看，可以確認其格式為RTF文檔格式：

添加文件擴展名后，打開該文檔。同樣是于于0x411658處第二次斷下時：

跳轉之后經過綠色方框中一系列計算，接著跳轉：

fldpi將π的值加載到FPU堆棧：

執行完后fpu_instruction_pointer指向fldpi指令，其后的fnstenv指令將FpuSaveState結構體保存到esp-0xC處：

如此一來，pop ebp后EBP寄存器的值是fpu_instruction_pointer——fldpi指令位置：

由EBP計算出需要解密的數據起始位置，EDX中存儲的是數據長度(0x315)：

接著執行解密后的指令：

跳轉后，執行相應指令，接下來call調用：

sub_562B2F功能是獲取指定的系統函數調用地址，此次是kernel32.VirtualAlloc()：

之后調用VirtualAlloc()申請內存空間：

向申請的內存空間中寫入數據：

調用sub_562B2F獲取kernel32.Wow64DisableWow64FsRedirection()調用地址：

LoadLibrary(shell32)：

傳遞參數給sub_562B2F，獲取shell32.ShellExcute()調用地址：

LoadLibrary(urlmon)：

獲取urlmon.URLDownloadToFile()調用地址：

調用URLDownloadToFile()，其傳遞參數如圖：

讀取文件：

由于沒有獲取到文件，計算出的EBX值錯誤：

上述就是小編為大家分享的CVE-2017-11882及利用樣本分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。