记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

Adobe在野漏洞:CVE-2016-4117漏洞分析

2016-08-03 22:15

在今年五月份,国外安全专家发现了一个未知的Adobe漏洞在野外被利用。在该漏洞被披露后,Adobe发布了一个升级补丁用于修复此漏洞(APSB16-15),编号为CVE-2016-4117。同时,CVE-2016-4117漏洞被列为高危漏洞,在CVSS Score中被评为10.0,它同时影响到Windows,Mac OS X,Linux和Chrome OS。Adobe在发布的漏洞信息中提到,“Windows、mac、Linux和Chrome OS中的Adobe Flash Player 21.0.0.226和早期版本中存在一个高危漏洞,成功利用该漏洞可能会导致系统崩溃,甚至攻击者可以控制受影响的系统。”

0x0漏洞简介

CVE-2016-4117是出现在ActionScript的com.adobe.tvsdk.mediacore.timeline.operations.DeleteRangeTimelineOperation类中的一个类型混淆漏洞,最终可能导致远程代码执行,在今年五月份的时候首次出现野外样本。在此类中,存在以下两个get,set的接口(图0-0),名称为placement,假如我们以此类作为基类,在子类中创建一个相同名称的object(图0-1),avm虚拟机在解释的过程中会出现错误,从而引起类型混淆。

 

\

 

(图0-0)

 

\

 

(图0-1)

0x1 漏洞相关知识

要深入了解这个漏洞的深入原理,首先我们要了解avm虚拟机解释字节码getproperty(0x66)的逻辑流程。adobe在github上公布过avm虚拟机的源代码,并且有一些参考文档,尽管这是3年前的代码,但是还是可以作为参考。

首先我们可以查看getproperty这个指令的简介(图1-0):

 

\

 

图(1-0)

简单来说就是从一个object中根据后面的index取出某个属性。我们再看源代码的实现:

 

\

 

图(1-1)

getBinding是根据我们的属性名字,最后返回一个bind ID值,然后会根据这个值取出不同的函数或者字段的值。这个ID的值由两部分组成,分别是低三位的bit和其余的bit,低三位的bit保存的是这个property的类型,其余的bit保存这个ID真正的值,枚举值如图:

 

\

 

图(1-2)

随后的bindingKind就是将这个ID值与7相与,也就是取出低三位的bit,然后switch表根据这个值进行不同的操作,这里与漏洞相关的有两个,一个是BKING_VAR(2),一般是object,uint等变量,一个是BKING_GET(5),对应get的接口,首先我们查看BKING_VAR:

 

\

 

图(1-3)

BindingToSlotId是右移三位,得到真正的ID值,然后根据这个ID值取出真正的value,getSlotAtom的逻辑也很简单,比如ID值是0x5,就取出对象偏移0x5*4的value,当然还会进行类型的判断,如这个类型是double型则取出8字节,如果是int型,则取出4字节。对比的汇编指令如下:

 

\

 

图(1-4)

然后我们再看BKING_GET:

 

\

 

图(1-5)

跟进coerceEnter函数:

 

\

 

图(1-6)

这段代码比较复杂,首先解释几个名词:

Vtable:是一个保存as层面(不是native层面)虚函数列表的对象,里面的methods数组保存不同虚函数对象的对应的MethodEnv,一般保存在object的+0x8偏移的位置。

MethodEnv:在其+0x8保存MethodInfo对象。

MethodInfo:在其0x8 保存虚函数将要调用的函数指针。最终会调用这个函数指针从而调用get or set接口。

这段代码首先右移三位,得到真正的ID值,然后以这个ID值作为索引从methods数组中取出对应虚函数的MethodEnv对象,再调用对应的get or set接口。

对应的汇编指令如下:

 

\

 

图(1-7)

另一个需要了解的就是byteArray的数据结构,根据不同版本,在byteArray对象的+0x40 or +0x44 or +0x48会有一个m_buffer,而m_buffer的+0x8保存了真正保存数据的array,+0x10是length。具体如图所示:

 

\

 

图(1-8)

0x2 漏洞触发分析

实验环境:Windows 7 64 bit 企业版cn

