谈谈Office Moniker类漏洞和公式编辑器类漏洞

阅读量    110958 | 评论 1

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

在近几年出现的诸多office漏洞中,有两类漏洞是很值得谈谈的,第一类是Moniker导致的逻辑漏洞,第二类是公式编辑器漏洞。

对于第一类漏洞,其重点在于攻击者和微软安全团队之间的攻防过程,了解这类漏洞攻防过程对威胁追踪与研究较有益处:

  1. 第一回合:CVE-2017-0199,用URL Moniker加载远程HTA文件实现远程代码执行;
  2. 第二回合:CVE-2017-8570,用CompositeMoniker、FileMoniker、NewMoniker、scriptletfile实现远程代码执行;
  3. 第三回合:CVE-2017-8759,用office文档加载.Net组件漏洞,实现远程代码执行;
  4. 第四回合:CVE-2018-8174,用office文档加载IE VBScript组件漏洞,实现远程代码执行;
  5. 第五回合:CVE-2020-0674,用office文档加载IE JavaScript组件漏洞,实现远程代码执行。

对于第二类漏洞,其难点在于对相似漏洞之间的区分。从CVE-2017-11882开始,到CVE-2018-0802,再到CVE-2018-0798,三个都是非常相似的漏洞,在静态层面不容易区分,本文将分享一个在动态层面区分它们的方法。

下面跟随笔者一起来看一下这两类漏洞。

 

Moniker类漏洞

第一回合:CVE-2017-0199

2017年4月7日,著名office漏洞研究员李海飞发布了一篇在野0day攻击预警,首度披露了CVE-2017-0199漏洞的在野攻击。随后,2017年4月11日和12日,FireEye连发两篇文章,披露了他们捕获到的CVE-2017-0199漏洞样本细节。后续的披露表明这几篇文章中披露的漏洞是一种借助URL Moniker特性加载远程hta文件的新型漏洞,这是一个由于开发者对office文件加载机制设计不合理导致的逻辑漏洞,且要求触发环境安装IE10/IE11。漏洞触发过程不需要用户交互,但在触发的过程中会弹出一个对话框,不点击或者点击任意该对话框的按钮都不影响执行过程,对话框样式如下:

该漏洞的发现者之一李海飞曾经在Syscan360 2017会议上做过题为《Moniker Magic: Running Scripts Directly in Microsoft Office》的演讲,里面详细介绍了CVE-2017-0199的细节,包括:

  1. 微软在CVE-2017-0199的补丁中修复了两个漏洞,分别是被在野利用的RTF URL Moniker加载远程HTA文件的远程代码执行漏洞,和李海飞独立发现的PPSX Script Moniker远程代码执行漏洞;
  2. office安全团队在这两个漏洞的基础上设计了一类针对Moniker的黑名单机制,禁用了一些他们觉得不安全的Moniker。

Moniker本身是office的一个特性,可以用来链接一些本地或远程对象,其本身不属于漏洞,漏洞发生在office软件对远程链接的文件的执行策略上。譬如,如果远程加载的是一个Excel文件,直接打开没问题;但如果加载的是HTA文件和Script这类脚本文件时,直接执行就存在问题了,导致了漏洞。

第二回合:CVE-2017-8570

在对CVE-2017-0199补丁的研究过程中,李海飞发现(上面也已经提到):

  • office安全团队在这CVE-2017-0199的补丁中设计了一类针对Moniker的黑名单机制,禁用了一些他们觉得不安全的Moniker。

于是他开始寻找那些还没有被禁用的Moniker,尝试用那些没有被禁用的Moniker构造出另一个逻辑漏洞,结果确实找到一个,即CVE-2017-8570。

在CVE-2017-0199中,用到的Moniker是下面这两个:

3050F4D8-98B5-11CF-BB82-00AA00BDCE0B // htafile
06290BD3-48AA-11D2-8432-006008C3FBFC // scriptlet(or ScriptMoniker)

而在CVE-2017-8570中,用到的Moniker是下面这几个:

00000309-0000-0000-C000-000000000046 // CompositeMoniker
00000303-0000-0000-C000-000000000046 // FileMoniker
ECABAFC6-7F19-11D2-978E-0000F8757E2A // NewMoniker
06290BD2-48AA-11D2-8432-006008C3FBFC // scriptletfile(or ScripletFactory)

可以看到CVE-2017-8570利用未被加入黑名单的Moniker绕过了CVE-2017-0199的补丁。

不过,许多分析过CVE-2017-8570的读者可能会观察到一个奇怪的现象:漏洞中触发时script脚本中的代码会被执行两次。这是为什么呢?原来,在这个漏洞的触发逻辑中,会涉及到wwlib.dll库中的一个函数调用,该函数内部会顺序调用ole32!CDefLink::BindToSource和ole32!CDefLink::Update两个函数,如下(以office 2010为例):

