CVE-2018-8174：IE最新漏洞分析

一、前言

2018年4月下旬，我们利用沙箱环境发现了Internet Explorer（IE）的一个最新0day漏洞，而这距离IE漏洞上一次在野外被利用（CVE-2016-0189）已经过去了2年时间。这个漏洞以及相关利用技术在某些方面较为有趣，本文详细分析了这个漏洞（CVE-2018-8174）的根本原因。

二、捕获0day漏洞

故事开始于2018年4月18日，当时有人往VirusTotal（VT）上传了一个有趣的漏洞利用程序。包括卡巴斯基在内的多个AV厂商成功检测到了这个利用程序，我们将该程序标记为针对老版本Microsoft Word漏洞的通用启发式逻辑类别。

图1. Virustotal上对CVE-2018-8174的扫描结果

使用我们的沙箱系统处理这款恶意样本后，我们注意到即便打上完整补丁的Microsoft Word也会被成功利用。根据这个信息，我们开始深入分析这个利用程序。我们先来看一下完整的感染链：

图2. 感染链

这条感染链包含如下几个环节：

1、受害者收到一个恶意Microsoft Word文档。

2、打开这个恶意文档后，样本会下载第二阶段的利用程序，即包含VBScript代码的HTML页面。

3、VBScript代码会触发UAF（Use After Free，释放后重用）漏洞并执行shellcode。

三、初步分析

我们针对RTF（Rich Text Format）文档开始研究，攻击者利用该文档来投递针对IE的利用程序。该文档只包含一个对象，其内容经过混淆处理，这是一种已知的混淆技术，我们称之为“nibble drop（半字节）”混淆技术。

图3. RTF文档中经过混淆处理的对象

去除混淆并解密16进制数据后，我们发现这是一个OLE对象，其中包含一个URL Moniker.aspx) CLSID。因此，漏洞利用程序最开始的处理方式与之前的一个漏洞（CVE-2017-0199）类似，该漏洞用到了Microsoft HTA处理程序。

图4&5. 使用URL Moniker来加载IE漏洞利用载荷

在CVE-2017-0199漏洞中，Word会尝试根据文件的属性，使用默认的文件处理程序来执行文件，比如服务器响应报文中的Content-Type HTTP头部字段就是其中一个属性。由于application/hta这个Content-Type所对应的默认处理程序为mshta.exe，因此Word会选择其作为OLE服务器，不受限制地运行脚本。这样攻击者就可以直接调用ShellExecute，启动所选择的攻击载荷。

然而，如果我们检查最新利用程序中嵌入的URL时，我们发现服务器响应中的Content-Type并非application/hta（CVE-2017-0199漏洞需要满足这个条件），而是text/html。与text/html对应的默认OLE服务器为mshtml.dll，这是包含IE后端引擎的一个程序库。

图6. WINWORD.exe查询注册表确定正确的OLE服务器

此外，该页面包含一个VBScript，加载该脚本时会使用一个安全模式标志（默认值0xE）。这样一来攻击者无法直接执行攻击载荷，这与HTA处理程序的情况一样，需要使用一个IE漏洞才能突破这个限制。

微软在针对Moniker相关漏洞（CVE-2017-0199、CVE-2017-8570以及CVE-2017-8759）的补丁中引入了激活过滤器，利用该过滤器，应用程序可以限制在运行时实例化的COM对象，因此攻击者有可能可以使用URL moniker来加载远程web页面。

图7. 被过滤的某些COM对象，限制使用MSO.dll中的IActivationFilter来创建这些对象

在分析样本时，过滤后的CLSID列表包含16个表项。MSHTML CLSID（{{25336920-03F9-11CF-8FD0-00AA00686F13}}）不在该列表中，因此攻击者可以在Word上下文环境中成功创建MSHTML COM服务器。

现在起事情开始变得有趣起来。尽管Word文档是攻击者使用的最初攻击媒介，但漏洞实际上位于VBScript中，而非Microsoft Word中。这是我们第一次看到有攻击者使用URL Moniker来加载IE漏洞利用载荷，我们相信恶意软件开发者会在未来大量应用这种技术。利用这种技术，攻击者可以使用IE引擎加载并渲染web页面，即便受害者主机上的默认浏览器并非IE浏览器。

下载的HTML页面中的VBScript包含一些函数名及整数值，这些信息都经过混淆处理。

图8. 经过混淆处理的IE漏洞利用载荷

四、漏洞原理分析

为了分析漏洞原理，我们只需查看去混淆后脚本中的第一个函数（即TriggerVuln），程序在调用RandomizeValues以及CookieCheck函数后就会调用该函数。

图9&图10. 去混淆脚本中的漏洞触发过程

为了获得所需的堆布局，确保已被释放的类对象内存会被ClassToReuse对象再次复用，漏洞利用程序会分配一些类对象。触发漏洞的代码可以精简为如下PoC代码：

图11. CVE-2018-8174漏洞PoC代码

当我们使用启用了页堆的IE浏览器运行这个PoC时，我们可以观察到OLEAUT32!VariantClear函数会发生崩溃：