Adobe Flash:flashplayer21_0r0_213_win_sa_debug.exe

根据捕获的样本分析得出,漏洞触发的关键代码如下:

 

\

 

图(2-0)

通过flash90.palcement语句从而会在AS虚拟机层面进入getPlacement(该部分没有源代码,暂时命名)函数,是触发漏洞的关键所在,伪代码如下:

 

\

 

图(2-1)

首先会进入Toplevel_getproperty函数(也就是图1-1的函数),该函数没有漏洞,因此所有代码运行正常,最终返回placement在内存中的值0xd。我们知道placement等于true,也就是0x1,但是在as虚拟机保存变量的机制中,末尾三位bit也是保存类型的,官方文档如下:

 

\

 

图(2-2)

因此true的值是1

 

\

 

图(2-3)

我们可以看到这里调用了getBinding函数,然后返回0xe2:

 

\

 

图(2-4)

ID值0xE2如果与7相与等于0x2(因为我们已经混淆成object类型,本来是get接口),对应图(1-2),正确的流程应该是进入图(1-3)的代码,取出placement的值0xd。但是这里并没有进行任何判断,就进入图(2-3)下面的代码,我们对比和图(1-7)的代码:

 

\

 

我们发现这两处地方的代码是一样的,这里是进入了case 5和7的处理流程,从Vtable中取出MethodEnv然后取出虚函数地址并且调用。但是我们应该进入case 2的处理环节的,却进入了case5和7的处理流程,我们可以查看修补该漏洞后的代码:

 

\

 

图(2-5)

修补后的代码会对getBinding后的ID值的类型进行判断,如果不是0x5的类型,则进入错误处理流程,从而避免了其他ID值的类型进入了0x5类型的处理流程。下面我们来分析如果我们把这个0x2类型的ID值进入0x5类型的处理流程会产生什么严重的问题。

 

\

 

图(2-6)

将ID值右移三位得到0x1c,该值是placement属性在flash90对象中的偏移值(44+1c*4=b4):

 

\

 

图(2-7)

但是该值被用于从Vtable对象的MethodEnv数组中作为index值取出MethodEnv元素(图2-6中的edx+0x3c是数组的开始位置),查看Vtable对象的内存:

 

\

 

图(2-8)

Vtable对象的大小是0x60,0x1C并不是一个合法的值,经过计算后,最终会越界从下一个相邻的Vtable对象中读出MethodEnv元素。而这个Vtable对象是属于另一个对象类型Data5的,查看Data5的内存:

 

\

 

图(2-9)

 

\

 

图(2-10)

Data5对象的+0x8保存的Vtable对象等于0x39cbf40,与图2-8相符合,第一个属性等于0xab4130等于十进制的11223344,与图2-10相符合,最终判定该对象就是Data5对象。所以最后取出的虚函数指针是Data5对象的f2虚函数指针:

 

\

 

图(2-11)

但是这里的this指针却变成了flash90的指针,根据源码(图2-12),我们查看进入虚函数指针前第三个参数的内存区域:

 

\

 

图(2-12)

 

\

 

图(2-13)

换句话说,在f2函数上所有的一切操作的this指针都不是指向Data5对象的内存区域,而是指向flash90的内存区域,最终引起类型混淆漏洞。由于Data5对象里面有很多属性,占用的内存空间会比flash90对象大很多(图2-14),最终可以对flash90内存区域进行越界读写,只要在flash90对象的下一个相邻位置放入一个byteArray,即可以在f2函数中对这个byteArray的关键数据区域修改,得到一个长度超长的byteArray。

 

\

 

(图2-14)

0x3 漏洞利用分析

漏洞利用的过程中,主要有几个问题:

3.1 怎样令Data5对应的Vtable对象刚好分配在Data4对应的Vtable对象的下一个相邻位置。

第一步:Vtable对象的大小是由一个对象的虚函数数量决定的,虚函数越多,MethodEnv数组越大,Vtable对象也越大。目标Vtable对象是0x60,样本中通过添加5个虚函数,加上本来存在的3个虚函数,最后得到0x3c+8*4=0x5c,再经过内存对齐就是0x60:

 

\

 

