深度分析TCP会话劫持

　作为一种会话劫持的方法，黑客如果对一些并不可靠的协议进行劫持，那么将会轻而易举的视线，但是TCP协议是一种被称为可靠的传输协议，许多传输功能也都是基于TCP协议进行的，所以TCP会话劫持将作为本章讨论的对象。

　　TCP会话劫持

　　根据TCP/IP中的规定，使用TCP协议进行通讯需要提供两段序列号，TCP协议使用这两段序列号确保连接同步以及安全通讯，系统的TCP/IP协议栈依据时间或线性的产生这些值。在通讯过程中，双方的序列号是相互依赖的，这也就是为什么称TCP协议是可靠的传输协议(具体可参见RFC 793)。如果攻击者在这个时候进行会话劫持，结果肯定是失败，因为会话双方“不认识”攻击者，攻击者不能提供合法的序列号;所以，会话劫持的关键是预测正确的序列号，攻击者可以采取嗅探技术获得这些信息

　　TCP协议的序列号

　　现在来讨论一下有关TCP协议的序列号的相关问题。在每一个数据包中，都有两段序列号，它们分别为：

　　SEQ：当前数据包中的第一个字节的序号

　　ACK：期望收到对方数据包中第一个字节的序号

　　假设双方现在需要进行一次连接：

　　S_SEQ：将要发送的下一个字节的序号

　　S_ACK：将要接收的下一个字节的序号

　　S_WIND：接收窗口

　　//以上为服务器(Server)

　　C_SEQ：将要发送的下一个字节的序号

　　C_ACK：将要接收的下一个字节的序号

　　C_WIND：接收窗口

　　//以上为客户端(Client)

　　它们之间必须符合下面的逻辑关系，否则该数据包会被丢弃，并且返回一个ACK包(包含期望的序列号)。

　　C_ACK <= C_SEQ <= C_ACK + C_WIND

　　S_ACK <= S_SEQ <= S_ACK + S_WIND

　　如果不符合上边的逻辑关系，就会引申出一个“致命弱点”，具体请接着往下看。

　　致命弱点

　　这个致命的弱点就是ACK风暴(Storm)。当会话双方接收到一个不期望的数据包后，就会用自己期望的序列号返回ACK包;而在另一端，这个数据包也不是所期望的，就会再次以自己期望的序列号返回ACK包……于是，就这样来回往返，形成了恶性循环，最终导致ACK风暴。比较好的解决办法是先进行ARP欺骗，使双方的数据包“正常”的发送到攻击者这里，然后设置包转发，最后就可以进行会话劫持了，而且不必担心会有ACK风暴出现。当然，并不是所有系统都会出现ACK风暴。比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。注意，ACK风暴仅存在于注射式会话劫持。

　　TCP会话劫持过程

　　假设现在主机A和主机B进行一次TCP会话，C为攻击者，劫持过程如下：

　　A向B发送一个数据包

　　SEQ (hex): X ACK (hex): Y

　　FL

　　AGS: -AP--- Window: ZZZZ，包大小为:60

　　B回应A一个数据包

　　SEQ (hex): Y ACK (hex): X+60

　　FLAGS: -AP--- Window: ZZZZ，包大小为:50

　　A向B回应一个数据包

　　SEQ (hex): X+60 ACK (hex): Y+50

　　FLAGS: -AP--- Window: ZZZZ，包大小为:40

　　B向A回应一个数据包

　　SEQ (hex): Y+50 ACK (hex): X+100

　　FLAGS: -AP--- Window: ZZZZ，包大小为:30

　　攻击者C冒充主机A给主机B发送一个数据包

　　SEQ (hex): X+100 ACK (hex): Y+80

　　FLAGS: -AP--- Window: ZZZZ，包大小为:20

　　B向A回应一个数据包

　　SEQ (hex): Y+80 ACK (hex): X+120

　　FLAGS: -AP--- Window: ZZZZ，包大小为:10

　　现在，主机B执行了攻击者C冒充主机A发送过来的命令，并且返回给主机A一个数据包;但是，主机A并不能识别主机B发送过来的数据包，所以主机A会以期望的序列号返回给主机B一个数据包，随即形成ACK风暴。如果成功的解决了ACK风暴(例如ARP欺骗)，就可以成功进行会TCP话劫持了。