0x01 Lotus Blossom 行动

在 2015 年 6 月，国外安全厂商 Palo Alto Networks 的威胁情报团队 Unit42 发现了一起针对东南亚政府的一次间谍行为，试图获取该国家的内部运作信息，此次攻击行动代号为 Lotus Blossom
通过恶意构造 Office 文档使目标上钩，从而在对方的计算机中植入木马，诱骗的内容包括电影邀请、明星照片、陆军机密文件、IT 升级计划等等
其中就利用了著名的 CVE-2012-0158 Word 栈溢出漏洞（用烂了的），CVE-2012-0158 的成因是 MSCOMCTL 模块中对文档数据读取过滤不严导致堆栈溢出

0x02 构建漏洞分析环境

这一次并没有用到 Windbg，因为异常点并没有想要的信息；利用 Immunity Debugger 附加 Word 进程打开漏洞文档（也可以加载源文件，但是附加进程可以跳过文档启动过程，更方便）
这个就是当前的运行程序，选择 WINWORD.EXE 程序
让它运行起来
打开 POC 文档触发异常
此时汇编窗口是黑色的，凭经验判断是返回值错误导致的，离堆栈异常点最近的地方可以看出有一个叫 MSCOMCTL 的模块，地址是 0x275c8a0a
载入 OD 运行
由堆栈可知，在该函数返回的时候会被覆盖 0x41414141，故在函数开辟堆栈前先断下，重新运行，发现此时函数返回值还未被覆盖
经过反复调试，发现执行完这个函数后返回值才被覆盖，所以进入这个函数
终于在 0x275c87cb 中看到了可疑的复制指令，经过多次调试发现确实是这一个指令出了问题，指令执行之后，堆栈会被覆盖（edi 和 esi 满足条件后，这里要多执行几次）
将有漏洞的模块载入到 IDA 当中，该模块是在 System32 中，并且基址和 0x275c87cb 相对应
找到汇编指令漏洞触发点
翻译成伪 C 代码，成功定位 memcpy 污点函数

从 memcpy 的第三个参数入手，追根溯源；图中 ecx 就是复制的大小，也就是第三个参数，那么就追踪 ecx
发现 ebx 传入 eax，而 ebx 的值又是 [ebp + 10h] 的地址，也就是 0x275c876d 函数的参数
在 OD 中可以看到这个 0x8282 这个参数
之后经过反复调试后，发现第一次调用该函数是获取样本中的 0x8282 这个数据，第二次调用该函数会将 0x8282 大小的数据复制到堆栈上造成溢出，再往下追根溯源就没有意义了
这个就是样本中的数据，和覆盖返回值的 0x41414141 都在其中

本实验的 POC 是 RTF 格式，要想被 Offvis 认识，必须提取其中的 Word 格式，也就是图中的 D0CF…之后 ASCII 字符转换成 16 进制即可
这里可以编写 python 脚本来实现转换（每两个字符变为一个 16 进制储存即可），这里为了方便利用 oletools 这个工具来转换
这个就是转换好的 POC（提取码：8pb5）文件，以 16 进制 DOCF 开头
之后在 Offvis 中打开就可以了
这里可以很清楚的看出，在 DirctoryEntries[4] 中的 OLESSDirctoryEntry[3] 中的 data 字段中出的问题