在2018年4月下旬，我们使用沙箱发现了IE0day漏洞;自从在野外发现上一个样本(CVE-2016-0189)已经有两年多了。从许多方面来看，这个特别的漏洞及其后续的开发比较有趣。下一篇文章将分析最新的漏洞背后的核心原因，CVE-2018-8174。
寻找0day漏洞
我们从VirusTotal (VT)开始搜寻0day漏洞，有人在2018年4月18日上传了一个有趣的漏洞。这一漏洞被包括卡巴斯基在内的几家AV供应商发现，特别是我们的通用启发式逻辑，用于一些较老的Microsoft Word漏洞。
Virustotal对CVE-2018-8174的扫描结果
在我们的沙箱系统中处理了恶意软件样本后，我们注意到微软Word的一个完全补丁版本被成功开发。从这一点开始，我们开始对漏洞进行了更深层次的分析。让我们看一下完整的感染链:
感染链
感染链包括以下步骤:
· 受害者会收到恶意的微软Word文档。
· 在打开恶意文档后，将下载该漏洞的第二阶段;包含VBScript代码的HTML页面。
· VBScript代码触发Use After Free (UAF)漏洞后，并执行shellcode。
初步分析
我们将使用初始Rich Text Format (RTF) 文档开始分析，该文档用于传递IE的实际漏洞。它只包含一个对象，并且其内容是利用我们称为“nibble drop”的已知混淆技术来进行混淆的。
在RTF文档中混淆对象数据
在对对象数据进行了反混淆和十六进制解码后，我们可以看到这是个OLE对象，其包含一个URL Moniker CLSID。正因为如此，这一漏洞最初类似于利用微软HTA处理器的一个旧漏洞(CVE-2017-0199)。
URL Moniker被用来加载IE漏洞
使用CVE-2017-0199漏洞，Word尝试根据其属性，通过默认的文件处理程序，来执行文件;服务器响应中的Content-Type (内容类型)HTTP头是其中之一。由于“application/hta”内容类型的默认处理程序是mshta.exe，该程序也是OLE的服务器，可以让OLE不受限制地运行脚本。这一特点允许攻击者直接调用ShellExecute并启动选择的有效负载。
但是，如果追踪一下最新发现的漏洞中嵌入的URL，可以看到服务器响应中的内容类型不是“application/hta”，而是 “text/html”，这是CVE-2017-0199开发的需求。“text/html”的默认OLE服务器是mshtml.dll，它是一个包含引擎的库，在Internet Explorer后面。
WINWORD.exe为正确的OLE服务器查询注册表
此外，该页面包含VBScript，它利用安全模式标志加载，以将其默认值设为“0xE”。由于这一操作使得攻击者不能直接执行有效负载，就像HTA处理程序一样，需要利用Internet Explorer漏洞来克服这一点。
像上面一样，使用一个URL名字对象来加载远程web页面是可能实现的，因为针对Moniker相关漏洞(CVE-2017-0199, CVE-2017-8570和CVE-2017-8759)的微软补丁，引入了一个激活过滤器，它允许应用程序指定哪些COM对象在运行时被禁止实例化。
一些过滤后的COM对象，被限制IActivationFilter在MSO.dll中创建
在分析时，筛选的CLSID列表包含16个条目。TheMSHTML CLSID ({{25336920-03F9-11CF-8FD0-00AA00686F13})不在列表中，这就是为什么MSHTML COM服务器在Word上下文中成功创建的原因。
这就是它变得有趣的地方。尽管Word文档是初始攻击向量，但漏洞实际上是在VBScript中，而不是在Microsoft Word中。这是我们第一次见到利用URL Moniker加载IE漏洞，我们相信在不久的将来这一技术将会被恶意软件作者大量使用。这种技术允许使用IE引擎加载并呈现一个web页面，即使受害者机器上的默认浏览器设置为别的浏览器。
下载的HTML页面中的VBScript包含了函数名和混淆的整数值。
混淆的IE漏洞
漏洞根本原因分析
对于根本原因分析，我们只需要看去混淆版本中的第一个函数(“TriggerVuln”)，该函数是在“RandomizeValues”和“CookieCheck”之后被调用的。
去混淆后的漏洞触发程序
为了实现所需的堆布局，并确保释放的类对象内存将被“ClassToReuse”对象重用，该漏洞分配了一些类对象。为了触发这个漏洞，这个代码可以最小化到以下的概念验证(PoC):
CVE – 2018 – 8174的概念验证
当我们通过启用页面堆，在Internet Explorer中启动这个PoC时，我们可以观察到OLEAUT32!VariantClear函数的崩溃。
访问关于释放内存调用的违例
当第二个数组(ArrB)被破坏时，释放的内存指针被重用
通过这个PoC，我们就能够触发一个Use-after-free漏洞;ArrA(1)和ArrB(1)在内存中引用相同的“ClassVuln”对象。这种情况是可能的，因为当调用“Erase ArrA”时，vbscript!VbsErase函数确定要删除的对象类型是SafeArray，然后调用OLEAUT32!SafeArrayDestroy。
它检查是否指向tagSafeArray结构的指针不是NULL，以及它的引用计数，存储在时钟字段中的是零，然后继续调用ReleaseResources。
ArrA(1)的VARTYPE是VT_DISPATCH，因此调用VBScriptClass::Release来破坏对象
反过来，ReleaseResources将会检查fFeatures标志变量，由于我们有VARIANT的一个数组，随后它将调用VariantClear;它是一个函数，该函数迭代数组中的每个成员并执行必要的初始化，并在必要时调用相关的类析构函数。在本例中，VBScriptClass::Release被调用来正确地破坏对象，并且处理像Class_Terminate这样的破坏者，因为ArrA(1)的VARTYPE是VT_DISPATCH。
在TerminateClass函数之前，只检查一次CVE-2018-8174 -“refCount”的根本原因
这最终成为了漏洞的根源所在。在VBScriptClass::Release函数中，在函数开始时对引用计数只检查一次。尽管可以(实际上是在PoC中)在一个超载的TerminateClass函数中增加检查次数，但是在最终释放类对象之前不会进行检查。
Class_Terminate是一种过时的方法，现在被“Finalize”程序取代。在对象破坏期间，它被用来释放获得的资源，一旦对象被设置为空，该程序就会被执行，并且不再有对该对象的引用。在我们的例子中，Class_Terminate方法是超载的，当对VBScriptClass::TerminateClass执行调用时，就会为其分派超载的方法。在该超载方法的内部，为ArrA(1)成员创建了另一个引用。在这个点ArrB(1)引用ArrA(1)，ArrA(1)拥有一个很快被释放的ClassVuln对象。
崩溃，由于在释放第二个对象时调用一个无效的虚拟方法
在Class_Terminate子完成之后，Arr(1)中的对象被释放，但是ArrB(1)仍然保留对被释放类对象的引用。当继续执行，并且ArrB被擦除时，整个循环会重复，除了这一次，ArrB(1)引用了一个已释放的ClassVuln对象，因此当调用ClassVuln vtable中的一个虚拟方法时，我们观察到了崩溃。
总结
在本文中，我们分析了CVE-2018-8174背后的核心原因，Use-After-Free是一个特别有趣的漏洞，这可能是由于在Class_Terminate VBScript方法中错误的对象周期处理造成的。其漏洞利用过程不同于我们在过去的漏洞(CVE-2016-0189和CVE-2014-6332)中所看到的，因为该漏洞不再使用Godmode技术。完整的开发链和漏洞本身一样有趣，但是超出了本文的范围。
CVE – 2018 – 8174是首个使用URL名字对象在Word中加载一个IE漏洞的公开漏洞,我们相信,除非被固定,不然未来攻击者将大量的使用这种技术进行攻击,因为它允许在无视受害者系统默认浏览器设置的情况下，强迫IE加载。
鉴于距离漏洞攻击开发者开始滥用这一技术进行路过式攻击（通过浏览器）以及网络钓鱼攻击（通过文档）活动，不会太久，我们预计该漏洞将成为近期利用最多的工具之一。为了保持安全，我们建议应用最新的安全更新，并使用带有行为检测功能的安全解决方案。
在我们看来，这一漏洞和Qihoo360核心安全团队在其最近的出版物中所称的“Double Kill”是同一漏洞。虽然这一漏洞并不局限于浏览器利用，但它被报告为IE0day漏洞，这一举动在安全社区中引起了一定的混乱。
在发现这一漏洞后，我们立即与微软分享了相关信息，并且微软确认这实际上是CVE-2018-8174。
该漏洞在野外被发现，并被一个APT行动者使用。对卡巴斯基情报报告服务的客户来说，可以获得更多关于该APT行动者的信息以及该漏洞的使用信息。联系:[email protected]
检测
卡巴斯基实验室的产品成功地检测并阻断了所有的开发链和有效载荷的所有阶段，并进行了如下的判决:
HEUR:Exploit.MSOffice.Generic—— RTF文档
PDM:Exploit.Win32.Generic——IE漏洞——采用漏洞自动预防技术检测。
HEUR:Exploit.Script.Generic——IE漏洞
HEUR:Trojan.Win32.Generic ——有效载荷
IOCs
b48ddad351dd16e4b24f3909c53c8901 ——RTF文档
15eafc24416cbf4cfe323e9c271e71e7 ——IE漏洞 (CVE-2018-8174)
1ce4a38b6ea440a6734f7c049f5c47e2 ——有效载荷
原文地址：https://www.cnblogs.com/wushangguo/p/9073559.html