12年 linux 系统运维工程师，网络架构设计、优化，故障处理。
分类： 网络与安全
2014-12-24 17:15:16
延续了近期通过flash利用ie浏览器漏洞的趋势，CVE-2014-6332的样本在很多地方接二连三的被捕获，这一趋势的最著名的例子是cve-2014-0322和cve-2014-1776的利用。
我们还没有遇到最原始的SWF利用样本，但是通过分析SWF，很明显是几个构造函数的内存破坏。
这个exploit中有趣的部分是flash组件，通过反编译ActionScript乍一看相当简单，exploit中相当多的代码以前见过。
这篇文章将不细讲 spray漏洞，因为它们和以前出现的时候几乎一样，简而言之，
信号处理函数启动，ExternalInterface 调用一个/ VBScript函数触发浏览器的漏洞。
一旦信号处理函数通过扫描检测到vector变长，它就停止检测并继续到下一个段落。
下一个被损坏的vector覆盖到整个内存，并定义读/写
通过向后扫描，确定Flash_*.ocx的一个指针泄露
之后，VirtualAlloc和GetProcAddress的地址从导入表中计算，等以后编写shellcode时使用。
ROP链通过覆盖以前创建的Sound对象的虚函数表来触发，并调用toString方法，完成第一个ROP小部件(Gadget)
这有一个行为值得一提，之前的shellcode，stack pivot之后，原堆栈地址（现在是eax）保存在ESI）保存在esi,然后放回esp作为的shellcode的一部分，确保shellcode可以在原堆栈上运行。
The shellcodeshellcode有趣的是，它似乎是为了绕过Microsoft EMET保护而定制的，其他的安全产品可能也是如此。
首先根据EMET，可以看到shellcode设置其数据段（包括大部分以后解决的函数的hash。
shellcode通过调用GetProcAddress解析NtSetContextThread的地址，开始运行，地址是通过ActionScript代码，在之前写到 heap spray （由ecx指向的）里面的。
按照2012年Piotr Bania证明的方法，shellcode建立了一个CONTEXT结构，调用NtSetContextThread，覆盖debug寄存器和消除EMET的EAF特征。
这一步完成后，shellcode面临的困难大大降低。
然后继续解决之前函数里输入的hash。
它在两个独立的loops中处理来自kernel32和ntdll的函数，如下：
LoadLibraryA一旦所有的函数处理之后，它通过Flash组件，进去读取一个paload PE,置于shellcode结尾，
Payload PE 通过一个名为“show.jpg”的文件到达，被魔法值0xDEADBEEF41414141标记，另一个DWORD包含它整体大小。
它被复制到内存中，然后写入到Local\Temp目录下的“windump.exe”文件（使用GetTempPathA检索）。
这个店由另一块 evasive代码介绍。
shellcode检查进程中是否存在 EMET.dll
如果这样，他正常调用WinExec，并且payload运行。否则，重置UnhandledExceptionFilter，保存当前esp值，调用第一次控制最后一个SEH handler的wapper函数，（由TEB指向）跳转到WinExec。
返回后，它将重置esp到之前的值，并无痕迹退出。
无论哪种方式，从损坏的sound对象的 toString method方法返回的已经恢复到正常执行。
结论
这个漏洞很有趣，因为它首先瞄准了受EMET保护的机器（准确的说是 EMET 4.1）。
奇怪的是，未完成bypass——这个exploit会在VirtualAlloc被EMET的堆栈检查抓到。
禁用或bypass这个单一的测试——这个exploit成功bypass EMET 4.1.
事实上，通过对customizations的小设置，也可以使这个exploit bypass EMET 5.1
尽管不是很熟悉，这个exploit展示了一个 bypass EMET的重大进展，而在同类型的以前的exploit中，攻击者通过 一个之前的IE补丁信息泄露(CVE-2014-7331)，来避免运行了EMET的机器。
值得注意的是，Palo Alto Networks Traps通过大量的冗余制止这种利用，我们将继续研究这些漏洞并适时更新。
