CVE-2015-1641 Word 利用样本分析 Secer's Blog - 记录互联网安全历程与个人成长经历

作者：知道创宇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 的起始位置：