【Office漏洞 第一弹】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地点处值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中。
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值错误：

故至此结束。
0x06 参考链接

• Office恶意文件解析与混淆研究
  
• https://github.com/Ridter/CVE-2017-11882
  
• Office文件格式底子知识
  

来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！