ie漏洞
首页
文章
漏洞
SRC导航
内容精选
输入关键词搜索
APP 登录| 注册
CVE-2018-8174：IE最新漏洞分析
阅读量 12147 | 评论 2 稿费 180
分享到： QQ空间 新浪微博 微信 QQ facebook twitter
发布时间：2018-05-10 11:58:03
译文声明
本文是翻译文章，文章原作者，文章来源：https://securelist.com
原文地址：https://securelist.com/root-cause-analysis-of-cve-2018-8174/85486/
译文仅供参考，具体内容表达以及含义原文为准
×
一、前言
2018年4月下旬，我们利用沙箱环境发现了Internet Explorer（IE）的一个最新0day漏洞，而这距离IE漏洞上一次在野外被利用（CVE-2016-0189）已经过去了2年时间。这个漏洞以及相关利用技术在某些方面较为有趣，本文详细分析了这个漏洞（CVE-2018-8174）的根本原因。
二、捕获0day漏洞
故事开始于2018年4月18日，当时有人往VirusTotal（VT）上传了一个有趣的漏洞利用程序。包括卡巴斯基在内的多个AV厂商成功检测到了这个利用程序，我们将该程序标记为针对老版本Microsoft Word漏洞的通用启发式逻辑类别。
img
图1. Virustotal上对CVE-2018-8174的扫描结果
使用我们的沙箱系统处理这款恶意样本后，我们注意到即便打上完整补丁的Microsoft Word也会被成功利用。根据这个信息，我们开始深入分析这个利用程序。我们先来看一下完整的感染链：
img
图2. 感染链
这条感染链包含如下几个环节：
1、受害者收到一个恶意Microsoft Word文档。
2、打开这个恶意文档后，样本会下载第二阶段的利用程序，即包含VBScript代码的HTML页面。
3、VBScript代码会触发UAF（Use After Free，释放后重用）漏洞并执行shellcode。
三、初步分析
我们针对RTF（Rich Text Format）文档开始研究，攻击者利用该文档来投递针对IE的利用程序。该文档只包含一个对象，其内容经过混淆处理，这是一种已知的混淆技术，我们称之为“nibble drop（半字节）”混淆技术。
img
图3. RTF文档中经过混淆处理的对象
去除混淆并解密16进制数据后，我们发现这是一个OLE对象，其中包含一个URL Moniker.aspx) CLSID。因此，漏洞利用程序最开始的处理方式与之前的一个漏洞（CVE-2017-0199）类似，该漏洞用到了Microsoft HTA处理程序。
img
img
图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后端引擎的一个程序库。
img
图6. WINWORD.exe查询注册表确定正确的OLE服务器
此外，该页面包含一个VBScript，加载该脚本时会使用一个安全模式标志（默认值0xE）。这样一来攻击者无法直接执行攻击载荷，这与HTA处理程序的情况一样，需要使用一个IE漏洞才能突破这个限制。
微软在针对Moniker相关漏洞（CVE-2017-0199、CVE-2017-8570以及CVE-2017-8759）的补丁中引入了激活过滤器，利用该过滤器，应用程序可以限制在运行时实例化的COM对象，因此攻击者有可能可以使用URL moniker来加载远程web页面。
img
图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包含一些函数名及整数值，这些信息都经过混淆处理。
img
图8. 经过混淆处理的IE漏洞利用载荷
四、漏洞原理分析
为了分析漏洞原理，我们只需查看去混淆后脚本中的第一个函数（即TriggerVuln），程序在调用RandomizeValues以及CookieCheck函数后就会调用该函数。
img
img
图9&图10. 去混淆脚本中的漏洞触发过程
为了获得所需的堆布局，确保已被释放的类对象内存会被ClassToReuse对象再次复用，漏洞利用程序会分配一些类对象。触发漏洞的代码可以精简为如下PoC代码：
img
图11. CVE-2018-8174漏洞PoC代码
当我们使用启用了页堆的IE浏览器运行这个PoC时，我们可以观察到OLEAUT32!VariantClear函数会发生崩溃：
img
图12. 调用被释放的内存时出现访问冲突（Access Violation）异常
img
图13. 当销毁第二个数组（ArrB）时会复用被释放的内存指针
利用这个PoC代码我们成功触发了一个UAF漏洞，ArrA(1)以及ArrA(2)都会引用内存中的同一个ClassVuln对象。这种情况有可能会出现，因为当Erase ArrA被调用时，vbscript!VbsErase函数会确定待删除的对象类型为SafeArray，然后再调用OLEAUT32!SafeArrayDestroy。
然后函数会检查指向tagSafeArray.aspx)结构的指针不为NULL，同时检查指针的引用计数（存储在cLocks字段中）是否为0，然后继续调用ReleaseResources。
img
图14. ArrA(1)的VARTYPE为VT_DISPATCH，因此会调用VBScriptClass::Release来销毁对象
而ReleaseResources会检查fFeatures这个标志变量，由于我们有一个VARIANT数组，因此该函数随后会调用VariantClear，VariantClear函数会遍历数组中的每个成员，执行必要的去初始化操作，并且根据需要调用相关的类析构函数。在我们分析的这种情况中，由于ArrA(1)的VARTYPE为VT_DISPATCH，因此程序会调用VBScriptClass::Release来正确销毁对象，处理类似Class_Terminate之类的析构函数。
img
图15. CVE-2018-8174的根本原因：在TerminateClass函数之前只检查一次reCount
这正是这个漏洞的根源所在。在VBScriptClass::Release函数内部，程序只在函数开头检查了一次引用计数值。即使该值很有可能会在重载的TerminateClass函数中递增（PoC代码中的确这么处理），最终释放类对象前并没有再做任何检查。
Class_Terminate是一个被弃用的方法，现在已经被Finalize过程所取代。在对象销毁过程中，程序会使用该函数来释放已获取的资源，一旦对象被设置为空并且该对象没有其他引用时就会立即执行该函数。在我们的例子中，Class_Terminate被代码重载，当调用VBScriptClass::TerminateClass时，会转到对应的重载方法。在重载方法内部又创建了ArrA(1)成员的另一个引用。此时ArrB(1)引用了ArrA(1)，其中包含一个即将被释放的ClassVuln对象。
img
图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， 原文链接 。如若转载请注明出处。
漏洞分析 CVE-2018-8174 IE最新漏洞
興趣使然的小胃 认证 分享到： QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
U2F安全协议分析
2018-11-24 10:00:48
二十年重回首——CIH病毒源码分析
2018-11-23 15:20:19
Cookie Maker：隐藏在Google Docs中的恶意网络
2018-11-23 14:30:40
情报分析与研判之图片信息挖掘（1）
2018-11-23 10:00:17
|发表评论
发表你的评论吧
昵称
白帽子
换一个
|评论列表
越南邻国宰相 · 2018-06-11 16:27:57 回复
补丁未在 引用计数这里打补丁，而是在 变体类型做的更正~~所以说你说的根本原因是不太对的。
Ox9A82 · 2018-07-14 23:23:15 回复
感觉分析还是挺清楚的呀
興趣使然的小胃
肥叶好香锅，孜孜不倦
文章
296
粉丝
40
TA的文章
Cookie Maker：隐藏在Google Docs中的恶意网络
2018-11-23 14:30:40
海莲花：针对东南亚的新一波水坑攻击
2018-11-22 11:00:56
Ursnif重装上阵：对最新木马活动的跟踪分析
2018-11-21 11:27:51
Golem：隐藏在系统字体中的恶意软件
2018-11-20 10:56:04
分析“正式版”的Kraken Cryptor勒索软件
2018-11-13 15:43:51
输入关键字搜索内容
相关文章
CVE-2018-16323：如何利用 ImageMagick内存泄漏
【缺陷周话】第10期：反射型 XSS
VBScript引擎远程代码执行漏洞之CVE-2018-8174分析与利用（更新）
活动 | 破壳学院《代码审计7天体验营》
漏洞预警 | Adobe ColdFusion远程命令执行漏洞预警（CVE-2018-15961）
被遗漏的0day ? —APT-C-06组织另一网络武器库分析揭秘
【缺陷周话】第9期：缓冲区下溢
热门推荐
文章目录
一、前言
二、捕获0day漏洞
三、初步分析
四、漏洞原理分析
五、总结
六、检测方法
七、IOC
安全客Logo
安全客
安全客
关于我们
加入我们
联系我们
用户协议
商务合作
合作内容
联系方式
友情链接
内容须知
投稿须知
转载须知
合作单位
安全客
安全客
Copyright © 360网络攻防实验室 All Rights Reserved 京ICP备08010314号-66
Loading...0daybank
文章评论