而这两个函数最终都会调用kernel32!CreateProcessW创建进程,所以script脚本中的代码会被执行两次。其中ole32!CDefLink::BindToSource创建进程的栈回溯如下:

0:000> k 50
ChildEBP RetAddr  
0013a5b4 729cd2f5 kernel32!CreateProcessW
0013a63c 729cd5f7 wshom!CreateNewProcessW+0x6f
0013a69c 76da3e75 wshom!CWshShell::Exec+0x19a
0013a6bc 76da3cef OLEAUT32!DispCallFunc+0x165
0013a74c 729d0267 OLEAUT32!CTypeInfo2::Invoke+0x23f
...cut...
0013ae9c 7705b5dc comsvcs!CNewMoniker::BindToObject+0x14f
0013aed0 770c3cc6 ole32!CCompositeMoniker::BindToObject+0x105 [d:\w7rtm\com\ole32\com\moniker2\ccompmon.cxx @ 1104]
0013af3c 68ee87ce ole32!CDefLink::BindToSource+0x1bf [d:\w7rtm\com\ole32\ole232\stdimpl\deflink.cpp @ 4637]
0013af80 68a61429 wwlib!wdGetApplicationObject+0x69230 // 第一处调用
0013b010 68a23b2c wwlib!DllGetLCID+0x4753b3
...cut...

而ole32!CDefLink::Update创建进程的栈回溯如下:

0:000> k 50
ChildEBP RetAddr  
0013a57c 729cd2f5 kernel32!CreateProcessW
0013a604 729cd5f7 wshom!CreateNewProcessW+0x6f
0013a664 76da3e75 wshom!CWshShell::Exec+0x19a
0013a684 76da3cef OLEAUT32!DispCallFunc+0x165
0013a714 729d0267 OLEAUT32!CTypeInfo2::Invoke+0x23f
...cut...
0013ae68 7705b5dc comsvcs!CNewMoniker::BindToObject+0x14f
0013ae9c 770c3c55 ole32!CCompositeMoniker::BindToObject+0x105 [d:\w7rtm\com\ole32\com\moniker2\ccompmon.cxx @ 1104]
0013af08 7710f7ee ole32!CDefLink::BindToSource+0x14e [d:\w7rtm\com\ole32\ole232\stdimpl\deflink.cpp @ 4611]
0013af30 7710f42a ole32!CDefLink::Update+0x62 [d:\w7rtm\com\ole32\ole232\stdimpl\deflink.cpp @ 5347]
0013af44 68ee8830 ole32!CDefLink::Update+0x33 [d:\w7rtm\com\ole32\ole232\stdimpl\deflink.cpp @ 2695]
0013af80 68a61429 wwlib!wdGetApplicationObject+0x69292 // 第二处调用 
0013b010 68a23b2c wwlib!DllGetLCID+0x4753b3
...cut...

第三回合:CVE-2017-8759

在CVE-2017-8570漏洞被修复后,累计有如下这些Moniker被加入黑名单:

3050F4D8-98B5-11CF-BB82-00AA00BDCE0B // htafile
06290BD3-48AA-11D2-8432-006008C3FBFC // scriptlet(or ScriptMoniker)
00000309-0000-0000-C000-000000000046 // CompositeMoniker
00000303-0000-0000-C000-000000000046 // FileMoniker
ECABAFC6-7F19-11D2-978E-0000F8757E2A // NewMoniker
06290BD2-48AA-11D2-8432-006008C3FBFC // scriptletfile(or ScripletFactory)

在前面几个Moniker不能使用之后,攻击者又注意到了下面这个Moniker:

ecabb0c7-7f19-11d2-978e-0000f8757e2a // SOAPMoniker

SOAP Moniker可以用来加载一个远程的SOAP配置文件,当Word进程远程加载这个配置文件时,.Net组件会被加载用来解析对应的配置文件,并按照配置自动生成一个C#文件,再自动将该C#文件编译得到一个动态链接库并执行。攻击者借助.Net SOAP WSDL模块中的一个代码注入漏洞(CVE-2015-8759),将恶意脚本代码注入到了待编译的C#文件中,从而让编译得到的动态链接库包含恶意代码并自动执行。

从CVE-2017-8759开始,攻击者开始借助office组件与其他Windows组件之间的交互进行攻击。.Net的漏洞本身不属于office的范围,却可以借助office文档进行触发,这种攻击方式当时给笔者留下了深刻的印象。

第四回合:CVE-2018-8174

CVE-2017-8759被修复后,Moniker黑名单又得到了更新:

