DCE/MS RPC旁窥

                目录:

    ☆ DCE/MS RPC架构简介
    ☆ BIND操作简介
        1) "BIND Over TCP"简介
        2) "BIND Over Transaction"简介
        3) "BIND Over Write AndX"简介
        4) "BIND Over ..."扩展
        5) SMB_COM_TRANSACTION2与SMB_COM_NT_TRANSACTION
    ☆ PFC_OBJECT_UUID标志位
    ☆ MS02-045/Q326830
    ☆ WildPackets Free Filters for Detecting Malicious Worms/Viruses
    ☆ /pipe/epmapper
    ☆ 135/UDP相关讨论
        1) XP SP1的msgsvc.dll(5.1.2600.1309)
        2) 中文2000的msgsvc.dll(5.0.2195.4874)
        3) 通过135/UDP访问MGMT
        4) 通过135/UDP访问EPM
    ☆ Windows网络服务最小化
    ☆ MS05-040/KB893756
    ☆ DriverStudio Remote Control服务
    ☆ 参考资源

--------------------------------------------------------------------------

☆ DCE/MS RPC架构简介

本节属于科普性质，文字描述不那么规范，将就着看吧。

一个RPC服务可以绑定多种协议序列，也可以只绑定某一种协议序列，这是实现相关
的，没有定式。某接口绑定N种协议序列，就意味着有N条途径可以访问该接口。可以
用135dump.exe、ifids.exe等工具查询这类信息。

            +-- ncacn_ip_tcp(动态TCP口)
            |
DCE/MS RPC--+-- ncadg_ip_udp(动态UDP口)
            |
            +-- ncacn_np(固定的139、445/TCP口)
            |
            +-- ... ...(其它协议序列)

可以将DCE/MS RPC看作一层，这一层可以在不同的协议序列上跑，比如上面列出的三
种。实际上还有其它协议序列可用，但不常见，这里就不罗嗦了。

ncacn_ip_tcp与ncadg_ip_udp用到了动态端口，它们会向EPM接口注册所用动态端口，
而客户端可以向EPM接口查询服务端注册过的信息。如果客户端有其它手段提前知道
服务端所用动态端口，就可以省去向EPM接口查询的操作。

一般碰上的是版本5的RPC，ncacn_ip_tcp、ncacn_np等用的就是V5。而ncadg_ip_udp
用的则是版本4的RPC。V4与V5的差别很大。你在现实环境中很难观察到V4。历史上某
些版本的net send命令会用到V4，MS02-045/Q326830补丁取消了Messenger服务绑定
的ncadg_ip_udp协议序列，现在更难在现实环境中观察到V4了。

EPM接口本身是一个RPC服务，同样有多种协议序列可用来访问这个接口。

ncacn_np协议序列用到了SMB协议，DCE/MS RPC层位于SMB层上，SMB层再位于TCP层上。
有些文字会介绍说139/TCP口的通信是SMB层位于NBT层上，NBT层位于TCP层上。这一
点对于旁路协议分析来讲，没有必要区分，可以将NBT层那四字节划入SMB层。再简单
点说，旁路协议分析时，可以认为139、445/TCP仅仅是端口不同，没有其它区别。

SMB协议可以由多种命令来承载DCE/MS RPC层数据，同样是139、445/TCP上的通信，
因不同的SMB命令而导致不同的SMB层解码。

无论用哪种协议序列，用哪种SMB命令，访问一个RPC接口的典型步骤是:

a) Bind
b) Request

不同的协议序列、不同SMB命令就对应不同的Bind Over ...、Request Over ...。
分层解码后到了DCE/MS RPC这一层，就都一样了。

做DCE/MS RPC协议分析时，首先就应该关注Bind操作。

---------   ---------   --------------  -------
动态TCP口   动态UDP口   139、445/TCP口  ... ...
----+----   ----+----   --------+-----  ----+--
    |           |               |           |
    |           |           ----+----   ----+--
    |           |           SMB层解码   ... ...
    |           |           ----+----   ----+--
    |           |               |           |
    +-----------+--------+------+-----------+
                         |
                    -----+----------
                    DCE/MS RPC层解码
                    -----+----------
                         |
               ----------+--------------
               RPC层各命令相关的首部解码
               ----------+--------------
                         |
