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 not canonicalized .... 1... = Case Sensitivity: Path names are caseless .... ..0. = Receive Buffer Posted: Receive buffer has not been posted .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported Flags2: 0xc001 1... .... .... .... = Unicode Strings: Strings are Unicode .1.. .... .... .... = Error Code Type: Error codes are NT error codes ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs .... 0... .... .... = Extended Security Negotiation: Extended security negotiation is not supported .... .... .0.. .... = Long Names Used: Path names in request are not long file names .... .... .... .0.. = Security Signatures: Security signatures are not supported .... .... .... ..0. = Extended Attributes: Extended attributes are not supported .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response Process ID High: 0 Signature: 0000000000000000 Reserved: 0000 Tree ID: 2048 Process ID: 23643 User ID: 2048 Multiplex ID: 63744 Trans Request (0x25) Word Count (WCT): 16 Total Parameter Count: 0 Total Data Count: 72 Max Parameter Count: 0 Max Data Count: 1024 Max Setup Count: 0 Reserved: 00 Flags: 0x0000 .... .... .... ..0. = One Way Transaction: Two way transaction .... .... .... ...0 = Disconnect TID: Do NOT disconnect TID Timeout: Return immediately (0) Reserved: 0000 Parameter Count: 0 Parameter Offset: 84 Data Count: 72 Data Offset: 84 Setup Count: 2 Reserved: 00 Byte Count (BCC): 89 Transaction Name: \PIPE\ Padding: 0000 SMB Pipe Protocol Function: TransactNmPipe (0x0026) FID: 0x4000 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: 4b324fc8-1670-01d3-1278-5a47bf6ee188 Interface Ver: 3 Interface Ver Minor: 0 Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860 Syntax ver: 2 0040 00 00 00 9c ff 53 4d 42 25 00 00 00 00 08 .....SMB%..... 0050 01 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 08 ................ 0060 5b 5c 00 08 00 f9 10 00 00 48 00 00 00 00 04 00 [\.......H...... 0070 00 00 00 00 00 00 00 00 00 00 00 54 00 48 00 54 ...........T.H.T 0080 00 02 00 26 00 00 40 59 00 00 5c 00 50 00 49 00 ...&..@Y..\.P.I. 0090 50 00 45 00 5c 00 00 00 00 00 05 00 0b 03 10 00 P.E.\........... 00a0 00 00 48 00 00 00 01 00 00 00 b8 10 b8 10 00 00 ..H............. 00b0 00 00 01 00 00 00 00 00 01 00 c8 4f 32 4b 70 16 ...........O2Kp. 00c0 d3 01 12 78 5a 47 bf 6e e1 88 03 00 00 00 04 5d ...xZG.n.......] 00d0 88 8a eb 1c c9 11 9f e8 08 00 2b 10 48 60 02 00 ..........+.H`.. 00e0 00 00 .. -------------------------------------------------------------------------- SMB Command字段表明此次RPC通信由Transaction承载。RPC层的Bind(11)报文仍占72 字节。本例与"BIND Over Tcp"的情形相比，一是RPC层的承载者由TCP变成了SMB，二 是接口UUID变了，除此之外，并无区别。微软很好地实现了协议分层处理。 Bind(11)报文对于DCE/MS RPC协议分析来讲，至关重要，直接体现在暴露了接口UUID。 在Google中搜索"4b324fc8-1670-01d3-1278-5a47bf6ee188"，重点推荐: Well-known DCE RPC named pipes endpoints http://www.hsc.fr/ressources/articles/win_net_srv/ch04s05s03.html 这里有一张表"Named pipes used by DCE RPC servers"，列举了部分接口UUID对应 的服务或进程，协议分析爱好者可以参看。 接口UUID即上述显示中的Interface UUID字段，不要与Transfer Syntax字段混淆了。 分析DCE/MS RPC通信时，没有接口UUID寸步难行。后续的Request(0)报文中的Opnum 是接口UUID相关的，A接口的0号调用与B接口的0号调用显然是两个独立的调用。有时 会碰上求助者提供了CAP文件，居然只有Request(0)报文，没有Bind(11)报文，分析 者将很难进行有效分析。 那么怎么针对接口UUID设置过滤规则呢？先要搞清楚层次关系，我们可能碰上不同的 承载，就目前举例来讲，已经出现了TCP、SMB两种。 "BIND Over Tcp"对应协议序列ncacn_ip_tcp，目标端口理论上可以是任意TCP端口。 在设置端口过滤时，只能是具体问题具体分析，后面会单独讲这个问题。抛开端口不 谈，Interface UUID字段在TCP数据区(注意我的用词)的偏移是固定的+0x020，由于 UUID大小固定，后面版本字段在TCP数据区的偏移也是固定的。真正设置过滤规则时， 还可以对Version、Packet type、Transfer Syntax字段进行过滤，减少误报。 前面提到了"在TCP数据区的偏移"，意味着我假设手头的工具可以正确定位TCP数据区， 即剥掉IP首部、TCP首部之后的TCP数据区。你不能简单地从IP首部+40，要考虑可能 出现的IP选项、TCP选项。从协议分层的理念来讲，定位在TCP数据区的偏移也是合理 的。 "BIND Over Transaction"对应协议序列ncacn_np，目标端口理论上只有两个，139与 445/TCP，很容易设置端口过滤。一般必须同时观察这两个端口上的通信过程。A时刻 抓取的报文可能用了139/TCP，B时刻抓取的报文可能用了445/TCP。这不是RPC层的问 题，而是SMB层的问题。SMB层的实现最早只用到139/TCP，后来增加了445/TCP，微软 保持向后兼容性，宏观上139与445是竞争关系。抛开端口不谈，Interface UUID字段 在RPC层(注意我的用词)的偏移是固定的+0x020，由于UUID大小固定，后面版本字段 在RPC层的偏移也是固定的。真正设置过滤规则时，还可以对Version、Packet type、 Transfer Syntax字段进行过滤，减少误报。 前面提到了"在RPC层的偏移"，意味着我假设手头的工具可以正确定位RPC层。剥掉IP 首部、TCP首部可能好理解也好操作，大家都熟了，剥掉SMB层可能不太熟。看前面显 示的Data Offset字段，字段值加上4即RPC层在TCP数据区的偏移，SMB层就这样简单 地被剥掉了。别高兴得太早，Data Offset字段本身在TCP数据区的偏移是随SMB命令 而改变的，就Trans(0x25)而言，偏移是61。有人要问了，我先过滤出Trans(0x25)， 再直接假设RPC层在TCP数据区的偏移是+0x058，不就得了。嘿，这是有问题的。注意 看上面显示中的Padding字段，该字段的长度与值不固定！可能你抓了1000次包，都 没看到Padding字段的长度有变化，但第1001次你敢保证仍不变吗？事实上我最初写 代码时就是这样假设的，结果后来针对不同OS测试时意外出错，调试了半天才得到现 在的结论。 写程序时可以精确过滤并定位各个偏移，用协议分析工具时就得变通一下了。先过滤 先过滤出Trans(0x25)，再直接假设RPC层在TCP数据区的偏移是+0x058，进而针对RPC 层各字段进行过滤。因为Padding字段长度有变毕竟是极少数事件，万一哪天你细心 地碰上了，可以针对性地增加另一类过滤，然后逻辑或一下。 下面是前述Bind(11)报文的响应报文: -------------------------------------------------------------------------- Transmission Control Protocol, Src Port: 139 (139), Dst Port: 52635 (52635), Len: 128 NetBIOS Session Service Message Type: Session message Flags: 0x00 .... ...0 = Add 0 to length Length: 124 SMB (Server Message Block Protocol) SMB Header Server Component: SMB Response to: 1 Time from request: 0.000545000 seconds SMB Command: Trans (0x25) NT Status: STATUS_SUCCESS (0x00000000) Flags: 0x88 1... .... = Request/Response: Message is a response to the client/redirector .0.. .... = Notify: Notify client only on open ..0. .... = Oplocks: OpLock not requested/granted ...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized .... 1... = Case Sensitivity: Path names are caseless .... ..0. = Receive Buffer Posted: Receive buffer has not been posted .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported Flags2: 0xc001 1... .... .... .... = Unicode Strings: Strings are Unicode .1.. .... .... .... = Error Code Type: Error codes are NT error codes ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs .... 0... .... .... = Extended Security Negotiation: Extended security negotiation is not supported .... .... .0.. .... = Long Names Used: Path names in request are not long file names .... .... .... .0.. = Security Signatures: Security signatures are not supported .... .... .... ..0. = Extended Attributes: Extended attributes are not supported .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response Process ID High: 0 Signature: 0000000000000000 Reserved: 0000 Tree ID: 2048 Process ID: 23643 User ID: 2048 Multiplex ID: 63744 Trans Response (0x25) Word Count (WCT): 10 Total Parameter Count: 0 Total Data Count: 68 Reserved: 0000 Parameter Count: 0 Parameter Offset: 56 Parameter Displacement: 0 Data Count: 68 Data Offset: 56 Data Displacement: 0 Setup Count: 0 Reserved: 00 Byte Count (BCC): 69 Padding: 00 SMB Pipe Protocol Function: TransactNmPipe (0x0026) FID: 0x4000 DCE RPC Bind_ack, Fragment: Single, FragLen: 68, 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: 68 Auth Length: 0 Call ID: 1 Max Xmit Frag: 4280 Max Recv Frag: 4280 Assoc Group: 0x00011135 Scndry Addr len: 13 Scndry Addr: \PIPE\ntsvcs Num results: 1 Ack result: Acceptance (0) Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860 Syntax ver: 2 0040 00 00 00 7c ff 53 4d 42 25 00 00 00 00 88 ...|.SMB%..... 0050 01 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 08 ................ 0060 5b 5c 00 08 00 f9 0a 00 00 44 00 00 00 00 00 38 [\.......D.....8 0070 00 00 00 44 00 38 00 00 00 00 00 45 00 00 05 00 ...D.8.....E.... 0080 0c 03 10 00 00 00 44 00 00 00 01 00 00 00 b8 10 ......D......... 0090 b8 10 35 11 01 00 0d 00 5c 50 49 50 45 5c 6e 74 ..5.....\PIPE\nt 00a0 73 76 63 73 00 00 01 00 00 00 00 00 00 00 04 5d svcs...........] 00b0 88 8a eb 1c c9 11 9f e8 08 00 2b 10 48 60 02 00 ..........+.H`.. 00c0 00 00 .. -------------------------------------------------------------------------- 协议序列为ncacn_np时，Scndry Addr len、Scndry Addr字段明显有变，以至RPC层 大小不再是60，但你也不能说它固定是68，显然因Scndry Addr的内容而变。要小心 获取Ack result字段在RPC层的偏移。 分析响应报文时同样需要正确定位RPC层。这次Data Offset字段本身在TCP数据区的 偏移是51(不再是61)，该字段的值加4后即RPC层在TCP数据区的偏移。 用协议分析工具时可以先过滤出Trans(0x25)，再直接假设RPC层在TCP数据区的偏移 是+0x03C，进而针对RPC层各字段进行过滤。 SMB_37_3.cap的显示就不文本化了，与SMB_37_1.cap类似。发送Bind报文试图绑定不 存在的接口UUID，引发Provider rejection(2)报文。区别在于承载者由TCP变成SMB， 其它分析不变。这个包不可能在身边的环境中抓到，我用程序发出来的，提供在此仅 用于研究，大家自己打开了看。