3050F4D8-98B5-11CF-BB82-00AA00BDCE0B // htafile
06290BD3-48AA-11D2-8432-006008C3FBFC // scriptlet(or ScriptMoniker)
00000309-0000-0000-C000-000000000046 // CompositeMoniker
00000303-0000-0000-C000-000000000046 // FileMoniker
ECABAFC6-7F19-11D2-978E-0000F8757E2A // NewMoniker
06290BD2-48AA-11D2-8432-006008C3FBFC // scriptletfile(or ScripletFactory)
ecabb0c7-7f19-11d2-978e-0000f8757e2a // SOAPMoniker

在上面这些Moniker都不可用之后,攻击者又想出了一种新的攻击方式:借助URL Moniker去加载远程html文件,这样就可以借助office加载IE漏洞。攻击者首先用URL Moniker+CVE-2014-6332的组合试了一下该方案的可行性,笔者追溯到的这方面的最早样本为2018年1月17日的下面这个文件(以及相关文件):

// CVE-2014-6332
Document MD5: A9D3F7A1ACD624DE705CF27EC699B6B6
URL Moniker: hxxp://s.dropcanvas[.]com/1000000/940000/939574/akw.html
akw.html MD5: C40A128AE7AEFFA3C1720A516A99BBDF

到了2018年4月,攻击者终于按捺不住了,借助URL Moniker+IE VBScript 0day的方式对特定目标进行了攻击,这次攻击所用漏洞就是著名的CVE-2018-8174,相关样本如下:

// CVE-2018-8174
Document MD5: b48ddad351dd16e4b24f3909c53c8901
URL Moniker: hxxp://autosoundcheckers[.]com/s2/search[.]php?who=7
search.htm MD5: 15eafc24416cbf4cfe323e9c271e71e7

CVE-2018-8174出现后,微软安全团队并未直接将office加载VBScript脚本的功能进行限制。随后,在2018年7月,攻击者又借助另一个IE VBScript 0day(CVE-2018-8173),用相同的方式实施了攻击。

这下微软不淡定了,赶紧对Office加载VBScript脚本进行了限制。

第五回合:CVE-2020-0674

故事到这里就结束了吗?当然没有。此时,微软依然没有限制office加载JavaScript脚本,所以IE浏览器的两个JavaScript引擎:JScript和JScript9依然可以通过此种方式进行攻击。

其一,据笔者所知,在2018年的天府杯上,针对office项目的攻击采用了URL Moniker + IE JScript9 0day的组合。

其二,2019年-2020年,由于几个JScript漏洞被相继披露,陆续有APT攻击组织使用URL Moniker + JScript 1day的方式实施攻击,相关样本如下:

// CVE-2020-0674
Document MD5: 90403dfafa3c573c49aa52c5fe511169
URL Moniker: hxxp://tsinghua.gov-mil[.]cn/images/A96961AA/36604/1836/65449576/ab8feee
ab8feee MD5: 1892D293030E81D0D1D777CB79A0FDBE

// CVE-2020-0968
Document MD5: 60981545a5007e5c28c8275d5f51d8f0
URL Moniker: hxxp://94.156.174[.]7/up/a1a.htm
a1a.htm MD5: 293916af3a30b3d7a0dc2949115859a6

于是微软在高版本office中(office2016及以上版本)也加入了对JScript9脚本和JScript脚本的加载限制。

至此,攻击者针对Moniker的所有尝试都被微软进行了封堵,此后未观察到针对Moniker的新攻击方式。

 

公式编辑器漏洞

2017年11月补丁日,国外安全公司_embedi发表了一篇《SKELETON IN THE CLOSET: MS Office vulnerability you didn’t know about》详细描述了他们发现office公式编辑器漏洞CVE-2017-11882的整个过程(笔者发现这家公司的官网已经挂了…)。

属于office公式编辑器漏洞的时代至此开启。

由于组件源码的丢失,微软的补丁开发人员花了较长时间来修复这一漏洞,并且以一种近乎炫技的方式,直接在二进制层面对程序作了修补,在没有重新编译源码的情况下修复了漏洞,并添加了ASLR支持。

然而,一时激起千层浪,CVE-2017-11882出现后,广大安全研究员蜂拥而至,都开始关注office公式编辑器这一组件,这直接导致微软在2018年1月的更新中砍掉了公式编辑器组件。

在第二次修复的诸多office公式编辑器漏洞中,有两个漏洞比较值得注意,这两个漏洞分别为CVE-2018-0802和CVE-2018-0798,三个漏洞并称为office公式编辑器漏洞领域的“三驾马车”,

由于笔者经常看到分析人员对这三个漏洞的样本进行误判,所以这里分享一种在动态层面区分这三个漏洞的方法。

首先跟随笔者来了解一下这三个漏洞的具体成因,下文中的汇编代码基于以下公式编辑器组件:

eqnedt32.exe 2000.11.9.0

