码迷,mamicode.com
首页 > 其他好文 > 详细

Equation漏洞混淆利用分析总结(上)

时间:2018-12-31 00:05:38      阅读:285      评论:0      收藏:0      [点我收藏+]

标签:比较   ati   控制   不为   分享   一个   难度   byte   意思   

Office Equation类型的漏洞从2017年底开始被发现,到目前一共可用的有11882,0802,0798三个漏洞,可以说2018年office中使用最多的也是这三个漏洞,也是office中混淆利用最繁杂的一类漏洞(应该没有之一),由于equation本身的问题导致这三个漏洞的在利用的混淆上有很多的变种,有意思的是这些混淆的技巧在三个漏洞中基本是通用的,本文通过几个样本来对这几个漏洞的混淆利用进行一次总结。

首先无论是11882,0802,还是0798,一个正常的利用样本的结构如下所示,即eqnolefilehdr,mtef head,mtef byte stread(这是EquationNative流的形式),当为Ole10Native流时,结构变为4字节+ mtef head,mtef byte stread。

 技术分享图片

mtef head正常情况如下所示,如上图中的03 01 01 03 0A

技术分享图片 

之后的mtef record按类型一共包含14类,其中漏洞出在其中的type 5(matrix,0798),type 8(font,11882/0802中)

 技术分享图片

样本一

 技术分享图片

Vt上也是报的11882,但是vt上大多报的不准,因此我决定确认一下到底是不是11882.

上调试器,来个断点,11882溢出点断下。

 技术分享图片

覆盖返回地址。

技术分享图片

 

进入shellcode。

 技术分享图片

现在基本确认是11882,如下红框部分就是对应的equation head,mtef head,之后是对应的shellcode部分,长度47,符合11882的溢出长度,接下来一步一步看这个样本是如何进行的混淆。

技术分享图片

首先是equation head部分,在有Equationnative 流的情况下,这部分的长度为0x1c,以0x1c开头,而值得注意的是绿色部分的值。

 技术分享图片

通过对比解析equation的流程就可以知道,读取0x1c长度的头部之后,会判断其第二个字节开始的四字节的值是否小于0x20000,因此这个地方是一个混淆点,只要保证值小于0x20000即可。

技术分享图片

可以看到之后的比较,之后的equation head中的内容实际是没有太多要求的(至少在解析代码的流程中是没有看到对应的作用的)。

 技术分享图片

之后到metf head,这个和之前熟悉的03 01 01 03 0A完全不一致(之前的报告里也遇到过,但第一个和第三个字节从文档来看是不能变的,难道文档有毒?)。

 技术分享图片

Metfhead的解析在以下函数。

 技术分享图片

进去之后发现,确实2,4,5位是没有检验的,第一位是version,但是version是可以有多个值的,只要不小于2,不大于3即可,甚至当你大于了3,还有贴心的减掉100的机会,也就是说第一位可用的值有02,03,102,103,而该样本中用的是02,因此符合判断条件,而位于第三位的值如果不为01,则会进入到函数sub_4184A0中,该函数比较复杂,但是却没有相关异常的操作,即应该是可以正常返回的。

 技术分享图片

调试样本可以看到metf第三位的值为a4,不等于1,会进入对应的函数流程。

 技术分享图片

但是该函数直接运行之后,似乎并不影响之后的程序。

 技术分享图片

因此可知,metf除了第一个字节有所要求外,其余字节也是可变的。

技术分享图片

之后就对应的font部分,正常的情况一般为0A 08 00 00,可以看到这个地方基本都变了。

 技术分享图片

Metfhead check之后继续往后读取值,此时可以看到直接读取的是01,之后进入正常的11882漏洞执行流程。

 技术分享图片

判断前一步中读取的是否为font的type 8,如果不是分两个流程如果大于9,则依次再读取下一个字节的内容(这也是之前11882普遍喜欢使用的一个混淆方式,即在08 type前插入任意大于9的字节,皆可起到混淆的作用,同时不影响漏洞的利用),第二种流程即小于9则直接返回,很明显这个样本属于第二中情况,结合上面的调试,我们知道该样本11882是利用成功的,即攻击者使用了另外的执行流程来利用该漏洞(这样做的好处是可以绕过hook指定函数检测漏洞利用的方式)。

 技术分享图片

