CVE-2018-0802：Microsoft office 公式编辑器 font name 字段二次溢出漏洞调试分析

\x01 前言

CVE-2018-0802 是继 CVE-2017-11882 发现的又一个关于 font name 字段的溢出漏洞，又称之为 “第二代噩梦公式”，巧合的是两个漏洞竟由同一个函数 sub_421774 所引发，而且都属于栈溢出。据说是国内安全厂商 360 率先截获了全球首例利用此漏洞的攻击，并且立即公布了该漏洞的具体细节，给安全厂商们赢得了宝贵的时间，避免攻击进一步扩大。在 2018 年 1 月的微软例行安全更新中有此漏洞的具体细节，以及针对 Office 各个版本的补丁。

注：需要注意的是，由于该漏洞是按笔者自己的流程进行分析的，所以可能有些地方写的不是很详细，导致看不懂，有看不懂的地方可以留言

CVE-2018-0802 影响的 Office 软件版本：

\x02 调试环境

虚拟机： VMware 15 Pro + Windows 7 旗舰版（关闭 ASLR && DEP）
漏洞软件： Office 2016 64位（提取码：fc1b）+ EQNEDT32.EXE（版本 2000.11.9.0）
公式编辑器插件： EQUATION(未打 CVE-2017-11882 补丁，提取码：behx) + EQUATION(打了 CVE-2017-11882 补丁，提取码：ck8o）
漏洞样本及 Python 制作脚本打包： CVE-2018-0802.zip（提取码：7x0x）
16进制编辑器： C32Asm（16进制分析文件工具，提取码：4sj8）
反汇编工具： x64dbg + IDA 7.2（提取码：zksm）
CVE-2017-11882 补丁地址： https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882
CVE-2018-0802 补丁地址： https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

注：CVE-2018-0802 是在 CVE-2017-11882 补丁的基础上触发的，换句话说就是必须满足存在 CVE-2017-11882 漏洞并且打上了补丁这两个条件才能触发 CVE-2018-0802。所以基于此点建议先研究分析 CVE-2017-11882 漏洞后再分析 CVE-2018-0802。

\x03 调试分析漏洞成因

首先搭建好基于 CVE-2017-11882 的环境，并且打上补丁，由此确保 CVE-2018-0802 能够触发。
使用 cve-2018-0802_poc.py 脚本生成 test.doc 样本文件。
双击 test.doc 样本，成功弹出计算器，这表明漏洞确实存在，并且在加载文档之前触发。下面就来研究一下为什么打开文档会弹出计算器吧…
先设置 x64dbg 为附加调试模式，这样就可以在 Office 载入 EQNEDT32.EXE 模块时自动开启调试器进行调试，这个也是调试子进程最方便的方法之一。
然后重新打开 test.doc 文档，调试器附加成功后在 WinExec 函数上下断点，因为弹出计算器的操作是由这个函数完成的。
由于之前分析过 CVE-2017-11882 这个漏洞，所以根据之前下的断点得出在 sub_421774 函数调用后会断在 WinExec 上，接下来对这个函数的返回值进行分析，判断问题是否出在 sub_421774 中。对 sub_421774 函数的开头和结尾下条件记录断点。
断点下好后，重新打开 test.doc 文档，得到日志如下图所示。经过分析可以得出 EQNEDT32.EXE 模块在运行期间多次调用了 sub_421774 函数。需要注意的是最后调用 sub_421774 时出现了问题（红圈圈中的），在 start 处压栈时压入的返回地址为 0x004214E2，但是在 end 出栈时返回地址却变成了 0x00420025，说明返回地址被恶意覆盖了，由此确定了 sub_421774 函数中存在内存泄漏的状况，下面开始调试该函数，查找是什么原因导致。
根据日志设置条件断点，在 start 处当 esp == 18F308 && [esp] == 4214E2 时断下，方便调试。
重新打开文档之后断在了 sub_421774 上，且满足 esp == 18F308 && [esp] == 4214E2 的条件。然后经过调试之后发现漏洞出现在 sub_421E39 这个函数中，因为执行完此函数后返回值会被覆盖，而 sub_421E39 函数中的复制字符串指令 rep 就是漏洞导致的根本原因，由于局部变量的大小为 0xAC，只要复制长度超过 0xAC 就会照成栈溢出。
查看 rep 指令执行结束后堆栈的状态，栈空间 sub_421774 函数的返回地址已经被覆盖成了 0x00420025。而且复制的数据是 font name 字符串地址，是通过参数传递进来的，如下图内存窗口所示：
样本中的对照数据如下图所示，该数据是嵌入在 RTF 文件的 \object 组中的，属于公式编辑器对象（OLE）。
然后运行到 sub_421774 的结尾处会进行 ret 返回操作。
待 sub_421774 函数返回之后成功劫持了程序的 EIP 并且运行到了 0x00420025 处。
最终实现了执行任意代码的目的（安全限制绕过及 shellcode 会在之后进行分析）。

\x04 CVE-2017-11882 补丁 + CVE-2018-0802 结合分析

既然 CVE-2018-0802 是在 CVE-2017-11882 补丁的基础上才会触发，那么来研究一下到底是为什么。对于打补丁和未打补丁之间的切换，直接更换 EQNEDT32.EXE 文件即可，别忘了做备份。
首先恢复到打补丁之前的版本，也就是能够触发 CVE-2017-11882 的版本，之后打开 CVE-2018-0802 看看会发生什么。由于之前的条件断点，所以运行之后断在了 sub_421774。
之后运行完 sub_421E39 后，由于复制的数据 font name（lpLogFont） 大于局部变量的大小 0xAC，所以导致栈溢出，返回值被覆盖为 0x00420025，到此为止没有任何问题。
接着运行到 sub_4115A7 函数处，F7 进入该函数，注意传入的参数为 font name 字段，
再运行到 sub_41160F 处，F7 再次进入，传入的参数为依然包括 font name 字段。
如下图所示，在 0x00411658 地址处就是 CVE-2017-11882 漏洞的触发点，rep 指令会将 font name 字段复制到当前函数的局部变量中，由于局部变量只有 0x28 大小，所以会再次造成栈溢出。
接着运行到 sub_44C430 函数处，F7 进入该函数。
在运行到如图所示的这条语句上时会导致异常，因为传入该函数的第二个参数已经被 font name 字段给覆盖了，导致 mov dl，byte ptr ds:[ecx] 读取了一个未知地址的数据，故触发异常。
异常导致程序直接运行到 0x7DE915EE 地址上，导致程序退出，从而不会运行到返回地址处。
运行流程图：
对比打上了 CVE-2017-11882 补丁之后的效果，运行完 sub_421E39 后触发了 CVE-2018-0802，返回地址被覆盖为 0x00420025。
接着进入到 sub_41160F 函数中，触发 CVE-2017-11882。
由于打上了补丁，所以会对 font name 字段的长度进行判断，如果 font name 字段的长度超过了 0x21，则将拷贝的长度限制为 0x20。
这样的话 sub_44C430 中的 mov dl，byte ptr ds:[ecx] 就不会触发异常，因为 ecx 没有被 font name 字段恶意覆盖，这也是为什么打了 CVE-2017-11882 补丁才能够触发 CVE-2018-0802 的根本原因。
接着就可以成功的运行到 sub_421774 函数的结尾并且跳转到 0x00420025 的地址当中去。
运行流程图：

注：在进行 CVE-2018-0802 和 CVE-2017-11882 双重 POC 构造时，如果在同一个对象中，就需要注意避开异常

\x05 安全限制绕过分析

如果原来没有开启系统的 ASLR 的话，需要开启 ASLR。本实验系统是 Windows 7，所以需要用 EMET（微软的增强减灾工具）来开启 ASLR，同时这个工具也可以关闭 ASLR。
如果同时开启了 DEP 的话，需要将其关闭，因为该样本无法绕过 DEP。
之后使用 Immunity Debugger 的 !mona modules 命令查看开启的防护，发现打上 CVE-2017-11882 补丁之后，开启了 ASLR。
下面看看样本是如何绕过 ASLR 的。打开 test.doc 样本之后，直接运行要 sub_421774 函数的返回处，此时栈中的返回地址已经被覆盖了。
对于 ASLR 的基本知识主要有两点，第一个是映像基址随机化，第二个堆栈地址随机化（还有一个就是 TEB/PEB 的随机化），对于 32 为程序，映像基址（模块基址）随机化只针对地址的前半部分，比如 0x00240035 只随机化 0x0024 的部分，而 0x0035 保持不变；而堆栈地址随机化相对于堆栈开辟来说则是全部随机化。
结合该样本分析，返回地址只是覆盖了地址的后半部分为 0x0025，为的是保留前半部分以绕过 ASLR。
然后 F8 运行，程序直接返回到了 0x00240025，该地址是一条 ret 指令（对于 ret 指令的选取，直接在模块中搜索该条指令即可）
接着继续 F8 单步运行，返回到了 0x001DF084 地址，该地址就是溢出的 font name 字段中的数据，这一步是完成内存数据到程序指令的转变。
指令 sub esp，edx 会将 esp 减去 0x200，这样做的目的是让 shellcode 使用未初始化过的栈空间，避免了对栈空间的破坏，让程序能够流畅的运行。
完成以上操作后，使用 F7 进入下图所示的 call 中，地址是 0x0051EC82，该地址储存着 shellcode。
shellcode 的实现很简单，利用线程环境块动态调用 WinExec API 函数，函数地址储存在 eax 中，参数储存在 ebx 中，由 jmp 指令进行调用。
样本中的 shellcode 如下所示：
最后会运行到 WinExec 的地址，进行打开计算器的操作。