在office中,公式编辑器的数据被存储在一个OLE文件的“Equation Native”流中,三个公式编辑器漏洞都是在处理这个流的数据时出现的问题。

CVE-2017-11882

首先来看一下CVE-2017-11882。

该漏洞的成因为:在读入“Equation Native”流中的Font Name Record数据时,在将Name拷贝到某个局部变量的时候没有对Name的长度做校验,从而造成栈缓冲区溢出,漏洞发生点如下图所示:

从下图可以看出,函数给SrcStr变量分配的大小是0x24个字节,Name长度超过该大小就会造成栈溢出。

CVE-2017-11882的触发逻辑如下所示:

CVE-2018-0802

再来看一下CVE-2018-0802。

该漏洞的成因为:在将“Equation Native”流中的Font Name Record数据拷贝到一个LOGFONT结构体(位于栈上)内的lfFaceName成员(它是一个以空结尾的char型字符串,最大长度为0x20,其中包含终止符NULL),没有对Name的长度做校验,从而造成栈缓冲区溢出,漏洞发生点如下图所示:

CVE-2018-0802漏洞的触发路径和CVE-2017-11882有很大的重叠,下图可以做一个直观的比对:

由于某些限制,CVE-2018-0802在未打CVE-2017-11882补丁的版本上只会造成crash,但在打了补丁的版本上可以实现远程代码执行。

CVE-2018-0798

最后看一下CVE-2018-0798。

该漏洞的成因为:在读入“Equation Native”流中的Matrix Record数据时,存在一处while循环内的数据读取操作,由于未对Matrix的行和列两个参数进行校验,从而使攻击者可以控制由此计算得到的拷贝长度,导致栈缓冲区溢出:

上述汇编片段描述了一个while循环,反汇编成伪代码如下,攻击者可以控制伪码中v2的大小,从而导致了数据读写越界:

上述代码位于sub_443F6C函数内,所以理论上只要调用sub_443F6C函数的地方均存在CVE-2018-0798漏洞。作为与之前两个漏洞的对比,在之前两个漏洞的基础上加入CVE-2018-0798的触发路径如下:

动态区分三个公式编辑器漏洞

以上笔者已经介绍了三个公式编辑器漏洞的成因,借助上述知识,很容易在调试器中确认特定样本使用的漏洞,判定方式如下:

// CVE-2017-11882
.text:00411655 C1 E9 02                shr     ecx, 2 // 获取此偏移处的ecx值,若ecx的值位于(0x20, 0x94]区间,即为CVE-2017-11882
.text:00411658 F3 A5                   rep movsd
.text:0041165A 8B C8                   mov     ecx, eax
.text:0041165C 83 E1 03                and     ecx, 3

// CVE-2018-0802
.text:00421E5B C1 E9 02                shr     ecx, 2 // 获取此偏移处的ecx值,若ecx的值大于0x94,即为CVE-2018-0802
.text:00421E5E F3 A5                   rep movsd
.text:00421E60 8B C8                   mov     ecx, eax
.text:00421E62 83 E1 03                and     ecx, 3
.text:00421E65 F3 A4                   rep movsb

// CVE-2018-0798
.text:00443F79 8D 04 45 02 00 00 00    lea     eax, ds:2[eax*2]
.text:00443F80 83 C0 07                add     eax, 7
.text:00443F83 C1 F8 03                sar     eax, 3
.text:00443F86 66 89 45 08             mov     [ebp+arg_0], ax // 获取此偏移处的eax值,若eax的值大于4,即为CVE-2018-0798

有些样本会同时满足上述两个或三个条件,因为这些样本中内嵌多个公式编辑器漏洞利用。

延伸

细心的读者会发现2020年极棒大赛上使用的某国产软件公式编辑器漏洞和CVE-2018-0798基本一样,有兴趣的读者可以自行对比研究。

 

参考链接

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/critical-office-zero-day-attacks-detected-wild/
https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html
https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199_useda.html
https://0b3dcaf9-a-62cb3a1a-s-sites.googlegroups.com/site/zerodayresearch/Moniker_Magic_final.pdf
http://justhaifei1.blogspot.com/2017/07/bypassing-microsofts-cve-2017-0199-patch.html
https://www.fireeye.com/blog/threat-research/2017/09/zero-day-used-to-distribute-finspy.html
https://securelist.com/root-cause-analysis-of-cve-2018-8174/85486/
https://ti.dbappsecurity.com.cn/blog/index.php/2020/07/13/sidewinder-new-attack-target-cn/
https://ti.dbappsecurity.com.cn/blog/index.php/2020/09/18/operation-domino/
https://support.microsoft.com/en-us/help/4058123/security-settings-for-com-objects-in-office
https://www.anquanke.com/post/id/87311
https://www.anquanke.com/post/id/94210
https://www.freebuf.com/vuls/160409.html

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多