+--------+--------+-----+-+------------+---------+--------+
|        |        |       |            |         |        |
-+--    --+--   ---+--- ---+----    ----+---    --+--   ---+---
Bind    Fault   Request Response    Bind_ack    AUTH3   ... ...
----    -----   ---+--- ---+----    --------    -----   -------
                   |       |
                   +-----+-+
                         |
               +-------+-+-----+-------+
               |       |       |       |
            ---+--- ---+--- ---+--- ---+---
            Opnum 0 Opnum 1 ... ... Opnum N
            ---+--- ---+--- ---+--- ---+---
               |       |       |       |
               +-------+---+---+-------+
                           |
                      -----+-------
                      stub data解码
                      -------------

在用Ethereal研究DCE/MS RPC协议时，经常看到所谓的stub data，这实际是RPC解码
关键所在。对于这些stub data的解码是IDL文件相关的，不同的IDL文件对应不同的
stub data解码。不同的RPC服务都有着各自不同的IDL文件，因此对stub data的解码
只能是具体问题具体分析，没有捷径可走。

☆ BIND操作简介

1) "BIND Over TCP"简介

一个最简单、常见的Bind_ack报文的例子如下(SMB_37_0.cap):

--------------------------------------------------------------------------
Transmission Control Protocol, Src Port: 4166 (4166), Dst Port: 135 (135), Len: 72
DCE RPC Bind, Fragment: Single, FragLen: 72, Call: 1
    Version: 5
    Version (minor): 0
    Packet type: Bind (11)
    Packet Flags: 0x03
        0... .... = Object: Not set
        .0.. .... = Maybe: Not set
        ..0. .... = Did Not Execute: Not set
        ...0 .... = Multiplex: Not set
        .... 0... = Reserved: Not set
        .... .0.. = Cancel Pending: Not set
        .... ..1. = Last Frag: Set
        .... ...1 = First Frag: Set
    Data Representation: 10000000
        Byte order: Little-endian (1)
        Character: ASCII (0)
        Floating-point: IEEE (0)
    Frag Length: 72
    Auth Length: 0
    Call ID: 1
    Max Xmit Frag: 5840
    Max Recv Frag: 5840
    Assoc Group: 0x00000000
    Num Ctx Items: 1
    Context ID: 0
        Num Trans Items: 1
        Interface UUID: e1af8308-5d1f-11c9-91a4-08002b14a0fa
            Interface Ver: 3
            Interface Ver Minor: 0
            Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860
            Syntax ver: 2

0030                    05 00 0b 03 10 00 00 00 48 00         ........H.
0040  00 00 01 00 00 00 d0 16 d0 16 00 00 00 00 01 00   ................
0050  00 00 00 00 01 00 08 83 af e1 1f 5d c9 11 91 a4   ...........]....
0060  08 00 2b 14 a0 fa 03 00 00 00 04 5d 88 8a eb 1c   ..+........]....
0070  c9 11 9f e8 08 00 2b 10 48 60 02 00 00 00         ......+.H`....

Transmission Control Protocol, Src Port: 135 (135), Dst Port: 4166 (4166), Len: 60
DCE RPC Bind_ack, Fragment: Single, FragLen: 60, Call: 1
    Version: 5
    Version (minor): 0
    Packet type: Bind_ack (12)
    Packet Flags: 0x03
        0... .... = Object: Not set
        .0.. .... = Maybe: Not set
        ..0. .... = Did Not Execute: Not set
        ...0 .... = Multiplex: Not set
        .... 0... = Reserved: Not set
        .... .0.. = Cancel Pending: Not set
        .... ..1. = Last Frag: Set
        .... ...1 = First Frag: Set
    Data Representation: 10000000
        Byte order: Little-endian (1)
        Character: ASCII (0)
        Floating-point: IEEE (0)
    Frag Length: 60
    Auth Length: 0
    Call ID: 1
    Max Xmit Frag: 5840
    Max Recv Frag: 5840
    Assoc Group: 0x00012bee
    Scndry Addr len: 4
    Scndry Addr: 135
    Num results: 1
    Ack result: Acceptance (0)
    Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860
    Syntax ver: 2

0030                    05 00 0c 03 10 00 00 00 3c 00         ........<.
0040  00 00 01 00 00 00 d0 16 d0 16 ee 2b 01 00 04 00   ...........+....
0050  31 33 35 00 00 00 01 00 00 00 00 00 00 00 04 5d   135............]
0060  88 8a eb 1c c9 11 9f e8 08 00 2b 10 48 60 02 00   ..........+.H`..
0070  00 00                                             ..
--------------------------------------------------------------------------

