当前位置：文档之家 › cve-2012-0158分析报告

cve-2012-0158分析报告

  • 格式：pdf
  • 大小：648.63 KB
  • 文档页数：11

计算器弹出来，接着 Word 就退出了。但我再一次打开这个样本，发现程序报错。
所以在测试前记得先备份，因为下面我们多次要打开这个样本。
漏洞分析
打 开 样 本 弹 出 计 算 器 ， 所 以 Shellcode 应 该 会 调 用 WinExec 函 数 。 用 Windbg 附 加 WINWORD.EXE，bp kernel32!WinExec 下断
首先分配 20 个字节空间 275C89CA sub esp, 14h 然后调用 275C89DA call sub_275C876D
; 分配 20 字节局部空间
这个 call 的功能是从样本读取 dwBytes，这里是 0CH 字节返回到 eax 指向的内存地址。读取 到的 0xC 字节如下所示： 00127b70 43 6f 62 6a 64 00 00 00 82 82 00 00 接着程序
然后运行，把样本拖进 word。
程序断在 WinExec 入口点。 这时候计算器还没弹出来， 看一下 WinExec 的参数， 发现是 a.exe。 我去到这个目录，发现它就是一个计算器。看来 shellcode 应该是把系统的 calc 复制到别的 目录再运行它。
WinExec 的返回地址是 0x00127dee。往上翻翻，没发现 shellcode 从哪开始。Kb 打印堆栈 ChildEBP RetAddr Args to Child 00127b20 00127dee 0cd5a5b0 00000000 0cd5a5b0 kernel32!WinExec WARNING: Frame IP not in any known module. Following frames may be wrong. 00127b50 275c8a0a 07d8c008 0cd3b868 0001c000 0x127dee 00127b8c 00127c05 1005c48b c7000001 4d032400 MSCOMCTL!DllGetClassObject+0x41cc6 00000000 00000000 00000000 00000000 00000000 0x127c05 重新载入，在 MSCOMCTL!DllGetClassObject+0x41cc0 下断
如果读取的 12 字节开始 4 个字节不等于 0x6A626F43h，则跳转到错误处理。否则执行来自275C89F3 cmp
[ebp+dwBytes], 8
我这里[ebp+dwBytes]为 0x00008282。显然 0x00008282 大于 8，所以程序转到
这里其实就是我们真正溢出的那个 CALL。我们看这个 call 有三个参数 Sub_275C876D（8 字节局部空间起始地址，lpMem，字节数） 【这里字节数是 0x8282】 跟进这个 call 看看，首先 275c877f 6a04 push 4 275c8781 51 push ecx 275c8782 53 push ebx 275c8783 ff500c call dword ptr [eax+0Ch] ole32!CExposedStream::Read (771ca84b)} 读取 4 个字节到[ebp+var_4]，返回值和 0 比较，如果小于 0，读取失败，转到失败处理，否 则
[ebp+var_4]和[ebp+dwBytes]即 0x00008282 比较，相等则
分配 0x8282 字节空间，接着
读取 0x8282 字节到刚才分配的堆空间。接着
我们看到：275C87CB rep movsd 再看看此时的 EDI=0x127b7c ESI=0x20e008 (指向前面读取的 0x8282 字节) ECX=0x20a0
前言
Cve-2012-0158 漏洞出现在 MSCOMCTL.OCX，是微软 Office 系列办公软件在处理 MSCOMCTL 的 ListView 控件的时候由于检查失误，导致攻击者可以通过构造恶意的文档执行任意代码， 本文我将分析这个漏洞的起因。
漏洞验证
我从网上拿到了一个样本：May.doc。首先我在虚拟机用 Word 打开这个样本，
是不是很熟悉呢？，到这里我们知道的信息如下： Shellcode 执行发生在下面 call 返回 275e7015 e8ad19feff call MSCOMCTL!DllGetClassObject+0x41c83 (275c89c7) 溢出发生在 275c8a05 e863fdffff call MSCOMCTL!DllGetClassObject+0x41a29 (275c876d) Shellcode 通过 jmp esp 覆盖返回地址利用。顺便 dump 部分 shellcode 00127b88 12 45 fa 7f 90 90 90 90 90 90 90 90 8b c4 05 10 .E.............. 00127b98 01 00 00 c7 00 24 03 4d 08 e9 5a 00 00 00 6b 65 .....$.M..Z...ke 00127ba8 72 6e 65 6c 33 32 00 df 2d 89 8c 1b 81 7d ef 42 rnel32..-....}.B 00127bb8 9d 85 85 d6 4e 99 59 5a 61 d8 54 93 77 77 21 9d ....N.YZa.T.ww!. 00127bc8 4a 62 68 c3 53 a3 83 6a 6b df 5c 5a 8a 1d 2b 4f Jbh.S..jk.\Z..+O 00127bd8 2c 45 28 81 71 f5 40 01 92 8f 05 ba 36 c1 0a 61 ,E(.q.@.....6..a 00127be8 61 61 61 73 68 65 6c 6c 33 32 00 8b 98 8a 31 61 aaashell32....1a 00127bf8 61 61 61 6f 70 65 6e 00 e8 11 02 00 00 6a ff e8 接下来用 IDA 打开有漏洞的 MSCOMCTL.OCX。定位前面那两个关键 call，先看上层 call 275e7015 e8ad19feff call MSCOMCTL!DllGetClassObject+0x41c83 (275c89c7)
断在这个 call 的上一句，Kb 发现这一层函数的返回地址是 0x 275e701a，它前面一个 call 是
接着两次 p，然后搜索内存
在 0x00127b88 发现万能跳转 0x7ffa4512 和 shellcode。并且在 275c8a05 e863fdffff call MSCOMCTL!DllGetClassObject+0x41a29 (275c876d) 之前这里还没有被 shellcode 覆盖，显然，溢出发生在 275c8a05 e863fdffff call MSCOMCTL!DllGetClassObject+0x41a29 (275c876d) 接着上面，我单步执行
漏洞利用
此样本是通过用 jmp esp 地址覆盖函数返回地址进行利用的
搜一下样本，发现 shellcode
之前看了通过利用异常处理进行的利用。 就像试试这个漏洞能不能用此方法。 在溢出即将发 生时候 275c87cb f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 我 dump 异常链 0:000> !exchain 0012f908: USER32!_except_handler3+0 (77d3edbf) CRT scope 0, func: USER32!UserCallWinProcCheckWow+155 (77d4f0cc) 0012f968: USER32!_except_handler3+0 (77d3edbf) 0012ffb0: WINWORD!wdGetApplicationObject+27bcf8 (30a6c5d4) 0012ffe0: kernel32!_except_handler3+0 (77e74809) CRT scope 0, filter: kernel32!BaseProcessStart+29 (77e737c8) func: kernel32!BaseProcessStart+3a (77e80128) Invalid exception stack at ffffffff 此时 EDI=0x00127b7c， 复制 33408 字节， 最多覆盖到 0x12FDFC， 而最近的异常处理在 0x12f908。 理论上可以利用。但是当我修改样本 shellcode 后面的数据时 shellocde 后面的数据在复制前 已经不是原始的的了。所以尽管可以覆盖到 SEH，但数据似乎是不可控的。
exit(-1); } } sub_275C876D(temp[8],lpMen,*temp[8]) { char val[4]; if( Read(val,4) <0 ); //继续从样本读取 4 字节到 temp { exit(-1); } else { if(val[0]==*temp[8]) { if( buffer=HeapAlloc(hHeap,0,val[0]) ); //分配 temp[0]字节空间 { Read(buffer,val[0]); //从样本读取 temp[0]字节到临时空间 memcpy(temp[12],buffer,0x8280); //复制 0x8280 字节到 sub_275C89C7() 剩下的 8 字节空间，导致覆盖返回地址 } else { exit(-1); } } else { exit(-1); } } }
而我们看 275e7015 e8ad19feff
call

合集下载

CNNVD-201111-144漏洞及其利用分析

CNNVD-201111-144漏洞及其利用分析

对Cve2011-3402的利用分析早就听说duqu是第二代的stuxnet，心中就保留了一份好奇。

之前对stuxnet的分析不仅可以看到作者在漏洞挖掘上的功力，同时也对作者那些精巧的利用思路由衷敬佩。

而且，据说这个内核漏洞是以doc形式来触发的，心中更是想仔细跟一下。

搜了一下，找到两篇比较好的文章启明星辰的分析，以及kk牛的《Analysing CVE-2011-3402 Font Parasing Vulnerability》。

这两篇资料，对我的分析起到了很大的帮助。

一、漏洞原理在“启文”和KK的文章中，已经把漏洞原理说得比较清楚了，这里就是对他们所描述原理的理解、抄袭。

Win32k在处理字体的时候，需要计算出两个重要的变量：ulBitmapOffset、ulWorkMemSize。

如果计算出来的ulBitmapOffset>ulWorkMemSize则会导致问题。

因为，sfac_GetSbitBitmap函数会对ulBitmapOffset+0xA48位置的数据进行了修改，导致修改了后面结构fnt_GlobalGraphicStateType中的数据。

而ulBitmapOffset+0xA48恰好指向fnt_GlobalGraphicStateType中的cvtcount成员。

将修改cvtcount的值改得比较大以后，将从而使得解析引擎RCVT和WCVT函数在后面读和写ControlValueTable的时候越界读写。

Win32k!sfac_GetSbitBitmapbf988bab 8d2424 lea esp,[esp]bf988bae 6685c0 test ax,axbf988bb1 8b5528 mov edx,dword ptr [ebp+28h]bf988bb4 8d3413 lea esi,[ebx+edx]bf988bb7760e jbe win32k!sfac_GetSbitBitmap+0x109 (bf988bc7) bf988bb9 0fb7f8 movzx edi,axbf988bbc 8bff mov edi,edibf988bbe 8a11 mov dl,byte ptr [ecx]bf988bc0 0816 or byte ptr [esi],dl由于字体解析的时候 ulBitmapOffset越界，sfac_GetSbitBitmap函数修改了Bitmap后面相邻结构中的变量(fnt_GlobalGraphicStateType中的cvtcount)，导致cvtcount变大，从而使得解析引擎RCVT和WCVT函数在后面读和写ControlValueTable的时候越界读写。

网络安全信息与动态周报-2012年第32期-国家互联网应急中心

网络安全信息与动态周报-2012年第32期-国家互联网应急中心

一、本周网络安全基本态势1的主机数约为129.7万个，较上周环比减少了13.8%；无新增网络病毒家族；境内被篡改政府网站数量为45个，较上周环比上升了7.1%；境内被植入后门的政府网站数量为104个，较上周环比增加了30%；针对境内网站的仿冒页面数量为257个，较上周环比减少了12%；新增信息安全漏洞108个，较上周环比大幅减少了44.6%，其中新增高危漏洞36个，环比大幅减少了63.3%。

本周网络病毒活动情况1、网络病毒监测情况本周境内感染网络病毒的主机数约为129.7万个，较上周环比减少了13.8%。

其中，境内被木马或被僵尸程序控制的主机约为18.1万个，环比减少了 6.7%；境内感染飞客（Conficker）蠕虫的主机约为111.5万个，较上周数量环比下降了14.9%。

木马或僵尸程序受控主机在我国大陆的分布情况如下图所示，其中红色区域是木马和僵尸程序感染量最多的地区，排名前三位的分别是广东省约2.2万个（约占中国大陆总感染量的12.4%）、江苏省约1.4万个（约占中国大陆总感染量的8%）和浙江省约1.3万个（约占中国大陆总感染量的7.3%）。

注1：一般情况下，恶意代码是指在未经授权的情况下，在信息系统中安装、执行以达到不正当目的的程序。

2、TOP5活跃网络病毒本周，中国反网络病毒联盟（ANV A ）2整理发布的活跃网络病毒3如下表所示。

其中，利用网页挂马或捆绑下载进行传播的网络病毒所占比例较高，病毒仍多以利用系统漏洞的方式对系统进行攻击。

ANV A 提醒互联网用户一方面要加强系统漏洞的修补加固，安装具有主动防御功能的安全软件，开启各项监控，并及时更新；另一方面，建议互联网用户使用正版的操作系统和应用软件，不要轻易打开网络上来源不明的图片、音乐、视频等文件，不要下载和安装一些来历不明的软件，特别是一些所谓的外挂程序。

注2：中国反网络病毒联盟（Anti Network-Virus Alliance of China ，缩写ANVA ）是由中国互联网协会网络与信息安全工作委员会发起、CNCERT 具体组织运作的行业联盟。

通过Anglerfish蜜罐发现恶意软件威胁

通过Anglerfish蜜罐发现恶意软件威胁


ser ver
client
ser ver
Port Closed
Port Open
以SYN端口扫描为例，当蜜罐程序未开放相应端口时，只能接收到扫描程序的SYN包。
First Data
client
server
client
ser ver
client send data first
server send data first
借鉴前人的经验
• Blackhole是Github上的一个开源项目，我的灵感来源于此，并在此基础上开始设计和开发 • 在模拟协议和漏洞过程中，吸取了Kippo，Dionaea等开源项目经验，积极使用现有的应用协议库 • 使用Python语言开发，基于Gevent模拟Server端应用协议
REFERENCE 1 https:///dudeintheshell/blackhole 2 https:///DinoTools/dionaea 3 https:///fabio-d/honeypot 4 https:///desaster/kippo
client
ser ver
client
ser ver
PING
PONG
always answer syn flag
always reply true flag
遇到的问题
• 如何判断/提升Fuzz testing成功率 • 只能对已知的应用协议进行Fuzz testing • Fuzz testing不成功导致会话停止
一.我对蜜罐的理解和需求
• 蜜罐协议模拟是基础，蜜罐数据分析是核心，捕获恶意样本是其目的 • 能够在TCP/UDP全端口捕获未知的恶意扫描软件威胁 • 能够模拟影响面广泛的应用协议和漏洞，优先模拟IoT，服务器等漏洞场景 • 蜜罐程序方便协议扩展，蜜罐数据结构方便数据分析
Spring漏洞分析（1）--CVE-2017-8046分析

Spring漏洞分析（1）--CVE-2017-8046分析

Spring漏洞分析（1）--CVE-2017-8046分析简介Spring Data REST的⽬的是消除CURD的模板代码，减少程序员的刻板的重复劳动，但实际上并没有很多⼈使⽤。

很少有请求直接操作数据库的场景，⾄少也要做权限校验等操作。

⽽Spring Data REST允许请求直接操作数据库，中间没有任何的业务逻辑漏洞的原因是对PATCH⽅法处理不当，导致攻击者能够利⽤JSON数据造成RCE。

本质还是因为Spring的SPEL解析导致的RCE，⼤部分Spring框架的RCE都是源于此参考：SPEL 测试package com.example.accessingdatarest;import org.springframework.expression.Expression;import org.springframework.expression.spel.standard.SpelExpressionParser;public class SpelTest {public static void main(String[] args) {//calc 弹出计算器String spEL="T(ng.Runtime).getRuntime().exec(new ng.String(new byte[]{99,97,108,99}))";testSpEL(spEL);}private static void testSpEL(String spEL){SpelExpressionParser parser = new SpelExpressionParser();Expression exp = parser.parseExpression(spEL);exp.getValue();}}环境搭建官⽅不可能在教程中采⽤存在漏洞的代码，所以我们需要⼿动将pom依赖⽂件中SpringBoot的版本修改为存在漏洞的版本。