在2017年11月14日，微软发布11月份安全补丁更新，其中更新了潜伏17年之久的Office远程代码执行漏洞(CVE-2017-11882) “噩梦公式一代“，而在2018年1月，又爆出了office 0day漏洞(CVE-2018-0802),该漏洞的技术原理类似17年修补的漏洞，是由于office公式编辑器组件EQNEDT32.EXE，对字体名的长度没有进行长度检验，导致攻击者可以通过构造恶意的字体名，执行任意代码。

基本情况:
漏洞的形成 是出现在 模块 EQNEDT32.EXE 中 ，在Office 的安装过程中被默认安装 该模块 以OLE技术 将公式 嵌入 Office 文档中

Object Linking and Embedding （OLE ，对象链接与嵌入）
是能让应用程序创建包含不同来源的复合文档的一项技术。 OLE 不仅是桌面应用程序集成，而且还定义了和实现一种允许应用程序作为软件”对象”(数据集合和操作数据的函数)彼此进行”链接”的机制 , 这种链接机制和协议称为部件对象模型(Component Object Mode) 简称COM。 OLE 可以用来创建复合文档 ，复合文档包含了创建于不同源应用程序 有着不同的数据类型 , 因此它可以 把 文字 、声音、图像、表格、应用程序等组合在一起。
-----来自维基百科

关于Equation Native 数据结构
在公式编辑器3.x(所有平台) 使用了 MTEF v.3 的二进制 格式进行存储
本漏洞的触发数据位于所提取OLE 对象的 “Equation Native” 流中

根据网上资料 关于这个结构的详细信息可以在底下的参考 网站里面查看

EqiationNative StreamData = EQNOLEFILEHDR +MTEFDATA
其头结构为：

对照漏洞样本 该结构如下

而紧接着的是MTEFDATA ，MTEFData 是由 MTEF 头和 MTEF字节流 组成
MTEF 头内容 为:

MTEF 字节流 包括一系列的记录 都以包含记录类型和一些标志位的标签字节开始 ，标签位的低4位 描述该记录的属性后续 紧跟标签的内容数据 ，而本漏洞发生栈溢出的部分位于字体标签

MTEF DATA 结构

分析 漏洞函数 可以看到在初始化LOGFONT 结构时，拷贝字体名没有进行长度限制 造成了溢出

OD 动态调试

当打开 样本文件 时 可以看到

关于没有打17年补丁 测试会崩溃的情况

从ida分析可以看到 之后 会调用 API 获取系统字体名 和用户提供lpLogfont 进行比较，在这时 间接的调用了 17年的漏洞，如果没有安装17补丁 将会在这里崩溃

根据这个没有长度限制的拷贝，证明可以在此处构造一个栈溢出 ，不过拷贝的起始地址位于上一个调用函数的栈帧中，所以 利用这个函数实现覆盖返回地址是不行的，只有覆盖上一个栈桢的函数返回地址 ，通过计算 据上一个函数栈桢返回地址相差0x94
12F304-12F270 =0x94 ,我们只需要覆盖 0x94个字节 就可以覆盖上一个函数的返回地址

上一个函数栈桢

此时 就可以 构造一个长度为0x94字节的 内容的shellcode 然后覆盖返回地址 ，来劫持程序执行流程

可以看到 覆盖上一个函数栈桢里返回地址 下面 就是 我们构造 源数据 ,此时 我们只需要一个 retn ，返回到 我们构造源数据的地方 。因为CVE-2017-11882的原因，微软对公式编辑器 开启了动态随机基址(ALSR) 而没有开启DEP

不过 随机基址 通常只随机 高两位地址,而在内存中 是 小端排序 ,覆盖是从低两位开始 在进行拷贝时又要 用NULL 进行截断 ,综上原因 需要寻找 一盒 具有 0xYYXX00ZZ 格式的retn 指令

而正好 在函数内部 有这个 格式的地址
整个shellcode 布局如下

由于shellcode空间只有 0x94个字节，空间有限 因此我们可以利用 进程中WinExec函数来完成其它程序调用

函数两次返回 ,返回到我们构造的字体名的源缓冲区执行代码，而源缓冲区为我们的shellCode最终 触发情况

此次爆发的漏洞 利用手法 相对简单 ，但破坏性 不能忽视 ，建议各用户赶紧打上补丁 ，防止被攻击利用 ，而在最新的补丁中 已经 彻底放弃 EQEDT32.EXE 文件 ，彻底杜绝了利用该漏洞攻击的行为

在2017的漏洞中 文件版本信息为 2000.11.9

具体结构前面以说明，对poc 通过ole 工具进行分析

poc equation native 对象分析
1.1 对poc文档提取ole 对象

1.2 查看ole 对象的目录结构

可以看到 该ole 对象 使用了 Equation Native 流
1.3 查看Equation Native 流

因为不知漏洞点在哪，可以看到该poc 有cmd.exe/calc.exe ，因为windows调用外部命令 一般使用winexec 函数 ，通过windbg附加调试运行eqnedt32.exe并在此设置断点

打开poc 可以看到以断下

可以看到 WinExec的返回地址 为00430c18 调用 地址为0x430c12 查看下POC记录着0x430c12

这期间很明显发生了覆盖了函数返回地址 ，函数直接返回到了 WinExec
通过调用堆栈 可以上一级的返回地址 是在 0x4218e4 之后通过IDA 查看 这个地址

可以看到这个地址 在函数 sub_421774中 ，程序在调用sub_4115A7 没能正确的返回
IDA 查看此函数

可以看到 关键函数sub_41160F
之后对 0x4218DF 下断 进行动态调试


根据调试 可以看到 这个函数的第一个参数为字体名 ， 此时的字体名是 伪造的恶意数据

在这里 将esi 数据拷贝到 edi

最后在返回的时候 返回地址 已经被淹没成 WinExec的地址 ，而在进行pop返回过后 ，WinExec的参数 就是构造恶意代码的地址
关于此程序的保护措施 此漏洞没有任何的保护措施 之后在爆发后才添加了ASLR

查看下 拷贝过去 edi 分配的大小

通过IDA 可以看到 分配空间为 0x24 ，当构造的数据超过0x24时就会产生有溢出 ,如果要淹没返回地址 就需要构造 0x24+0x4+0x4=0x2c的数据 也就是96个字符串

MTEF V.3 详细介绍
http://rtf2latex2e.sourceforge.net/docs.html
一个二进制POC 的诞生之旅
http://www.freebuf.com/vuls/160115.html
POC 链接
https://github.com/rxwx/CVE-2018-0802

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课