Adobe X沙箱

时间:2021-11-05 06:44:25

一、Adobe X沙箱简介

Adobe Reader X自从引入沙箱以来,对其攻击的难度就提高了很多。Reader X的沙箱是基于Google的Chrome沙箱,Chrome是开源的,Reader X和Chrome的代码有很大程度上的相似。

Adobe Reader X以及后续版本,在启动的时候会有两个进程,这两个进程的名字都叫AcroRd32.exe,是一对父子进程。其中父进程一般称为Broker进程,子进程称为SandBox进程,二者其实是同一个可执行文件AcroRd32.exe,只不过启动参数不同(参考文章《PLAYING IN THE READER X SANDBOX》)

Adobe X沙箱

图1:父子进程Broker.exe和SandBox.exe

Broker进程启动SandBox进程时修改了SandBox进程中的一些关键API,以User32! GetClipboardFormatNameA函数为例

Adobe X沙箱

图2:修改前的User32! GetClipboardFormatNameA函数

Adobe X沙箱

图3:修改后的User32! GetClipboardFormatNameA函数

在 SandBox进程中调用一些系统API的时候,会跳转到Adobe Reader自己的函数中(如图4中的JMP 00990270),并通过IPC调用把要执行的指令传给Broker进程,Broker进程来决定API是否被调用,最终通过IPC把结果返回给SandBox进程。

当打开一个PDF文件时,SandBox进程作为PDF文件的解释器解析PDF文件格式及其中的JS脚本,就算利用漏洞绕过了SandBox进程执行shellcode,由于有Broker进程的缘故,shellcode的功能也十分有限,这给了Adobe Reader极大的安全保障。Reader X逻辑关系如图4。

Adobe X沙箱

图4:Reader X逻辑关系图

二、漏洞利用——CVE_2013_0640 + CVE_2031_0641

1.    CVE_2013_0640

位置:作用于SandBox进程

成因:堆分配错误导致的可读写任意字节漏洞

效果:可在SandBox进程中执行shellcode

2.    CVE_2013_0641

位置:作用于Broker进程

成因:SandBox与Broker进程IPC通信漏洞

效果:可在Broker进程中执行shellcode

二者结合可突破Adobe Reader X,效果如图5。

Adobe X沙箱

图5:CVE_2013_0640 + CVE_2031_0641 突破Adobe Reader X

三、Adobe X 漏洞挖掘简介

1.     CVE-2013-0641简介

1)     前提假设:已获取SandBox进程控制权

2)     漏洞成因:IPC Call
         SandBox和Broker进程是通过IPC Call通信的,其每个IPC Call都有一个TagID标识调用的函数名。Broker进程根据TagID确定调用的是什么函数,如TagID = 0×74则Broker进程认为当前要调用的是GetClipboardFormatNameA 函数,TagID = 0×73则Broker进程认为当前要调用的是GetClipboardFormatNameW 函数。

当我们用TagID = 0×73 调用GetClipboardFormatNameA时会导致Broker进程的堆溢出,在下次IPC Call时可获取Broker进程控制权,如图6,7,8。(详情可参考南京翰海源的分析http://blog.vulnhunt.com/index.php/2013/02/21/cve-2013-0641-analysis-of-acrobat-reader-sandbox-%20escape/)

Adobe X沙箱

图6:TagID=0×74 发起GetClipboardFormNameA调用

Adobe X沙箱

图7:TagID=0×73 发起GetClipboardFormNameW调用

Adobe X沙箱

图8:TagID=0×73 发起GetClipboardFormNameA调用

  2. IPC Call 漏洞挖掘

Broker进程的逃逸是突破Adobe X的关键,Adobe的IPC Call可能还存在类似CVE-2013-0641的漏洞。若要对此类漏洞挖掘,则首先要获取Adobe所有的TagID,函数参数列表并把TagID对应到具体的Windows API上,可以通过静态分析AcroRd32.exe获取相应的信息(以下内容参考自 ADOBE SANDBOX WHEN THE BROKER IS BROKEN, CanSecWest 2013)。

1) 通过一已知API(InternetGetCookieA)的交叉引用表定位其TagID,如图9-13。

Adobe X沙箱

图9:从导出表查找函数InternetGetCookieA的地址

Adobe X沙箱

图10:定位InternetGetCookieA函数

Adobe X沙箱

图11:查看InternetGetCookieA的交叉引用表

Adobe X沙箱

图12:内存搜索交叉引用表中第一下地址,并获取到唯一值Adobe X沙箱

图13:查看内存搜索结果附近数据

Broker进程对每一个可处理的API Call都要调用同一个函数初始化, 大括号中的数据结构A为初始化函数传入的参数。

由图可知InternetGetCookieA与48B190,0×68是一一对应的。

2) 获取所有TagID和函数参数列表,如图14-16。

Adobe X沙箱

图14:获取数据结构A的交叉引用表

Adobe X沙箱

图15:查看调用A的函数(Call _text_413DD0),此函数即为所有API Call都需调用的初始化函数

Adobe X沙箱

图16:查看Call _text_413DD0的交叉引用表

从Call _text_413DD0的交叉引用表中可以找到所有类似于A的数据结构,从而定位所有TagID,如图17-18。

Adobe X沙箱

图17:点击交叉引用表

Adobe X沙箱

图18:获取TagID的数据结构

3)将TagID对应到Windows API

Adobe中有个函数是用来开启API拦截的,此函数可对某个指定的API是否开启拦截。可通过InternetGetCookie函数找到此拦截函数,如图19,20。

Adobe X沙箱

图19:内存搜索InternetGetCookieA函数

Adobe X沙箱

图20:call _text_42A580即为开启API拦截的函数的地址

通过call _text_42A580定位函数名和TagID的关系,如图Adobe X沙箱

图21:函数call _text_42A580

Adobe X沙箱

图22:Call _text_42A580的交叉引用表

Adobe X沙箱

图23:从交叉引用表中获取函数名与TagID对应关系

3. 自动化脚本测试

      按上述思路可用脚本获取所有TagID,对应到函数名和相应参数,以便进一步的漏洞挖掘。