试图绑定DCE/MS RPC Endpoint Mapper Interface UUID时引发上述报文。

Auth Length一般情况下为0，但并非总为0。关于这个字段，参看MSDN中如下函数:

RpcServerRegisterAuthInfo
RpcBindingInqAuthClient
RpcBindingSetAuthInfo

Auth Length为0的情况下，Bind(11)报文的RPC层大小固定为72。

Bind_ack(12)报文的RPC层大小变动较大，一是受Auth Length的影响，二是受Scndry
Addr的影响，Scndry Addr后面的Num results要求对齐在四字节边界上。当Scndry
Addr对应字符串表示的端口号时，Scndry Addr len最大等于6，即"65535"所占字节
数，包括结尾的NUL字符。由于Num results四字节对齐的缘故，"65535"不会比"135"
多占任何字节，因此当Scndry Addr对应字符串表示的端口号时，Auth Length为0的
情况下，Bind_ack(12)报文的RPC层大小固定为60。这种情形很常见，ncacn_ip_tcp
协议序列对应的BIND操作多半是这种情形，换句话说，BIND Over TCP多半是这种情
形。但是，ncacn_np协议序列对应的BIND操作就不是这种情形。

收到Bind_ack(12)报文并不意味着BIND操作成功，要检查Ack result字段:

0   Acceptance
2   Provider rejection

应该还有其它值，但那不重要。解析Bind_ack报文时，务必判断Ack result字段是否
等于Acceptance(0)，此时意味着BIND操作成功。以前一直以为收到Bind_nak(13)报
文才意味着BIND操作失败，不想近日做实验时意外地发现结论错误。

一个解码陷阱源于Ack result在Scndry Addr之后。ncacn_ip_tcp协议序列下Ack
result在RPC层的偏移可以认为是固定的+0x024，ncacn_np协议序列下这个偏移就变
了。可移植的解决方案是无论哪种协议序列，先取Scndry Addr len，再考虑四字节
对齐的事，动态计算Ack result的偏移。这个方案不受Auth Length的影响，认证相
关的数据位于尾部。另一个方案是先获取Auth Length，并确保收到的是完整的非畸
型的Bind_ack报文，然后从尾部倒推偏移-Auth Length-0x018。这个方案并不比前一
个方案更有优势，看个人喜好了。为此修正了一批早期编写的代码。

下面是一个Provider rejection(2)的例子(SMB_37_1.cap):

--------------------------------------------------------------------------
Transmission Control Protocol, Src Port: 60367 (60367), Dst Port: 135 (135), Len: 72
DCE RPC Bind, Fragment: Single, FragLen: 72, Call: 1
    Version: 5
    Version (minor): 0
    Packet type: Bind (11)
    Packet Flags: 0x03
        0... .... = Object: Not set
        .0.. .... = Maybe: Not set
        ..0. .... = Did Not Execute: Not set
        ...0 .... = Multiplex: Not set
        .... 0... = Reserved: Not set
        .... .0.. = Cancel Pending: Not set
        .... ..1. = Last Frag: Set
        .... ...1 = First Frag: Set
    Data Representation: 10000000
        Byte order: Little-endian (1)
        Character: ASCII (0)
        Floating-point: IEEE (0)
    Frag Length: 72
    Auth Length: 0
    Call ID: 1
    Max Xmit Frag: 4280
    Max Recv Frag: 4280
    Assoc Group: 0x00000000
    Num Ctx Items: 1
    Context ID: 0
        Num Trans Items: 1
        Interface UUID: ffffffff-ffff-ffff-ffff-ffffffffffff
            Interface Ver: 0
            Interface Ver Minor: 0
            Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860
            Syntax ver: 2

