TCP – for Transmission Control Protocol – is the most used protocol on the Internet. It is the basis for almost all activity: surf, e-mail, file transfer, etc. TCP is also a complex and ancient protocol with many implementation variations, caveats, and lurking threats.
Recently, researchers T. Beardsley and J. Qian found a new method to establish a TCP connection32. They called it the TCP split handshake. This new method has interesting consequences for
The standard method to establish a TCP connection is described in IETF document RFC 79333. This is the classical three-way handshake. It establishes a channel from a client to a server [figure-1] using three messages. The standard also mentions another highly theoretical method called the simultaneous open. It uses four messages [figure-2], basically simultaneously opening two half-way connections.
Figure 1 – Three-way Handshake
Figure 2 – Simultaneous Open
T. Beardsley and J. Qian mixed both connection methods in order to create a working TCP channel. They called it the TCP split handshake. It can reverse the direction of connection from server to client, instead from client to server. Like the simultaneous open, it uses four messages. Unlike the simultaneous open, it does not require simultaneity of the handshake and the messages slightly differ. First, the client sends one SY N packet to the server. Then, the server starts a classic three-way handshake towards the client by using information gathered from the first SY N [figure-3]. The magic goes here: this should not work, but it does! (at least on the three most popular operating systems: Windows, Linux, and MacOS ).
Figure 3 – Split Handshake
Because the TCP split handshake significantly differs from the current usage, it has the potential to fool protection systems that do not handle this use case. In the scenario where a malicious server (e.g., a web server) is attacking clients (e.g., browsers) the TCP split handshake can provide a means to evade protection systems (e.g., Intrusion Prevention Systems). Regarding the structural reversion of the connection, it is even possible that some protection systems may be totally confused and may not check some packets, considering they do not go in the sense of an attack).
T. Beardsley and J. Qian tested several devices already. They sometimes obtained worrying results. At least one Intrusion Prevention System (IPS) did not block an attack under the TCP split handshake scenario, although it did routinely block the same attack under the standard scenario.
At first sight, Network Address Translation (NAT ) devices seem to better resist. But this is rather by chance. The tested devices did not fully implement the TCP specification, giving less success chance to the TCP split handshake. Other NAT devices may still experience problems.
It is sometimes believed that all TCP weaknesses are known, but this study unveils a totally new concept: reversing the TCP connection establishment! It is a quite deep paradigm change in the client-server model, and it is very difficult to forecast all the consequences, good or bad. Nevertheless, we may see soon some exploits using TCP split handshake appear. Our security law number 8 has never been so true: “when you’re connected to the Internet, the Internet is connected to you.”
P. AUFFRET, O. HEEN
During Q1 2011, NSS Labs performed the industry’s most rigorous test of leading firewall solutions and discovered a serious problem involving the way many firewalls handle TCP. In some cases, the issue lies with the fact that the default policy has protection from this type of spoofing attack disabled. In other cases, the product simply does not provide protection and a patch is being developed to address this issue.
This document chronicles the recommended fixes and remediation steps that enterprises should take to mitigate the effects of the TCP Split handshake attack for the following products:
- CISCO ASA 5585
- FORTINET FORTIGATE 3950
- JUNIPER SRX 5800
- PALO ALTO NETWORKS PA-4020
- SONICWALL E8500
There are numerous other firewalls that have not yet been tested by NSS Labs. Thus, it would be unwise to assume that only the firewalls mentioned in this advisory are affected.
849 total views, no views today