0x01 Lotus Blossom 行动
- 在 2015 年 6 月，国外安全厂商 Palo Alto Networks 的威胁情报团队 Unit42 发现了一起针对东南亚政府的一次间谍行为，试图获取该国家的内部运作信息，此次攻击行动代号为 Lotus Blossom
- 通过恶意构造 Office 文档使目标上钩，从而在对方的计算机中植入木马，诱骗的内容包括电影邀请、明星照片、陆军机密文件、IT 升级计划等等
- 其中就利用了著名的 CVE-2012-0158 Word 栈溢出漏洞（用烂了的），CVE-2012-0158 的成因是 MSCOMCTL 模块中对文档数据读取过滤不严导致堆栈溢出
0x02 构建漏洞分析环境
- 漏洞软件： Microsoft Office Word 2003，版本：11.0.8211（提取码：woi9）
- 调试器： Immunity Debugger、IDA（提取码：v0pt）、OD
- 虚拟机：Windows XP sp3 64 位操作系统（提取码：d3ho，需要先解压）
- 样本： 能够触发异常的 POC 文档（RTF 格式，提取码：by1o）
- Office 格式分析工具： Offvis、oletools
0x03 根据异常定位漏洞函数
- 这一次并没有用到 Windbg，因为异常点并没有想要的信息；利用 Immunity Debugger 附加 Word 进程打开漏洞文档（也可以加载源文件，但是附加进程可以跳过文档启动过程，更方便）
- 这个就是当前的运行程序，选择 WINWORD.EXE 程序
- 让它运行起来
- 打开 POC 文档触发异常
- 此时汇编窗口是黑色的，凭经验判断是返回值错误导致的，离堆栈异常点最近的地方可以看出有一个叫 MSCOMCTL 的模块，地址是 0x275c8a0a
- 载入 OD 运行
- 由堆栈可知，在该函数返回的时候会被覆盖 0x41414141，故在函数开辟堆栈前先断下，重新运行，发现此时函数返回值还未被覆盖
- 经过反复调试，发现执行完这个函数后返回值才被覆盖，所以进入这个函数
- 终于在 0x275c87cb 中看到了可疑的复制指令，经过多次调试发现确实是这一个指令出了问题，指令执行之后，堆栈会被覆盖（edi 和 esi 满足条件后，这里要多执行几次）
- 将有漏洞的模块载入到 IDA 当中，该模块是在 System32 中，并且基址和 0x275c87cb 相对应
- 找到汇编指令漏洞触发点
- 翻译成伪 C 代码，成功定位 memcpy 污点函数
0x04 追根溯源查找样本对应数据
- 从 memcpy 的第三个参数入手，追根溯源；图中 ecx 就是复制的大小，也就是第三个参数，那么就追踪 ecx
- 发现 ebx 传入 eax，而 ebx 的值又是 [ebp + 10h] 的地址，也就是 0x275c876d 函数的参数
- 在 OD 中可以看到这个 0x8282 这个参数
- 之后经过反复调试后，发现第一次调用该函数是获取样本中的 0x8282 这个数据，第二次调用该函数会将 0x8282 大小的数据复制到堆栈上造成溢出，再往下追根溯源就没有意义了
- 这个就是样本中的数据，和覆盖返回值的 0x41414141 都在其中
0x05 利用 Offvis 工具定位样本中的格式字段
- 本实验的 POC 是 RTF 格式，要想被 Offvis 认识，必须提取其中的 Word 格式，也就是图中的 D0CF…之后 ASCII 字符转换成 16 进制即可
- 这里可以编写 python 脚本来实现转换（每两个字符变为一个 16 进制储存即可），这里为了方便利用 oletools 这个工具来转换
- 这个就是转换好的 POC（提取码：8pb5） 文件，以 16 进制 DOCF 开头
- 之后在 Offvis 中打开就可以了
- 这里可以很清楚的看出，在 DirctoryEntries[4] 中的 OLESSDirctoryEntry[3] 中的 data 字段中出的问题
0x06 总结
- 在污点函数方面，也就是出问题的函数 memcpy 并没有出乎我的意料，因为发生栈溢出无非是 memcpy，strcpy 等等函数
- 在分析和对比样本中的数据和调试数据时，用到的方法也基本一致：定位异常触发点、跟踪堆栈找到问题函数、下内存断点进行污点跟踪和参数跟踪、使用工具对样本字段分析等等
- 分析时从攻击者角度出发，理解是如何构造样本数据来挖掘漏洞的
- 分析难点在于逆向理解函数，要清楚 C++ 、汇编和伪 C 代码之间的关系，尤其需要清楚 C++ 的指针和结构体在汇编中的调用，这需要扎实的逆向工程基础
- 参考资料：0day安全：软件漏洞分析技术 + 漏洞战争
本次对于 CVE-2012-0158 堆溢出漏洞的分析到此结束，如有错误，欢迎指证