图12. 调用被释放的内存时出现访问冲突（Access Violation）异常

图13. 当销毁第二个数组（ArrB）时会复用被释放的内存指针

利用这个PoC代码我们成功触发了一个UAF漏洞，ArrA(1)以及ArrA(2)都会引用内存中的同一个ClassVuln对象。这种情况有可能会出现，因为当Erase ArrA被调用时，vbscript!VbsErase函数会确定待删除的对象类型为SafeArray，然后再调用OLEAUT32!SafeArrayDestroy。

然后函数会检查指向tagSafeArray.aspx)结构的指针不为NULL，同时检查指针的引用计数（存储在cLocks字段中）是否为0，然后继续调用ReleaseResources。

图14. ArrA(1)的VARTYPE为VT_DISPATCH，因此会调用VBScriptClass::Release来销毁对象

而ReleaseResources会检查fFeatures这个标志变量，由于我们有一个VARIANT数组，因此该函数随后会调用VariantClear，VariantClear函数会遍历数组中的每个成员，执行必要的去初始化操作，并且根据需要调用相关的类析构函数。在我们分析的这种情况中，由于ArrA(1)的VARTYPE为VT_DISPATCH，因此程序会调用VBScriptClass::Release来正确销毁对象，处理类似Class_Terminate之类的析构函数。

图15. CVE-2018-8174的根本原因：在TerminateClass函数之前只检查一次reCount

这正是这个漏洞的根源所在。在VBScriptClass::Release函数内部，程序只在函数开头检查了一次引用计数值。即使该值很有可能会在重载的TerminateClass函数中递增（PoC代码中的确这么处理），最终释放类对象前并没有再做任何检查。

Class_Terminate是一个被弃用的方法，现在已经被Finalize过程所取代。在对象销毁过程中，程序会使用该函数来释放已获取的资源，一旦对象被设置为空并且该对象没有其他引用时就会立即执行该函数。在我们的例子中，Class_Terminate被代码重载，当调用VBScriptClass::TerminateClass时，会转到对应的重载方法。在重载方法内部又创建了ArrA(1)成员的另一个引用。此时ArrB(1)引用了ArrA(1)，其中包含一个即将被释放的ClassVuln对象。

图16. 释放第二个对象时调用了无效的虚方法而导致崩溃

当Class_Terminate子函数处理完毕后，Arr(1)所对应的对象被释放，但ArrB(1)仍然保持被释放的类对象的引用。当执行流程继续时，ArrB会被擦除，再次执行类似逻辑，不过这一次ArrB(1)引用了一个被释放的ClassVuln对象，因此当程序调用ClassVuln vtable中的某个虚方法时，我们就可以观察到崩溃现象。

五、总结

在这篇文章中，我们分析了CVE-2018-8174漏洞背后的核心原因，这是一个特别有趣的UAF漏洞，漏洞成因在于Class_Terminate这个VBScript方法没有正确处理相关对象的生命周期。漏洞利用过程与我们在之前漏洞（CVE-2016-0189以及CVE-2014-6332）中看到的利用过程不一样，原因在于Godmode（上帝模式）技术已经不再适用。整个漏洞利用链与漏洞本身一样有趣，但本文对此不再赘述。

CVE-2018-8174漏洞是利用URL moniker来加载IE漏洞载荷的第一款漏洞，除非这种技术被修复，否则我们认为攻击者未来将大量滥用这种技术，无视受害者系统上的默认浏览器设置，强制使用IE来加载攻击页面。

我们预计该漏洞将在不久的将来成为攻击者最喜欢的突破口，相信漏洞利用工具包开发者很快就会在驱动式（通过浏览器感染）以及渔叉式钓鱼（通过文档感染）攻击活动中滥用这种技术。为了保证自身安全，我们建议大家采用最新的安全更新，适用具备行为检测功能的安全解决方案。

在我们看来，这个漏洞实际上就是360核心安全团队最近发现的浏览器“双杀”漏洞。虽然漏洞利用技术并不限于浏览器范畴，但仍被归类为IE 0Day漏洞，这给安全社区带来了一些混乱。

发现这个漏洞后，我们第一时间与微软分享了相关信息，微软确认该漏洞为CVE-2018-8174漏洞。

六、检测方法

卡巴斯基实验室产品可以成功检测并阻止整个利用链及相关载荷，具体如下：

1、将RTF文档标记为HEUR:Exploit.MSOffice.Generic

2、将IE漏洞利用技术标记为PDM:Exploit.Win32.Generic，可以使用自动漏洞防护技术来防护

3、将IE漏洞利用技术标记为HEUR:Exploit.Script.Generic

4、将攻击载荷标记为HEUR:Trojan.Win32.Generic

七、IOC

RTF文档：

b48ddad351dd16e4b24f3909c53c8901

IE漏洞利用技术（CVE-2018-8174）

15eafc24416cbf4cfe323e9c271e71e7

攻击载荷

1ce4a38b6ea440a6734f7c049f5c47e2

相关网址

autosoundcheckers[.]com

原文：https://securelist.com/root-cause-analysis-of-cve-2018-8174/85486/