图(3-0)

第二步:增加几个继承Data5的类Data6,Data7等等,然后在运行的过程中new出来,最后在内存中即可分配多个同样大小的Vtable对象。

 

\

 

图(3-1)

3.2 怎样令虚函数f2对应的MethodEnv刚好对应0x1c*4+0x3c+Vtable_Add

这个则十分简单,根据在内存中的偏移,在f2虚函数前增加若干个虚函数,样本中是1个。然后f2对应的MethodEnv就会刚好在0x1c*4的位置。

 

\

 

图(3-2)

3.3 如何令flash90后面紧跟一个byteArray

通过heap feng shui技术:

 

\

 

图(3-3)

Data3的构造函数如下图:

 

\

 

图(3-4)

最终内存布局如下图:

 

\

 

图(3-5)

进入f2函数后,首先进行一系列内存数据判断,找出byteArray关键数据区域的偏移值,因为版本和环境的不同,这些都可能不同的,因此为了兼容性,这里有必要进行判断:

 

\

 

图(3-6)

(图解:a48的内存位置计算法方法是flash90_add+0x10(因为Data5在第一个字段前会有0x10的metedata)+48*4=0x66a500=0x123=291,根据上图的内存布局(图3-5),a57就是byteArray的index,a64就是byteArray的this指针,a50是m_buffer的地址。a56和a23只是用于检测是否byteArray对象)

获得与flash90对象相邻的下一个byteArray的引用,将byteArray的m_buffer结构地址修改成我们可以控制的内存区域,把真正m_buffer区域的数据赋值至这个内存区域,然后进入flash20函数。复制利用的技术是把atom伪造成Number类型(图2-2),然后就可以读出指定内存区域的数据。修改前m_buffer地址(这里的版本是0x48偏移)如图所示:

 

\

 

图(3-7)

修改后的地址:

 

\

 

图(3-8)

进入flash20函数后,将会修改m_buffer区域的length字段,最终构造超长数组,实现任意内存读写:

 

\

 

图(3-9)

m_buffer的地址已经修改成我们可以控制的内存区域,因此这里的ba.a0是对应m_buffer的+0x8位置的,从图3-7可以看到,m_buffer的+0x8位置等于0x11223344,而ba.a0的构造函数如图3-4所示。在最新版的flash中,在m_buffer的结构中引入了cookie字段,以防篡改length,例如在+0x20就保存了length的cookie,计算方法是length xor .Data字段的一个cookie值。在修改length的同时也需要把+0x20的length_cookie也要修改,不然在校验的时候就会出错。通过将a1(capacity)与a5(capacity_cookie)异或,可以求出.Data字段中的cookie值,然后将这个cookie值与0xffffffff放进a6(length_cookie),最终完成篡改m_buffer的length字段的所有步骤。至此,我们已经得到了一个超大的byteArray数组,可以进行任意内存读写。样本接下来的利用方法与Hacking Team的CVE-2015-5119基本雷同,公开的分析文章非常多,在这就不再详细叙述:

 

\

 

图(3-10)

查找PE头,然后根据导入表结构查找VirtualProtect地址

 

\

 

图(3-11)

根据functionObject的结构,进行一系列读写操作,最终修改functionObject父对象的虚函数地址至VirtualProtect,在call.apply中会调用这个虚函数,从而调用VirtualProtect绕过DEP。

 

\

 

图(3-12)

读取functionObject的MethodEnv地址,再读取MethodEnv中的MethodInfo地址,再修改MethodInfo的_implGPR变成shellcode地址,从而绕过CFG检测。在functionObject.call的时候,会跳进shellcode执行,最终实现远程代码执行。

0x4 样本行为分析

和众多样本一样,shellcode的作用就是一个网马下载器。在shellcode执行后,样本会从网上下载一个恶意的exe文件然后执行,运行该exe后,受害者主机将会完全被攻击者控制。

 

\
知识来源: www.2cto.com/Article/201608/533350.html

阅读:40169 | 评论:0 | 标签:漏洞

想收藏或者和大家分享这篇好文章→复制链接地址

“Adobe在野漏洞:CVE-2016-4117漏洞分析”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云