Office 0day（CVE-2018-0802与2017-11882）漏洞分析与利用
1. 背景介绍
在2017年11月14日，微软发布11月份安全补丁更新，其中更新了潜伏17年之久的Office远程代码执行漏洞(CVE-2017-11882) “噩梦公式一代“，而在2018年1月，又爆出了office 0day漏洞(CVE-2018-0802)，该漏洞的技术原理类似17年修补的漏洞，是由于office公式编辑器组件EQNEDT32.EXE，对字体名的长度没有进行长度检验，导致攻击者可以通过构造恶意的字体名，执行任意代码。
2. 漏洞介绍
漏洞编号: CVE-2018-0802
危险等级: 高危
漏洞类型: 任意代码执行
影响版本:
Microsoft Office 2007 Service Pack3
Microsoft Office 2010 Service Pack2 (32)
Microsoft Office 2010 Service Pack2 (64)
Microsoft Office 2013 Service Pack1 (32)
Microsoft Office 2013 Service Pack1 (64)
Microsoft Office 2016 (32)
Microsoft Office 2016 (64)
3. 前置知识
基本情况：
漏洞的形成 是出现在 模块 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 结构
4.漏洞分析
分析 漏洞函数 可以看到在初始化LOGFONT 结构时，拷贝字体名没有进行长度限制 造成了溢出
OD 动态调试
当打开 样本文件 时 可以看到
关于没有打17年补丁 测试会崩溃的情况
从ida分析可以看到 之后 会调用 API 获取系统字体名 和用户提供lpLogfont 进行比较，在这时 间接的调用了 17年的漏洞，如果没有安装17补丁 将会在这里崩溃。
5. 漏洞利用
根据这个没有长度限制的拷贝，证明可以在此处构造一个栈溢出 ，不过拷贝的起始地址位于上一个调用函数的栈帧中，所以 利用这个函数实现覆盖返回地址是不行的，只有覆盖上一个栈桢的函数返回地址 ，通过计算 据上一个函数栈桢返回地址相差0x94
12F304-12F270 =0x94 ,我们只需要覆盖 0x94个字节 就可以覆盖上一个函数的返回地址
上一个函数栈桢
此时 就可以 构造一个长度为0x94字节的 内容的shellcode 然后覆盖返回地址 ，来劫持程序执行流程。
可以看到 覆盖上一个函数栈桢里返回地址 下面 就是 我们构造 源数据 ,此时 我们只需要一个 retn ，返回到 我们构造源数据的地方 。因为CVE-2017-11882的原因，微软对公式编辑器 开启了动态随机基址(ALSR) 而没有开启DEP
不过 随机基址 通常只随机 高两位地址,而在内存中 是 小端排序 ,覆盖是从低两位开始 在进行拷贝时又要 用NULL 进行截断 ,综上原因 需要寻找 一盒 具有 0xYYXX00ZZ 格式的retn 指令
而正好 在函数内部 有这个 格式的地址，整个shellcode 布局如下：
由于shellcode空间只有 0x94个字节，空间有限 因此我们可以利用 进程中WinExec函数来完成其它程序调用。
函数两次返回，返回到我们构造的字体名的源缓冲区执行代码，而源缓冲区为我们的shellCode最终触发情况。
6.结语
此次爆发的漏洞 利用手法 相对简单 ，但破坏性 不能忽视 ，建议各用户赶紧打上补丁 ，防止被攻击利用 ，而在最新的补丁中 已经 彻底放弃 EQEDT32.EXE 文件 ，彻底杜绝了利用该漏洞攻击的行为
CVE-2017-11882的分析
在2017的漏洞中 文件版本信息为 2000.11.9
POC 分析
具体结构前面以说明，对poc 通过ole 工具进行分析
1. 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 可以看到以断下
0:000> kb
ChildEBP RetAddr Args to Child
0012f1cc 00430c18 0012f350 00000000 0012f1ec kernel32!WinExec
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f210 004218e4 0012f350 0012f5e0 0012f7e4 eqnedt32!MFEnumFunc+0x241b
0012f300 004214e2 0012f350 0000005a 00000001 eqnedt32!FMDFontListEnum+0x650
0012f32c 0043b466 0012f350 0000005a 0012f5e0 eqnedt32!FMDFontListEnum+0x24e
0012f454 0043a8a0 0012f5e0 0012f7e4 00000006 eqnedt32!MFEnumFunc+0xcc69
0012f46c 0043a72f 00120008 0012f5e0 0012f7e4 eqnedt32!MFEnumFunc+0xc0a3
0012f484 0043a7a5 00120008 0012f4ac 0012f5e0 eqnedt32!MFEnumFunc+0xbf32
0012f4b4 00437cea 00120008 002972ee 00120000 eqnedt32!MFEnumFunc+0xbfa8
0012f4e4 0043784d 002972ee 00000000 0012f5e0 eqnedt32!MFEnumFunc+0x94ed
0012f548 0042f926 0012f560 0012f5e0 0012f7e4 eqnedt32!MFEnumFunc+0x9050
0012f578 00406a98 024b00bc 0012f5e0 0012f7e4 eqnedt32!MFEnumFunc+0x1129
0012f5dc 75bafc8f 0029f328 02b10570 00000202 eqnedt32!AboutMathType+0x5a98
0012f5f8 75c14c53 00406881 0012f7e8 00000002 RPCRT4!Invoke+0x2a可以看到 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个字符串
POC 结构
参考文章
MTEF V.3 详细介绍
http://rtf2latex2e.sourceforge.net/docs.html一个二进制POC 的诞生之旅
http://www.freebuf.com/vuls/160115.htmlPOC 链接
https://github.com/rxwx/CVE-2018-0802
看雪ID：Cestlavie呀
bbs.pediy.com/user-806349
本文由看雪论坛 Cestlavie呀 原创
转载请注明来自看雪社区