由于fun_CheckrecordHead是唯一的入口,因此我们在这个函数下断点,看看到底还有哪个地方能导致漏洞触发,结果如下所示,可以看到,入口是0798这个漏洞的入口。

技术分享图片

那是如何进入到这个0798的触发点的了?如上述所示正常流程的11882函数由于值为01,会直接返回,返回值为01,直接进入到switch中。

 技术分享图片

可以看到当case等于1时,进入到0798的漏洞函数。

 技术分享图片

继续往里。

 技术分享图片

此时可知,实际在进入0798的漏洞派发函数前,还有一次调用1188/0802的机会,熟悉0798的漏洞就应该知道,实际上前面的地方除了01外,04也是可以导致进入0798的,因此这个地方的混淆可以有01,04两种选择,本质上确是通过0798中MATRIX record触发的11882/0802漏洞。

 技术分享图片

08之后的两个字节实际上也没用,因此也是可混淆的。

 技术分享图片

样本二

这个样本中可以看到metf的第一位为被设为66(102),比较有趣的是蓝色部分,可以看到其使用了01的标记用于进入到0798的流程,通过0798进入对应的11882.此时中间有11,22,33,44四个字节的混淆字节,F8为font tag。

 技术分享图片

校验完meft head头,读取type类型,由于此处的类型为01,所以正常的11882漏洞流程直接将其返回,进入之后的case 1流程。

技术分享图片

在case1流程中,进入0798函数。

 技术分享图片

0798函数中包含了11882流程,进入并传入11参数,11882直接返回1,dispatch函数进入case 0流程。

 技术分享图片

Case 0 流程进入的函数如下所示,if 判断成功,直接返回,需要注意的是else中实际也是一处可供利用点,下两处红框中的函数都是可以进入到11882/0802漏洞触发流程的(需要注意的是这样利用依赖与a4的值,因此需要特殊构造)。

 技术分享图片

Case 0流程执行完毕,dispatch函数返回,循环再次读取下一位,此时读取22,并再次进入dispatch函数。

技术分享图片

22作为11882漏洞函数流程参数,直接返回2,进入dispatch 1流程。

技术分享图片

Case 1流程的处理函数如下,首先通过函数sub_43B449A再次往下读取一位,即33,函数中通过判断读取的值减掉0x80的值来判断返回1还是其他(依赖于一块内存变量word_45ABE6),此处返回0,之后判断版本,及sub_43B449A的返回值,由于返回值为0,这将导致if 判断失败,进入else流程,else中再次读取一位,即44,最终进入最后的0798流程,此时0798中读取F8,最终进入到11882的利用流程。

技术分享图片

sub_43B449A函数如下,可以看到通过33这个位置的值是可以在一定程度上控制返回值的,0x89,0x90可以保证返回1,其余情况则依赖于word_45ABE6这个位置的值。

 技术分享图片

实际上如果能控制sub_43B449A,及sub_420AE3 ,sub_44B324的返回值,进入if同样也是一条11882的触发流程,但是目前来看难度较高。主要是首先需要保证sub_43B449A的返回值小于0,这就要求word_45ABE6这个位置可控。

 技术分享图片

word_45ABE6引用的地方如下,在fun_shell1_11882进行了设置。

 技术分享图片

但是需要注意的是该函数是在11882流程里,且在利用返回后设置,因此word_45ABE6的值控制起来没有任何意义。

 技术分享图片

由上文的分析可知,11882/0802这两个函数有多种可能的触发方式,除了常规的ParseMTEFData外,其实大部分都集中在0798的dispatch函数中。

 技术分享图片

 

转载请注明出处

Equation漏洞混淆利用分析总结(上)

标签:比较   ati   控制   不为   分享   一个   难度   byte   意思   

原文地址:https://www.cnblogs.com/goabout2/p/10201061.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!