首页
社区
课程
招聘
[原创]CVE-2012-0158 office缓冲区溢出漏洞报告【千字长文】
发表于: 2021-6-12 22:18 14207

[原创]CVE-2012-0158 office缓冲区溢出漏洞报告【千字长文】

2021-6-12 22:18
14207

Microsoft Office(CVE-2012-0158)漏洞分析报告

| 软件名称:Microsoft Office 软件版本:2003
漏洞模块:MSCOMCTL.OCX 模块版本:2003
编译日期:2020-11-19 | 操作系统:Windows 7-x86
漏洞编号:CVE-2012-0158 危害等级:高危
漏洞类型
:缓冲区溢出 威胁类型:本地 |
分析日期2021年6月10日

1. 软件简介
Microsoft Office2003是全球使用最广泛的办公软件,Microsoft Office 2003 SP3 五合一此版本包含 Word、Excel、Powerpoint、Outlook、Access 五个组件的全部功能!
2. 漏洞成因
文件字节的长度,和文件字节的限制的验证长度,都保存在文件中,导致可以很容易的修改这2个值.而导致栈中存储复制内容的目标数组溢出.
3. 利用过程 1
注意:有的win7-32位打了补丁,可能无法完美触发溢出攻击,xp系统下可能产生溢出的指令被截断。

1.设置OD
图片描述
图片描述
2.首先运行word.exe,然后用OD附加
图片描述
3.OD按F9运行,用word程序,打开poc文档。
4.样本的获取:
4.1在kail中使用msfconsole命令,查找是否有改漏洞利用的程序
图片描述
4.2查看漏洞信息
图片描述
图片描述
4.3根据信息准备环境
office2010上会使用ROP进行绕过DEP和ASLR,需要通过文件-打开的方式运行恶意样本

加入一个弹计算器的payloads,填写样本必要参数生成样本
图片描述
图片描述
5.将样本提取到虚拟机进行分析,点开完美触发。
图片描述
6.查看样本,寻找特征jmp esp等
图片描述
7.猜测样本所使用的API
7.1POC弹出了计算器,那么很可能调用的API是以下几个:
CreateProcess(参数多不是首选)
WinExec,导出模块是kernel32.dll,比较常用
system 导出模块是ucrtbase.dll,word不一定会加载

7.2验证猜想

图片描述
图片描述
图片描述

图片描述

图片描述
图片描述
图片描述

图片描述
图片描述

图片描述
u 001217c6 l-20 含义:反汇编 地址001217c6 l(是list的意思) -20 是向上20条指令
有较多pop 还有popad 看着像是ShellCode(往上找,找到一些NOP)

图片描述
查看nop之前的4个字节是什么指令
图片描述

查看样本中是否有这些OpCode
十六进制字节搜索未找到
图片描述
其他方式搜索到了
图片描述

图片描述

图片描述
图片描述

图片描述

图片描述图片描述

图片描述
图片描述
图片描述

图片描述
暂时没看出问题,继续单步
没走几步就到了RET
图片描述
继续挖信息
bp MSCOMCTL!DllGetClassObject+0x41abc
图片描述
这个位置还没有溢出,可以继续跟
图片描述
这个call F8跟进去
图片描述
再按F8几次
图片描述
调用栈信息由很多突然变了,减少了好几条.
转到OD中查看.
图片描述
等到打开漏洞.doc文件时,设置事件.中断于新模块.
图片描述
前面我们已经知道了模块和有问题的指令

图片描述
下断点:
图片描述
f7进入该函数,走到即将出错的那条函数查看堆栈信息.
图片描述
图片描述
结束OD,重新附加程序,运行到此位置.对比
图片描述
15.将已知出问题的MSCOMCTL.OCX 模块,拖入到ida中分析定位.
比较基址是否一致
图片描述
图片描述
16.定位到问题函数
图片描述
17.定位问题指令
图片描述
图片描述
18.同理溢出发现是在拷贝中溢出的,所以必然是destin参数溢出了,也就是lpMema参数,而该参数是sub_275c876D传入的,所以需要回溯这个参数.前边已经知道这个函数位置就是0x275c8A05了.直接定位.
图片描述
图片描述
显示dwBytes 是8282
19.返回ida中查找该函数位置:
图片描述
20.小结:目前来看引起溢出的原因就是dwBytes,因为它决定了到底要复制大的数据.尝试在漏洞.doc寻找该数值.
图片描述
图片描述
图片描述
图片描述
4.漏洞成因:
文件字节的长度,和文件字节的限制的验证长度,都保存在文件中,导致可以很容易的修改这2个值.而导致栈中存储复制内容的目标数组溢出.
5.PoC

