内容简介:类型混淆漏洞一般是将数据类型A当做数据类型B来解析引用,这就可能导致非法访问数据从而执行任意代码。本文通过IE类型混淆漏洞实例和Word类型混淆漏洞实例进行分析,来学习理解类型混淆漏洞原理。实例一:IE/Edge类型混淆漏洞(CVE-2017-0037)
类型混淆漏洞一般是将数据类型A当做数据类型B来解析引用,这就可能导致非法访问数据从而执行任意代码。
本文通过IE类型混淆漏洞实例和Word类型混淆漏洞实例进行分析,来学习理解类型混淆漏洞原理。
实例一:IE/Edge类型混淆漏洞(CVE-2017-0037)
·漏洞原因:函数处理时,没有对对象类型进行严格检查,导致类型混淆。
· 分析环境:Win7、IE11
· 分析工具:Windbg、od、IDA Pro
在PoC中定义了一个table,标签中定义了表id为th1,在boom()中引用,然后是setInterval设定事件。
漏洞成因分析:
运行PoC,用OD或Windbg附加并加载运行,出现崩溃,如下图:
从崩溃点可以看到eax作为指针,引用了一个无效地址,导致崩溃,而上一条指令是一个call,如下
这个无效的返回值来自这个call,此时我们进行逆推,在这个call处下断点,
ecx作为参数,存放的对象是一个Layout::FlowItem::`vftable虚表:
这个值会在Readable函数中引用,如下图:
这里读取虚表中+4的值,为0时this指针赋值v1,随后v1+16后返回,因此,Layout::FlowItem::`vftable所属指针的这个情况是正常的,函数会正常返回进入后续处理逻辑。
让程序继续运行,会再次调用该函数,此时ecx并不是一个虚表对象,而是一个int Array对象,这里我们可以通过条件断点来跟踪两个对象的创建过程,重点关注两个对象创建的函数,一个是FlowItem::`vftable对应的虚表对象,另一个是引发崩溃的int Array对象。这两个函数的返回值,也就是eax寄存器中存放的指向这两个创建对象的指针。
通过条件断点,输出每一次int Array object创建的对象信息。
通过跟踪可以看到第一次调用Readable函数时ecx是一个正常的FlowItem对象,而第二次调用的时候ecx是一个int Array Object。Layout::Patchable >::Readable函数是处理虚表对象的函数,由于boom()函数中引用th1.align导致Readable函数得到第二次引用,由于没有进行对象属性检查,导致第二次调用时将table对象传入,最终发生类型混淆崩溃。
分析利用关键点
首先我们分析崩溃点上下文,通过流程走向看看是否有可利用的点,
在判断eax返回值不等于0后,会继续往下调用Readable函数,且eax会连续引用,后面看到一个call edi,这是一个虚函数,如果我们能控制edi就有可能在这里达到代码执行的效果。其中有一个控制流保护机制CFG(call __guard_check_icall_fptr),Win7系统未开启所以这里不用考虑pass。
edi是由ecx(Array Object)传递过来的,通过修改th1对象中的width值为2000000,允许我们将EAX的值移动到堆喷射中的受控内存位置。
PoC中设置eip为0x41414141。
这里eax=0bebc2d8,我们的受控位置为0Xbebc200=(2000000*100),在可控范围。
EIP被设置为0x41414141,由于加载的所有模块均启用了ASLR,目前仍没有绕过的方法。
实例二:Word类型混淆漏洞(CVE-2015-1641)
· 漏洞原因:Word在解析docx文档的displacedByCustomXML属性时未对customXML对象进行验证,导致可以传入其他标签对象进行处理,造成类型混淆。
· 分析环境:Win7、Word2007
· 分析工具:Windbg、od、oletools、notepad++、WinHex
样本:https://github.com/houjingyi233/office-exploit-case-study/blob/master/CVE-2015-1641/8bb066160763ba4a0b65ae86d3cfedff8102e2eacbf4e83812ea76ea5ab61a31.bin.gz
首先解压样本并改后缀名为doc,用oletools的rtfobj分析结果为4个文件,分离保存。
在样本中提取第三个OLE,构造成rtf文件(上图为文件前半部分截图),打开该文件后出错,如下图,可以看到故障模块为wwlib.dll,异常偏移为0x9d30。
运行word,用windbg附加word进程,再打开rtf文件,异常出现在wwlib模块中的0x5c4a9d30,代码为mov esi,dword ptr [ecx],崩溃原因是[ecx]引用到无效地址。
这里ecx=0x7c38bd50,指向何处? 接下来分析保存出来的ole文件,解压后在资源文件“document.xml”中发现ecx的值正是smarttTag标签的element的属性值。
smartTag是一个智能标签,可针对人名、日期、时间、地址、电话号码等进行智能识别并允许用户执行特定操作的标签,displacedByCumtomXml属性表示此处要替换为另一个customxml标签,样本作者在smartTag的element中构造了0x7c38bd50,Word在解析docx文档处理displacedByCustomXML属性时未对customXML对象进行验证,所以能传入smartTag标签对象。
由于是单独加载触发漏洞OLE引用到无效地址,因为这个地址位于” MSVCR71.DLL”模块中,而这个DLL正是通过第一个OLE对象“otkloadr.wRAssembly.1”引入的。将第一个OLE对象:{\object\objocx{\*\objdata180115000002000000160000006f746b6c6f6164722e5752417373656d626c792e3100000000000000000001000000400105000000000000}},添加到触发漏洞的OLE前面,构建成RTF运行,再通过Windbg下条件断点,这里先记录下crash发生的时候“0x7c38bd50 “所在的模块地址,通过它来下条件断点:
0x7C38BD50是smartTag标签的element值,4294960790(0xFFFFE696)是moveFromRangeStart的值,随后对这两个值进行计算得到一个地址0x7C38BD74。计算过程如下:
第二个smartTag,smartTag标签的element值此时为0x7C38BD68,moveFromRangeStart的值为0x7C376FC3(十进制为2084007875),计算出的地址为0x7C38A428,最后通过memcpy函数将0x7C376FC3覆盖到地址0x7C38A428中,在调试器可以看到,0x7C38A428为虚表指针:
接着往下执行,会先经过一大片地址为“7C342404”的“ret”,然后进入ROP链,再往后就是shellcode。
将id为1的OLE解压后,在解压目录的“activeX1.bin“中看到用来堆喷的数据块:nop指令上面的是ROP链,heapspary前会使用大量地址为0x7c342404 的ret-sled,
以上两实例分析文章在网上较多,这里只做一个浅析,不做深入分析。
原创文章转载请注明来源:四维创智攻防实验室。
以上所述就是小编给大家介绍的《类型混淆漏洞实例浅析》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
无处安放的互联网隐私
【美】茱莉亚·霍维兹 【美】杰拉米·斯科 / 中国人民大学出版社有限公司 / 2017-7-1 / CNY 55.00
在当今互联网时代,我们的隐私权已经受到了威胁,政府或企业可以追踪我们的电话,搜索引擎可以记录我们的在线浏览记录以及恒温器的设置以及更多信息。在当代,保卫隐私权不只是简单地描述出存在的问题或者警告人们隐私权已经丧失,隐私权的护卫者们提出了解决策略。他们密切关注商业实践、公共政策和技术设计以及人物,应该继续下去吗?条件就是:有问题,让我们找到解决之道。一起来看看 《无处安放的互联网隐私》 这本书的介绍吧!