CVE-2015-1641 Office类型混淆漏洞及shellcode分析

作者：枕边月亮

原文来自：CVE-2015-1641 Office类型混淆漏洞及shellcode分析

 

0x1实验环境：Win7_32位，Office2007

0x2工具：Windbg，OD，火绒剑，UltraEdit，oletools；

 

0x3漏洞简述：word在解析docx文档的displacedByCustomXML属性时未对customXML对象进行验证，可以传入其他标签对象进行处理，造成类型混淆，通过在word中嵌入构造好的RTF文件，其中经过精心构造的标签以及对应的属性值被displacedByCustomXML解析以及后续函数处理后会造成任意内存写入。

 

0x4 样本hash值：8bb066160763ba4a0b65ae86d3cfedff8102e2eacbf4e83812ea76ea5ab61a31

 

下载链接：https://github.com/houjingyi233/ ... 76ea5ab61a31.bin.gz

 

0x5：分析记录：

  在分析前先做好虚拟机快照，获取RTF样本后使用oletools工具中的rtfobj.pyc脚本分析，这里将文件命名为aa.doc，在cmd命令模式中来到rtfobj.pyc所在的目录，并将aa.doc一块放到该目录，接着执行命令“rtfobj.pyc aa.doc”,得到分析结果如下：一共四个文件，id为0的是“otkloadr.wRAssembly.1”，用来加载 OTKLOADR.DLL 模块，其功能会在之后分析到：

 

把其他三个OLE对象分别根据他们各自的id用“rtfobj.pyc-s [id] aa.doc”命令依次分离并保存，其中有两个是”.doc”文件，现在样本已经被分离，双击执行也不会有危险，

 

 

将其中id为2的"aa.doc_object_0002042c.doc"的后缀改为“.docx”后,打开word就会奔溃，可以预测，漏洞就在这个OLE里面触发的：

 

 

  在分析这个样本的过程中，由于对RTF文件构造方式不熟悉，使得我在构造样本的时候阻滞了很长时间，东拼西凑就是不能制造crash，后边把问题放到了看雪论坛，前辈们一下就解决了，其实RTF文件的构造不复杂：将原始rtf 样本用文本方式打开，搜索 “objdata” 字符串，可找到与 rtfobj.py 提取后相应 id 的内容，手动抽取对应id的内容另存为一个合法的 rtf 文件即可。前面提到，这个RTF样本一共由四个OLE对象组成，用notepad++打开原始样本，然后搜索“objdata” 字符串，发现一共有四个这样的字符串，也就是那四个OLE，触发漏洞的OLE的id为2，也就是原始样本中的第三个OLE，长这样：

 

 

抽取复制OEL的时候一定要把括号成对匹配好，把这个OLE复制出来，即它的开头到下一个OLE的开头的部分，然后新建一个文本文档，并把后缀改为”.rtf”格式，然后在这个文档中先写好“{\rtf}”，然后粘贴OLE进去即可：