TCP Split Handshake Attack

TCP Split Handshake Attack，翻译过来为TCP分离握手攻击，虽然有“分离”两字，但这并不是指“TCP四次挥手”过程，而仍然是指在TCP三次握手过程中的漏洞攻击。

我们知道，根据RFC 793中的描述，TCP三次握手过程可以描述为：

如果在第二步中，Server将SYN-ACK分离成两个数据包发送，那么TCP三次握手过程可以描述为四步：

值得注意的是，上面这个4步握手过程是合理的，在RFC 793 3.3对这种情况有描述。在上图中的第二个包和第三个包之间（Split）的这段时间内，TCP session未建立，链接处于无状态（stateless）但又属于合理情况的状态，但问题在于目前绝大多数防护系统对这种stateless状态未进行强制安全控制，从而导致攻击者有机可乘，攻击者利用ACK、SYN负载合理数据躲过防护系统进入到安全网内。比如经典的做法是从恶意服务器传送一个恶意脚本到客户端进行ActiveX Buffer Overflow攻击等。
TCP Split Handshake Attack最近在网上炒得比较火，原因在于前几天（4月17号，PS：这篇文章是我在2011年4月份写的），NSS实验室对业界各大安全设备进行测试时发现，被测试的安全设备（包括cisco、juniper、Sonicwall）在默认情况下都无法防护该攻击。事实上，在一年以前类似的攻击已经被报道，只是未被引起重视。

http://nmap.org/misc/split-handshake.pdf里的TCP Split Handshake Attack与上面的介绍略有不同，在那里，恶意服务器利用TCP Split Handshake Attack来反转客户端/服务器两者角色，从而来试图逃避安全设备的检测。

RFC 793 3.4描述了一种TCP链接同时打开（Simultaneous-Open）的情况，如下图：

当然，在实际网络中，这种情况几乎不可能遇到，因为它不但要求几乎相同的双方TCP链接发起时间，还要求对等的端口号。
但是恶意服务器可利用这种方式来进行TCP Split Handshake Attack，恶意服务器同样是分离ACK和SYN，但是值得注意的是，它会修改发回客户端的SYN包内ACK为0，同时选用新的seq，如下图中的第三步，这样看上去，服务器反转了角色变成了发起TCP链接的“客户端”，而第四步中客户端返回SYN/ACK，变成了响应TCP链接的“服务器端”：

上图中第二步ACK回包是可选的，所以五步流程可变成四步。对比下图可以发现，TCP Split Handshake Attack流程和Simultaneous-Open流程类似，属于合法但又很容易被利用的链接建立情况。

这种客户端/服务器角色的反转，可以使得外网流入内网的数据有可能逃避基于内容的安全系统（比如IPS、AV）的检测，因为这些安全系统大多基于策略来进行安全检测，如果不恰当的策略配置就有可能招致TCP Split Handshake Attack威胁。

TCP Split Handshake Attack的局限性在于两点：第一，只有特定的外部流量（比如恶意服务器）逃避安全防护系统。第二，需要安全网内用户先发起请求，即外部攻击者无法主动进行攻击。
TCP Split Handshake Attack的解决方案：第一，更严格的检测，比如Juniper提供的” set security flow tcp-session strict-syn-check” ，Sonicwall提供的“Enforce Strict TCP Compliance”，对TCP链接建立过程中的SYN进行检测等。第二，安全策略对数据流方向上的兼容性。

完全参考资料：
http://paulsparrows.wordpress.com/2011/04/17/tcp-split-handshake-attack-explained/
http://watchguardsecuritycenter.com/2011/04/15/what-is-the-tcp-split-handshake-attack-and-does-it-affect-me/

转载请保留地址：http://www.lenky.info/archives/2012/09/1921 或 http://lenky.info/?p=1921