\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
的地址,进行打开计算器的操作。
\x06 CVE-2018-0802 补丁分析
- 进入微软官网对照各个版本下载相应补丁,本实验的
Office
版本是2016(64bit)
,下载完成之后安装。
- 使用
IDA
直接定位到CVE-2018-0802
漏洞处,也就是sub_421E39
,之后对补丁进行分析。但是好像并没有什么变化。
- 且运行之后还是能弹出计算器。
- 再次安装更新也显示此系统已经安装了更新。
- 额,不知道是为什么,但是鉴于上面的情况,建议开启系统的
DEP
防护来缓解CVE-2018-0802
的危害…
关于 CVE-2018-0802 的漏洞分析到此结束,如有错误,欢迎指正