干货分享丨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中。

由于文章篇幅较长，我们分了上/下篇为大家分享，请大家持续关注哦~