5.1为什么jmp esp 要加nop(9090..) 1
图片描述
图片描述
图片描述

office有一些漏洞,都是此类溢出.此类的关键点,就在于将限制文档字节个数的值放在了文档中,导致不怀好意的人可以任意修改.而且加上,office未对读取到的漏洞.doc中限制字节的值做校验.导致溢出.
尽量不要点击来历不明的文档,比如.doc.pdf等.因为可能有病毒.

\<15PB信息安全教育-漏洞利用\>---任晓辉


[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!

上传的附件:
收藏
免费 6
支持
分享
最新回复 (8)
雪    币: 167
能力值: ( LV1,RANK:0 )
在线值:
发帖
回帖
粉丝
2
你是在15pb培训,感觉如何?
2021-6-14 00:35
1
雪    币: 14484
活跃值: (17483)
能力值: ( LV12,RANK:290 )
在线值:
发帖
回帖
粉丝
4
感谢分享
2021-6-14 17:30
0
雪    币: 669
活跃值: (2173)
能力值: ( LV4,RANK:45 )
在线值:
发帖
回帖
粉丝
5
TCONEONE 你是在15pb培训,感觉如何?
感觉挺好的,想学可以去试课
2021-6-14 19:52
0
雪    币: 15170
活跃值: (16832)
能力值: (RANK:730 )
在线值:
发帖
回帖
粉丝
6
师傅有时间整理一下格式吧,格式有点混乱现在
2021-6-15 20:31
0
雪    币: 292
活跃值: (795)
能力值: ( LV6,RANK:90 )
在线值:
发帖
回帖
粉丝
7
这个洞我记得我在另一个帖子回复过,关于漏洞成因的问题很多人是认为没有校验长度,实际上是错误的校验长度,楼主可以关注一下你上传途中有一个地方检查了dwBytes,对比方式是dwBytes<8则返回error code,实际上这里应该检查的是dwBytes > 8返回error codes,正因为这样传入dwBytes为一个极大值时才能通过判断直接进行memcpy,很多小伙伴分析漏洞的时候,只分析到触发漏洞的原因,而不是root cause,第一是在进行漏洞修补和防御的时候不利于阻止攻击,因为如果root cause再更靠前的位置,可能补了这里,而另一个地方仍然可能出发漏洞,哪怕是微软现在在修补漏洞的时候依然有可能会犯这样的错误,没有找到根本原因,所以在漏洞分析的时候最好就是进行一次bindiff,看一下微软是怎么修补的这个漏洞,我记得微软对这个漏洞的修补方法是对dwBytes是否为8进行了判断,如果dwBytes!=8则直接返回错误。
2021-6-16 18:32
0
雪    币: 669
活跃值: (2173)
能力值: ( LV4,RANK:45 )
在线值:
发帖
回帖
粉丝
8
Keoyo 这个洞我记得我在另一个帖子回复过,关于漏洞成因的问题很多人是认为没有校验长度,实际上是错误的校验长度,楼主可以关注一下你上传途中有一个地方检查了dwBytes,对比方式是dwBytes 8返回erro ...
嗯嗯,谢谢大佬指点呀
2021-6-17 10:30
0
雪    币: 669
活跃值: (2173)
能力值: ( LV4,RANK:45 )
在线值:
发帖
回帖
粉丝
9
有毒 师傅有时间整理一下格式吧,格式有点混乱现在
嗯嗯,好的
2021-6-17 10:30
0
游客
登录 | 注册 方可回帖
返回
//