BYR Achieve · 镜像论坛

By swan http://hi.baidu.com/0x557/blog/item/9e0686f46e193b6dddc47489.html 如果跳出一个计算器，那是一个玩笑，如果什么都没跳出来，那是一个神经病。 ——唐纳德·牛大腿当然，还有一种情况是你打开了然后闪了一下又打开一个正常文档，接下来有两个分支：甲）你勤打补丁的话，你是个VIP；乙）你不打补丁的话，你是菜鸽子。由于科普三大定律第一条的约束，我不准备讨论菜鸽子，只讨论你是VIP的情况，顺带说一句，如果遇到了，麻烦VIP同学把样本fw一份给我。最常见的流程，我拿doc文档做例子，是成功溢出->搜索自己的句柄->定位文件-> 释放并执行绑定的东东->关闭并替换掉自己 ->打开已经修复正常的文档。这样有两个好处，第一是你打开后确实看到的是一个文档，第二是以后再打开都正常，当事人不能反复重现第一次闪一下再打开的情况，只好上医院去看看是不是自己有幻视。对于找当前的文件这个过程，常见方法是像搜索SOCKET一样搜索句柄然后用 GetFileSize判断大小来确定，偶尔也见到有在stack上搜索": \"和".doc"来判断当前打开文件的，方法效果都一样，也说不上谁好谁不好，只是第一个方法写起来简单些。问题是，office不同版本处理错误的情况还有所差别，比如Excel和PowerPoint都存在的，对同一个漏洞，某些版本上也许先对恶意文件进行了处理（比如en ppt某些版本打开的时候文件长度已经不对了），某些版本可能就没有，这个时候作为一个固定值的文件大小可能就失效了，后一种方法通用性就好些。如果非要用文件大小来判断的话，也不是不可以，先估计下文件大小可能的范围，然后在这个范围内的句柄都测试一下，读读看某个特定位置的特定值，满足就表示搜索到了。GetFileSize然后比较预定值常见于word的exp中，搜索stack的在SmartTag见过，最后那个比较可靠的方法在ppt的某个 exp中有人用过，不知道有没有其他更牛的方法，估计也就这两条路子，最多稳定性上增加点。释放和执行没什么说的。修复自己也没什么好说的，就是把预先绑定的正常文件读来覆盖写一下，或者填充足够的字节覆盖拷贝回来。绑定的文件，有的直接添加在文档的最后面，也有放在文件内容当中。放在文件当中有长度的限制，doc的见得不多， xls和ppt的相对多点。绑定文件到后面的没有长度的限制，绑 128M的win2k sp4补丁都没有问题，但是容易被启发式的杀毒引擎杀。现在基本上异或一两个字节是逃不过的，所以有些干脆就把PE的DOS head自己编码到shellcode里面去，避免了找PE文件头及其简单加密形式的启发式杀毒，还有懒点的用一些规律较为复杂的异或方法。目前还没有变态到用DES或者其他什么的加密绑定文件，一种可能是这样的神经病不存在，也有可能是我没有见过。善后的工作主要分为两个路子。一种是特定的漏洞，你修复了上下文，跳回去还能执行，另一种只能结束掉当前进程，另外开一个。特别特别罕见的情况是漏洞虽然产生了异常，但是因为异常处理机制（有时是不在主线程），不用管它都不会影响当前进程，目前只见到过两种，都是图片引起的，后面再说。对于doc什么的，很多call [xxx+xx]，也就是非典型栈溢出的那种，基本上都能恢复上下文，如果懒一点的，大概也就是处理一下注册表免得下次打开报错，然后新开一个doc就完了（有些exp连注册表都没有处理，我个人揣测应该是缺乏职业道德的缘故）。有些IE的漏洞也可以相同处理，总之是具体情况具体分析，很难有一个统一的流程做出一个完美的善后工作，我也没有见过把邮箱里面原始文档也给处理掉的，所以很多情况下执行前后的文件用fc /b肯定能够看出来，不过这个要考虑的东西实在太多，不是神经不正常的人就能做出来的。手工打制这种东西，有时候也是很讨厌的。比如是图片的漏洞，要嵌到doc里面，可能一拖进去就Crash了。出现这样的情形，正常人的做法是先弄个正常图片，保存，然后二进制处理doc把图片弄不正常，这个方法可能不适用于大多场合，因为文件嵌进去后会被压缩，最后压得你也看不出来是个什么东西。不太正常的人会先分析漏洞的成因，然后先下断点，拖图片进去，然后在异常出现前修改相关寄存器的值，让异常不出现（这个过程可能会重复达20次以上），最后存盘。最不正常的人是直接手工patch 一个补丁，这样世界上就有了一台不存在这个漏洞的机器，随便怎么编辑都没问题。最后这个往往可以连漏洞带笔记本一起卖掉，就像成都法拉利通常和促销小姐一起卖掉一样。图片的整数溢出是很难利用的，但不意味着不能利用。WORD最恶心的一点是 0x12ffff是栈底，但0x130000开始是默认堆的开始（也有可能是我记忆的问题，因为我刚过完生日，变老了），所以主线程栈上的整数溢出可能会把整个该死的堆都写成一块乱麻，几乎不可能恢复。这个只能说还有留有点能利用的种子，如果遇到不是主线程上的溢出，要么stack cookie起作用，要么根本没有SEH给你覆盖，只能抱着枕头去哭了。写到这里我已经忘了最开始打算写的内容，隐约觉得还有点重要的东西没写，就是想不起来。不过既然扯到这里，不如索性多扯点八卦什么的。可能你看到一个 exp，觉得有点想找找到底是谁写的，如果你有渠道，直接问可以，但就怕别人神秘兮兮地告诉你，某高人写的，你就傻了。其实哪来这么多高人，平时看看代码的风格，大概也能猜出来是哪些人搞的鬼。最简单的看banner。cnhonker什么的肯定写得超级复杂，名字也署上了，不用猜；SST的exp也是复杂得见鬼，前面一堆废话，每一步还告诉你正在干什么，完全有病；其他像Whitecell什么的，风格好像也有点类似，具体比较一下里面的内容就应该能猜出来。有时候也会有这样的exp，什么都没有，给个参数，显示ok 然后shell就出来了，这种多半是重庆高人写的，如果还不确定，可以看看命令，比如明明是通过hook NdrXXXXXX2来复用端口的RPC漏洞，命令却还是iis开头的那种。其他，没有生成器只有样本的情况下，可以直接把doc之类的拖到ida里面去看， shellcode一上来就加个异常处理的，多半是严谨的北京博士生，ret是个cf ec c2 4f 而且精心恢复了上下文的，作者应该在成都等等等等。如果都猜不出来的话，大致方向还是能确定，比如office系列的，多半是北京上海成都，端口复用文件上传下载的大多是重庆人，标0day只是勉强能用的可能成都作者偏多，shellcode完全是unicode形式大小写字母而且还他娘的带变形的应该是我写的——不过也许你永远看不到，因为我压根没有写过那样的。 p.s. 科普加扯淡，大家不要对号入座！

[转帖]当你打开一个文档