0040        05 00 0b 03 10 00 00 00 48 00 00 00 01 00     ........H.....
0050  00 00 b8 10 b8 10 00 00 00 00 01 00 00 00 00 00   ................
0060  01 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff   ................
0070  ff ff 00 00 00 00 04 5d 88 8a eb 1c c9 11 9f e8   .......]........
0080  08 00 2b 10 48 60 02 00 00 00                     ..+.H`....

Transmission Control Protocol, Src Port: 135 (135), Dst Port: 60367 (60367), Len: 60
DCE RPC Bind_ack, Fragment: Single, FragLen: 60, Call: 1
    Version: 5
    Version (minor): 0
    Packet type: Bind_ack (12)
    Packet Flags: 0x03
        0... .... = Object: Not set
        .0.. .... = Maybe: Not set
        ..0. .... = Did Not Execute: Not set
        ...0 .... = Multiplex: Not set
        .... 0... = Reserved: Not set
        .... .0.. = Cancel Pending: Not set
        .... ..1. = Last Frag: Set
        .... ...1 = First Frag: Set
    Data Representation: 10000000
        Byte order: Little-endian (1)
        Character: ASCII (0)
        Floating-point: IEEE (0)
    Frag Length: 60
    Auth Length: 0
    Call ID: 1
    Max Xmit Frag: 4280
    Max Recv Frag: 4280
    Assoc Group: 0x00012bf6
    Scndry Addr len: 4
    Scndry Addr: 135
    Num results: 1
    Ack result: Provider rejection (2)
    Ack reason: Abstract syntax not supported (1)
    Transfer Syntax: 00000000-0000-0000-0000-000000000000
    Syntax ver: 0

0040        05 00 0c 03 10 00 00 00 3c 00 00 00 01 00     ........<.....
0050  00 00 b8 10 b8 10 f6 2b 01 00 04 00 31 33 35 00   .......+....135.
0060  00 00 01 00 00 00 02 00 01 00 00 00 00 00 00 00   ................
0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00         ..............
--------------------------------------------------------------------------

此次Ack result等于Provider rejection(2)时，Ack reason字段开始有意义，另一
明显变化是Transfer Syntax字段。

Bind_ack(12)报文的RPC层大小与协议序列有关，但与Ack result、Ack reason字段
无关，这是两个短整型，始终占去4字节。因此上述Bind_ack(12)报文的RPC层大小仍
等于60。

向135/TCP发送Bind报文试图绑定不存在的接口UUID，就引发出如上Bind_ack报文。
这是一次实验意外出错后的结果，现实环境中这样的报文相当罕见，折腾DCE/MS RPC
这么久，还是第一次看到，为此修正了一批早期编写的代码。

2) "BIND Over Transaction"简介

当Bind(11)由SMB命令Trans(0x25)承载时，即"BIND Over Transaction"。

这是枚举Windows 2000共享时抓取的报文(SMB_37_2.cap):

--------------------------------------------------------------------------
Transmission Control Protocol, Src Port: 52635 (52635), Dst Port: 139 (139), Len: 160
NetBIOS Session Service
    Message Type: Session message
    Flags: 0x00
        .... ...0 = Add 0 to length
    Length: 156
SMB (Server Message Block Protocol)
    SMB Header
        Server Component: SMB
        Response in: 2
        SMB Command: Trans (0x25)
        NT Status: STATUS_SUCCESS (0x00000000)
        Flags: 0x08
            0... .... = Request/Response: Message is a request to the server
            .0.. .... = Notify: Notify client only on open
            ..0. .... = Oplocks: OpLock not requested/granted
            ...0 .... = Canonicalized Pathnames: Pathnames are