Adobe Flash Player CVE-2012-0779漏洞技术分析

原文地址:http://blogs.technet.com/b/mmpc/archive/2012/05/24/a-technical-analysis-of-adobe-flash-player-cve-2012-0779-vulnerability.aspx

作者:Jeong Wook Oh & Chun Feng (msft-mmpc)

翻译:magictong 20125

 

 

最近一段时间,我们在外部截获到一些针对已修补的Adobe Flash Player的漏洞攻击。在54日,Adobe最近的一次补丁发布日,已经解决了这些漏洞。如果你是在windows平台,那么Flash Player 11.2.202.233极其更早的版本都是有漏洞的。如果你正在使用有漏洞的版本,请立即更新你的Flash Player到最新版本以应对这些攻击。下面我们来分析一下这个恶意文档(程序)(SHA1e32d0545f85ef13ca0d8e24b76a447558614716c )的工作原理,在分析的过程我们也发现了很多有趣的细节。

下图展示了这个攻击的流程。攻击者首先发送一个恶意文档给被攻击者,恶意文档包含一个SWF下载触发器和一小段恶意代码。要注意的是,这个文档里面并没有包含任何恶意的SWFpayload(翻译注解:就是触发漏洞的部分,中文有效载荷并不确切,因此这里仍然使用payload原文)。

Adobe Flash Player CVE-2012-0779漏洞技术分析_第1张图片

1、攻击概述

 

下面描述一下当受害者打开这个恶意文档时,恶意软件感染的详细过程是怎么样的:

1) 当用户打开恶意文档时,恶意文档的部分功能是触发一个SWF文件的下载,该SWF文件是经过精心制作的,从上图中的恶意服务器1进行下载(注解:上图中的Malicious Server 1)。这个文档本身并没有什么恶意的地方,但是下载的这个SWF文件是恶意的,并且试图触发一个Adobe Flash Player的插件漏洞。

2) 恶意的SWF会被下载到用户的机器上并且被相关的应用程序渲染(注解:这里指被Adobe Flash Player进行渲染)。恶意的SWF文件实际上内部包含着真正的加密后的payload,并且是被动态加载的。我们称这种动态加载的内容为第二层SWF(注解:我理解的意思就是该SWF文件中包含大量的as动态执行代码)。而第二层SWF主要做的事情就是在目标程序的内存空间中进行Heapspray(堆喷:在堆上部署大量的shellcode代码)。

3) 第二层的SWF会去连接一个指定的恶意服务器(注解:上图中的Malicious Server 2)以便获取一段恶意数据,该恶意数据最终导致漏洞触发。

4) 当漏洞触发后,由第二层的SWF通过Heapspray(堆喷)早就部署好的shellcode代码得到执行。

5) 在第二层SWF里面的shellcode会从最开始打开的那个恶意文档里面解密一个PE文件出来。首先,它会枚举所有打开的句柄,以找到源恶意文档——如果这个枚举到的文件的特定偏移的位置包含一个8bit的特定的标记,则认为找到了源恶意文档。然后它开始从找到特定标记之后的0x10字节处开始进行解密PE文件的操作。解密方法是,每个字节和一个固定的key进行异或,但是跳过等于0的字节和等于key的字节不异或。最终解密出来的PE文件(SHA127c8bdacd4023858a810bec917381c6a7512715e)会被检测为TrojanDropperWin32/Glacid.A

和以前的很多攻击方式相比,这种攻击方式有一点点复杂,几个不同的模块需要协同工作才能完成整个攻击。每个模块化的的组件也被设计为可配置的。

例如,从恶意服务器1下载源恶意SWF文件时,源恶意文档可以精心设计进行HTTP请求的参数,而该参数最终会传给恶意SWF文件进行使用。下面的数据包是我们捕获的一个请求恶意SWF文件的例子。在这个例子中,我们可以看到,HTTP请求使用了“info”和“infosize”两个参数。这两个参数最终会被第二次SWF使用。

2、恶意SWF文件下载请求

 

这里是第二层SWF使用动态传递的info参数时的代码。动态传递的数据被转换为2进制形式并且进行了解压缩。解压后的数据是与恶意服务2(注解:提供触发漏洞的恶意数据)进行连接时的连接信息。

Adobe Flash Player CVE-2012-0779漏洞技术分析_第2张图片

3、第二层SWF里面参数的用法

 

正如我们在概览图里面看到的一样,第二层SWF是被恶意SWF文件动态的加载起来的。下面一小段来之恶意SWF文件的代码展示了第二层SWF是怎么被加载起来的。通过调用“flash.display.Loader”类里面的“loadBytes”方法,动态的把第二层SWF加载起来。在最近的一些SWF恶意文件中,这种动态加载第二层恶意SWF的方法非常常见,并且相当典型。

Adobe Flash Player CVE-2012-0779漏洞技术分析_第3张图片

4、使用loadBytes动态加载第二层SWF

 

有一个比较明显的特征是第二层SWF文件使用了Adobe Flash Player的“共享对象”功能。这是SWF里面一种在用户机器上面持久化数据的机制,它能被共享访问。当同一个SWF文件被再次加载之后(译注:就是之前已经加载过同一个SWF了,有点类似进程互斥),它可以从这个“共享对象”中获取到前一次加载这个SWF时保存的数据。通过“共享对象”的使用,恶意程序避免了同时间的多次利用(译注:因为利用的复杂性,同时多次利用可能造成问题),当它发现了已经有一个相同的SWF加载之后,它就不再进行下面的漏洞触发了。

Adobe Flash Player CVE-2012-0779漏洞技术分析_第4张图片

5、使用共享对象,防止多个利用实例存在

 

跟以前很多利用Adobe Flash Player的漏洞的恶意软件一样,这个也是通过堆喷技术来达到执行shellcode的目的。下面的图里面是进行堆喷操作的部分代码,在原理展示了堆喷是如何进行的,在进行堆喷的进行阶段,你会发现应用程序(译注:打开这个恶意文档的程序)的内存使用暴增。

Adobe Flash Player CVE-2012-0779漏洞技术分析_第5张图片

6、堆喷(Heap spraying

 

下图展示了shellcode被喷射到内存上面之后的样子。堆喷执行成功之后,同一个shellcode被成千上万的放置到内存的不同位置,当利用成功之后,程序执行流程会跳转到其中的一个shellcode去执行。

Adobe Flash Player CVE-2012-0779漏洞技术分析_第6张图片

7、喷射到内存上面的shellcode

 

要完整的完成一次攻击,需要多个模块协同工作。我们还没有发现此类攻击被广泛利用。并且,很多Adobe Flash Player漏洞下载回来的SWF文件可能就是恶意的,但是这个漏洞不是,它下载回来的SWF文件本身并不是恶意的。因此,你只要更新你的Adobe Flash Player就可以防止此类攻击。

 

本文分析中用到的SWF恶意软件的相关检测名称和SHA1

4d12200ede6cf44660399ca43c92fc87295b31cd检测名:SWF/CVE-2012-0779.A

53FE2CE5920CA0963638A68338433AD85F55BD0D检测名:SWF/CVE-2012-0779.B

c485712675509c233f70c64b84969b41164fab48检测名:SWF/CVE-2012-0779.D

你可能感兴趣的:(工作,解密,服务器,Flash,文档,Adobe)