给一个MIPS的系统porting Linux的时候被郁闷了，休息休息换换脑子。这里简单介绍一下如果利用spike[1]对程序进行黑盒测试。这里就挑选最新的Messenger漏洞作为测试的目标。spike一般是用来发现漏洞的，这里我们用来重现漏洞就有点...。不过重现漏洞只是一个示例。
spike是immunitysec公司的Dave Aitel写的一个黑盒进行安全测试的工具。最开始的spike是作为nmap-hackers邮件列表评比的Top 75 Security Tools中的spikeproxy出名的，spikeproxy是用来做web penetration test的。spikeproxy是SPIKE Suite Tools中的一部分，这里我们谈的是另外一部分SPIKE Fuzzer Creation Kit。这一部分为我们提供了使用黑盒的方式对程序进行安全分析的库，以下的构造就是基于这一部分进行的。spike的最新版本是2.8，从邮件列表上的消息看，不久2.9也快发布了。
这里简单的八卦一下，Dave Aitel以前是在@stake[3]工作的，现在你也可以在@stake上找到spike v1.8的下载。后来Dave Aitel创建了自己的公司immunitysec。之所以专门谈一下这个人，是因为在efnet发布的那份假的phrack62[4]上，有一篇<<Eye on the Spy的文章，里边提到了Dave Aitel和iDefense，专门收购漏洞从事盈利性活动，违背了full-disclosure的精神。不知道大家对这种行为如何评价？
这里转入正题。在进行最终的测试之前，我们需要了解一下Windows上的Messenger服务。最开始Messenger的表现形式就是win9x中的popup程序，与现在不同的是popup之类的Messenger一般是利用SMB协议中的Send Single Message Block Request进行消息传递的(当然也有Multi Message Block的)，相同的这种机制比如linux下的smbclient -M。而进入到win2k/xp以后，又提供了RPC上的Messenger服务。这里针对的就是RPC上的Messenger。
[注]:目前RPC的标准有SUN RPC和DCE RPC。Windows上的RPC是对DCE RPC进行的移植，由于对RPC接口命名方式不同，称为MS RPC。这里指得都是MS RPC。
进行分析的步骤大致如下:
1.对RPC的Messenger如何交换信息进行分析
2.构造测试框架
3.运行
--[ RPC上的Messenger的分析
在用ethereal[5]对net send命令发送的报文进行分析后，发现利用RPC发送Message的过程大致如下(UDP):
Source port1 - DCE-RPC的Messenger服务报文 - Target 135
Target port2 - DCE-RPC conv_who_are_you - Source port1
Source port1 - DCE-RPC conv_who_are_you2 reply - Target port2
Target port2 - DCE-RPC ACK - Source port1
Target 135 - DCE-RPC Response - Source port1
Source port1 - DCE-RPC ACK - Target 135
[注]: conv_who_are_you, conv_who_are_you2 reply, Response, ACK都是RPC协议中的PDU(Protocol Data Unit)类型。
这样一个过程做起来实在是复杂，port1除了发送Message，发送Response回应报文外，还得负责处理发送过来的conv_who_are_you的协商。实现起来虽然不难，但是体力劳动还是有很多。多亏现在Messenger上的垃圾广告的流行，人们对Messenger的分析都已经很深入了。google的时候无意中在Full-Disclosure[6]上发现只要把RPC报文中的标志位Idempotent和NoFack置为1，就不存在conv_who_are_you的协商了。这样一个单独的UDP报文就可以搞定整个过程(既然是单独的UDP报文就可以搞定，那伪造IP发送消息... //grin，不过这里用不到)，但是考虑到需要根据回应报文判断测试的结果，最后这个过程就简化为:
Source port1 - DCE-RPC的Messenger服务报文 - Target 135
Target 135 - DCE-RPC Response - Source port1
根据RPC的协议[7]，RPC的PDU分为两种类型，无连接(Connectionless)和有连接的(Connection-Oriented)。UDP上的RPC自然是无连接的了。
其中RPC头的数据结构为
typedef struct {
unsigned small rpc_vers = 4; /* RPC protocol major version
(4 LSB only)*/
unsigned small ptype; /* Packet type (5 LSB only) */
unsigned small flags1; /* Packet flags */
unsigned small flags2; /* Packet flags */
byte drep[3]; /* Data representation format label */
unsigned small serial_hi; /* High byte of serial number */
uuid_t object; /* Object identifier */
uuid_t if_id; /* Interface identifier */
uuid_t act_id; /* Activity identifier */
unsigned long server_boot;/* Server boot time */
unsigned long if_vers; /* Interface version */
unsigned long seqnum; /* Sequence number */
unsigned short opnum; /* Operation number */
unsigned short ihint; /* Interface hint */
unsigned short ahint; /* Activity hint */
unsigned short len; /* Length of packet body */
unsigned short fragnum; /* Fragment number */
unsigned small auth_proto; /* Authentication protocol
identifier*/
unsigned small serial_lo; /* Low byte of serial number */
} dc_rpc_cl_pkt_hdr_t;
其中需要事先知道的是object和opnum,一种方法就是从ethereal中的报文中构造，另外一种方法就是使用反汇编msgsvc.dll，使用rpcenum.idc[8]获得这些信息。第二种方法的输出如下:
------------------------------------
RPC Interface Enum $Revision: 1.8 $, (c) 2003 kkqq
------------------------------------
Length: 68
Interface UUID: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc
Major Version: 1
Minor Version: 0
Transfer UUID: 8a885d04-1ceb-11c9-9fe8-08002b104860
Major Version: 2
Minor Version: 0
Dispatch Table: 76818558
Dispatch Table Count: 1
Dispatch Table Addr: 76818550
DisPatch 1: NdrServerCall2
EndPoint Count: 0
EndPoint: 0
Default Manager: 0
Interpreter Info: 76812988
Flags: 0
------------------------------------
所以object为Interface UUID: "5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc"。只有一个Dispatch，opnum从0开始，那么就是0了。其余字段在下一部分介绍。
下来就是紧跟着RPC头的数据部分了。ethereal不愧是最强的协议分析自由软件。直接从捕获到的报文构造就是了。数据结构大致如下:
typedef struct {
WORD MaxCount;
WORD Offset;
WORD ActualCount;
BYTE Data[ActualCount + ActualCount%4 ? (4 - ActualCount%4) : 0];
} element;
typedef struct {
element Server;
element Client;
element Message;
} data;
之所以用ActualCount + ActualCount%4 ? (4 - ActualCount%4) : 0表达，是因为RPC中的字符串是要求4字节对齐的，不足的部分补0。另外字符串的长度是计算字符串的终结符'\0'的。
对应上边的数据结构，消息发送之后弹出的对话框内的文本形式如下:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 在2003-11-3 10:16:14从Client.Data到Server.Data的消息 ┃
┃ ┃
┃ Message.Data ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
实际的测试中发现发送一次以后，需要等很长时间第二次发送才能被正确处理。原因是DCE-RPC为了防止报文重复，一定时间内(似乎要几分钟)之内不再接收重复报文。如果真是这样的话，几分钟测一个testcase,也真是会等死人的。
测试发现，只要把DCE-RPC报文中的Activity GUID随便换一下，就没有什么事情了。
下来可以开始用SPIKE构造测试脚本了。
--[ 使用spike构造测试框架
之所以挑选SPIKE,是因为SPIKE提供了各种各样的构造函数。例如s_binary可以构造二进制数据，s_string可以构造字符串，s_unistring可以构造UNICODE字符串。类似这样的还很多，可以参考源码中的spike.h中s_xxxx之类的函数(SPIKE的文档做的不详细，想挖什么东西还是看源码来得直接一点)。
SPIKE构造测试集的方法称为Block-Based Protocol Analysis[9]。比如上边我们提到的RPC Header中有一个字段为len(Length of packet body)。如果让我们自己构造的话，还需要计算整个Packet的长度。如果在spike中，只需要定义如下的形式
s_block_start("Data")
s_binary("01020304");
s_block_end("Data");
在需要的地方使用以s_binary_block_size开头的函数，例如
s_binary_block_size_intel_halfword("Data");
就可以把标记为Data的Block的长度压到栈里边。
SPIKE的另外一个优势就是Dave Aitel的Fuzz理论，就是构造一些特殊的数字或者字符串作为程序的输入，检查程序是否能够处理这些异常数据。看过OUSPG[10]对协议进行安全测试的朋友应该会看到，在测试的过程中有一个异常元素构造(Design of Exceptional Elements)的过程，这其实就是SPIKE中提供的fuzz机制。只不过SPIKE提供的是较为常见的一些形式，例如:长字符串，带有格式串的字符串，大整数，负数，其他各种畸形字符等等(可以看源码中spike.c中的s_init_fuzzing函数)。相比之下，OUSPG进行的设计是有针
