Microsoft System RPC 漏洞挖掘

MSRPC Fuzzing with SPIKE 2006

Dave Aitel

d41444d184254b35eefd341f

概览

?Fuzzing 简介

?MSRPC快速简介和相关协议?MSRPC fuzzing的历史和这些技术的缺点?Immunity‘s专注于MSRPC fuzzing ?MSRPC的未来(and hence, of MSRPC fuzzing)

什么是Fuzzing?

?我们所有人都从把小字符串变成大字符串中获益

?Fuzzing所做的就是通过特殊的方法来对应用程序进行输入

–主要的好处: 没有误报. 你通过fuzzing找到

的所有bug都是可重现的(虽然它可能无法利用)

–主要的麻烦: 速度很慢

为什么要fuzz?

?即便有安全公告或二进制比较工具，相对逆向工程而言，fuzzing更容易找到bug

?Fuzzing能找出通过二进制或源代码分析难以发现的bug

?A generalized fuzzer for a bug will tell you if a patch is good enough to cover edge cases or if it has an edge case that is still vulnerable

什么是fuzz的最好方法??Non-fault-injection approach

–我们不直接注射数据到程序的API中，因为它将导致误报

?例如绕过验证，对输入进行有效性检查等?Fuzzing专注于发现可利用的漏洞–这不是关于QA –只是关注我们感兴趣的,即

整数溢出和缓冲区溢出

哪种类型的应用程序适合

fuzzing

?暴露在网络上的应用程序

–所有DCE-RPC!

?闭源应用程序

?看起来没有经过代码审核的应用程序

?难于获取的应用程序

?相对复杂的应用程序

–对复杂的应用程序进行审计将花费大量的金钱!

Fuzzing Mindset ?There's a certain magic to a good fuzzer since there is no guarantee it will find anything

?Fuzzers将花费相当长的时间

–例如几周, 几个月

?当你开始开发一个fuzzer时，你要相信自己不是在浪费时间

?大家看不起fuzzer

Fuzzers的问题?Tokenization is rarely perfect

?容易错失私有扩展

?Problem itself is exponential

?一般只有在找到一些潜在的bugs后才能吸引blackhat

?But does give you a good initial indication of the “stance”of the application

怎么打造fuzzer ?Tokenization

?产生正常的流量

?产生异常的流量

?检测和分析问题

?分析fuzzer的质量

Tokenization

?分解网络协议为常量(not fuzzed)和变量(fuzzed)

?类型

–字符串, 整数, 大小, 二进制块

?通常常量都是头字符串，协议常量，网络交互的响应等

?Over-tokenization 将使你的fuzzer变得很慢

?Under-tokenization 将使你的fuzzer发现不了任何东西

产生正常流量

?阅读和分解RFC‘s 或其它可读的协议描述

–fuzzing协议中没有实现的部分通常只会浪费你的时间

–将错失私有的扩展

?对协议进行逆向工程

–能够半自动完成

–If tool is flexible enough, human input can be

invaluable

?嗅探和静态分析

–Even very dumb replay-and-bit-flipping can find many bugs

?如果完成的不好，目标应用程序将忽略你的大部分流量

产生畸形?Transforming normal traffic into malformed traffic, but in a way that is likely to cause exploitable problems

?Bit-flipping is most simplistic

–For each bit we send, iterate over

sending the opposite

?改变流量中的一个部分将可能需要改变其它所有部分

–例如, 内容长度检查

Fuzzing is not Fault

Injection

?Fuzzing时你将从网络层开始测试所有层

?在fault injection时，你直接向API插入错误的数据?有许多层你是不知道的

?Fuzzing 永不产生误报

?fault injection的缺点

–需要一个调试器，它将改变程序的操作

–产生误报

SPIKE简介

?从2000年开始发布，最早的通用网络协议fuzzers 之一

–Greg的Hailstorm是另外一个类似的(注意:

它与当前的Hailstorm差别很大–之前的是一个商业的fuzzer，可用于任意协议)

?介绍唯一的基于块(block-based)的fuzzing

?包括HTTP,FTP及其它协议模块

?用底层C编写(考虑速度)

?基于GNU 许可证来发布

Block-based fuzzing ?协议基本上都由同种元素组成

?常量, 块, 变量

–

?把每个变量都用测试的字符串替换，并更新相关的sizes

?并且在每个变量的前面和后面插入测试字符串

基于块fuzzing的优势

?产生畸形流量的捷径

?Gut-feel: 找到有趣bugs

?Fuzz-streams 是可复用的

?接近原始的有效流

?能够比较容易的对被其它协议封装的协议进行fuzz

其它基于块的fuzzers ?Peach (基于Python的fuzzer)

–免费的

?d41444d184254b35eefd341f ProtoVer (同样是基于Python)–商业的

Immunity与MSRPC ?2000 –SPIKE, dcedump, ifids ?2002 –CANVAS msrpc.py (支持验证、本地管道、SMB/DCE分片)

?2003 –MSRPC 审计类

?2004 –MOSDEF集成lexx.py和yacc.py

?2005 –unmidl.py, DCEMarshall in CANVAS

?2006 –SPIKE 2006

SPIKE 2006

?用Python重写并成为CANVAS攻击框架的一部分–从包括DCE-RPC协议组的纯python网络协议库里获益

–更容易扩展和使用

?增加基于字符串和整数的概念

–A few selected fuzz-variables are used

for EVERY variable in protocol while

fuzzing

–找更隐藏的bugs

–程序变慢了(但计算机速度在提高:>)

SPIKE选择的字符串

?我们用字符B来代替A，因为当我们发现一个堆溢出问题时，Windows内存管理标志中的B往往会让程序正常的崩溃

?我们在所有长字符串前面都加上\\、\\\\和

?我们使用长度从0到2200的字符串来捕捉单字节溢出问题

?我们也会使用已知的常引发问题的特殊字符串集

为何对MSRPC应用程序进行

fuzz?

?在微软默认的应用程序中有上千个可用的MSRPC接口

–Writing Microsoft Windows exploits

isn't going out of style any time soon ?有很多厂商的MSRPC平台上进行开发–这些厂商需要快速和简单的测试他们自己的接口

?Samba needs regression testing