【技术分享】CVE-2017-8759的几种利用新姿势

前言

CVE-2017-8759是FireEye在今年8月底报告给微软的一个office 0day，该漏洞是一个因.Net WSDL解析器处理soap语句不当而导致的代码注入漏洞，由于其通用性和易用性，公布以来一直有新的野外利用样本出现。近日，360核心安全事业部高级威胁应对平台捕获一批利用CVE-2017-8759的新样本，通过分析这些样本，我们观察到一些有趣的利用新姿势，下面来和大家分享一下。

姿势1：CVE-2017-0199和CVE-2017-8759组合使用

MD5: 9e4596584e6782298421a32d2264d76d

最近国外的一篇博客《A short journey into DarkVNC attack chain》所提到的样本就是该姿势样本中的一个。该样本是一个带混淆的rtf文件，里面嵌入若干ole对象，其中一个ole对象利用CVE-2017-0199(CVE-2017-0199为FireEye在今年年初发现的另一个office 0day)去远程下载一个HTA文档并执行，另一个ole对象利用CVE-2017-8759去远程下载一个WSDL文档并执行。该文档带有大量的回车符换行符及制表符，并带有轻微混淆，如图1所示：

图1

删除回车换行和制表符，并且去混淆后，我们看到图2所示内容：

图2

其中内嵌的CLSID: 00000300-0000-0000-C000-000000000046所对应的含义如图3所示，可以看到它代表StdOLeLink，这代表该ole对象为一个链接对象，文档中还带有objautlink和objupdate控制字，在RTF格式规范中这两个控制字的作用如图4所示，目的是为了让rtf文档在打开时自动更新链接，从而在无须用户交互的情况下就可以直接下载并执行远程文件。这点在今年4月已经被国外的安全人员讨论过，见参考链接中的《exploiting-cve-2017-0199-hta-handler-vulnerability》一文。

图3

图4

我们从去混淆后的rtf文档中提取出两个ole对象，其中一个ole对象利用了CVE-2017-0199 (HTA)漏洞，如图5所示：

图5

图中蓝色部分是一个CLSID，代表了当前的Moniker类型，该Moniker的类型如图6所示，可以看到这是一个URL Moniker。关于Miniker的更多细节请参考HaifeiLi在2017年syscan360西雅图会议的演讲《Miniker Magic: Running Scripts Directly in Microsoft Office》

图6

图5中网址对应的文件其实是一个hta文件，里面的内容如图7所示，该文件带有一定的混淆，这里对文件内容不详细展开。

图7

另一个ole对象利用了CVE-2017-8759漏洞，如图8所示，蓝色部分为其对应的CLSID: ecabb0c7-7f19-11d2-978e-0000f8757e2a，它代表SOAP Moniker，如图9所示。

图8

图9

图9中网址对应的是一个WSDL文件，其内容如图10所示，注意红框圈出来的CRLF符，

图10

由于CVE-2017-8759漏洞，该WSDL文件在被.Net WSDL解析器解析完后得到的cs文件如图11所示，红框圈出部分为由于WSDL解析器在解析CRLF时处理不当导致被注入的代码，该代码被如图12的编译选项编译后，会在SOAPAssembly目录下得到一个以URL名称命名的dll及对应的pdb符号文件，如图13所示。其模块信息如图14所示，所创建进程名称及相应的栈回溯如图15所示。

图11

图12

图13

图14

图15

所获取的t.hta文件内容与第一个ole对象所获取的远程bbs.doc内容完全一样。

我们的平台捕获到的该样本的进程树信息如图16所示。

图16

姿势2：通过外部链接远程获取CVE-2017-8759利用样本并执行

MD5: 13d72363a5f8fcec2e6fb124edb9e4d4

该样本是一个docx文档，里面链接了一个远程rtf文档，当打开该docx文档时，远程的rtf文档将会被拉取并打开，从而触发CVE-2017-8759漏洞。为什么要搞得这么麻烦呢？当然是为了躲避静态检测，我们看到该文档在VT上的检出率情况，可以看到一开始提交到VT时该样本检出率只有2/61，如图17所示，而且静态根本检测不出它后面利用了CVE-2017-8759，最多只能检测出该文档链接有远程对象。

图17

该文档在word_relsdocument.xml.rels文件中指定了一个远程文档，如图18所示，这个所谓的mee.doc文件是一个内嵌ole对象的rtf文档，从文档中提取的ole对象中我们发现了如图19的内容，这显然是利用了CVE-2017-8759。

图18

图19

图19中的网址对应的mee.png文件是一个远程wsdl文件，有意思的是，与之前的8759利用方式相比，该wsdl文件并没有去加载一个远程hta文件，而是直接将需要执行的代码全部写在了wsdl文件内，如图20(为方便查看，图20中对代码做了对齐)所示，且代码量达到千行以上，如图21所示，编译后得到的cs文件如图22所示：

图20

图21

图22

我们的平台最终捕获到该样本的进程树如图23所示：

图23

姿势3：通过略微修改WSDL文件中的首个soap语句导致代码执行流上的改变

MD5: 607e8ae8bf2e3986636f4a82deab1143

我们的平台捕获到一系列直接将执行代码内嵌在wsdl里的样本，特别地，我们注意到一个样本下载的wsdl文件的后续代码执行流与其他样本不太一样，这引起了我们的好奇。先给出该样本执行payload时的栈回溯和其对应的命令行，如图24所示，读者可以自行将图24与图15进行对比，两者在执行流上并不一样，我们不禁要问，这是为什么？

图24

我们查看了这个样本下载的wsdl文件内容，发现cmd.exe对应的命令行被写在如图25中红框圈出的第一个soap语句中，这个地方的代码在我们观察到的其他wsdl文件中要么为空，要么指定了mshta.exe的路径。而该文件在此处用cmd启动了一个powershell进程，这导致创建进程的执行流发生了变化。是否还有更多的执行流呢？这等待研究人员去发现。

图25

我们的平台跑出该样本的进程树如图26所示:

图26

姿势4：通过EML进行传播，并通过PPSX进行利用

MD5: 34f9727770392845ff9ab0912cb8b81c

我们观察到一些利用EML进行传播的CVE-2017-8759样本，其中两个EML的信息如图27，图28所示，可以看到这些钓鱼邮件利用订单回复，汇款证据为诱饵进行CVE-2017-8759样本的投放，时间为最近一周。

图27

图28

图27中后缀名为PPSX的文件是一个CVE-2017-8759样本，尽管国外的安全研究人员有过这方面的讨论，但这种方式此前在野外并不常见。该ppsx文件在pptslides_rels slide1.xml.rels文件中直接指定了远程的wsdl文件路径，如图29所示，下载下来的wsdl文件与姿势2以及姿势3的高度相似，都为在wsdl文件中直接写入执行代码，此处不再展示。