使用SPIKE进行安全测试字符串长度计算工具下载
创建时间：2003-11-06
(My blog is here kkqq.blogdns)
    给一个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];

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。