发布时间:2014-07-15 11:50:28作者:知识屋
一、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》)
图1:父子进程Broker.exe和SandBox.exe
Broker进程启动SandBox进程时修改了SandBox进程中的一些关键API,以User32! GetClipboardFormatNameA函数为例
图2:修改前的User32! GetClipboardFormatNameA函数
图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。
图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。
图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/)
图6:TagID=0×74 发起GetClipboardFormNameA调用
图7:TagID=0×73 发起GetClipboardFormNameW调用
图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。
图9:从导出表查找函数InternetGetCookieA的地址
图10:定位InternetGetCookieA函数
图11:查看InternetGetCookieA的交叉引用表
图12:内存搜索交叉引用表中第一下地址,并获取到唯一值
图13:查看内存搜索结果附近数据
Broker进程对每一个可处理的API Call都要调用同一个函数初始化, 大括号中的数据结构A为初始化函数传入的参数。
由图可知InternetGetCookieA与48B190,0×68是一一对应的。
2) 获取所有TagID和函数参数列表,如图14-16。
图14:获取数据结构A的交叉引用表
图15:查看调用A的函数(Call _text_413DD0),此函数即为所有API Call都需调用的初始化函数
图16:查看Call _text_413DD0的交叉引用表
从Call _text_413DD0的交叉引用表中可以找到所有类似于A的数据结构,从而定位所有TagID,如图17-18。
图17:点击交叉引用表
图18:获取TagID的数据结构
3)将TagID对应到Windows API
Adobe中有个函数是用来开启API拦截的,此函数可对某个指定的API是否开启拦截。可通过InternetGetCookie函数找到此拦截函数,如图19,20。
图19:内存搜索InternetGetCookieA函数
图20:call _text_42A580即为开启API拦截的函数的地址
通过call _text_42A580定位函数名和TagID的关系,如图
图21:函数call _text_42A580
图22:Call _text_42A580的交叉引用表
图23:从交叉引用表中获取函数名与TagID对应关系
3. 自动化脚本测试
按上述思路可用脚本获取所有TagID,对应到函数名和相应参数,以便进一步的漏洞挖掘
2011-06-17
电脑开机时出现lass.exe进程是病毒吗?
自拍须谨慎!教你如何通过照片定位查看拍摄地点
电脑病毒最基础知识
黑客学员必须了解的C语言技术
精典详细内网渗透专题文章
教你破解Tp-Link的无线路由密码
解决SecureCRT中文显示乱码
QQ电脑管家和360哪个好?横评实测对比
攻防实战:无线网络路由入侵过程