Last Updated on October 1, 2018
Update May 12: TCP Split Handshake: Why Cisco ASA is not susceptible
Update May 11: The Never Ending Story
Update April 21: Other Considerations on TCP Split Handshake
Few days ago, independent security research and testing NSS Labs, issued a comparative report among six network security technologies. The controversial results created a comprehensible turmoil among the security vendors involved in the tests, and more in general inside the infosec landscape. As a matter of fact it turned out that that five of the six tested platforms were susceptible to TCP Split handshake attack.
As a security professional, I am pretty much involved with at least five of the six tested technologies, consequently, although I never heard about TCP Split Handshake before, I must confess I was really curious to learn which was the only platform capable of surviving the test (the answer is indirectly provided by the vendor – Checkpoint – missing from the list contained on the remediation report subsequently released). Fortunately the scientific side of me took over and instead of making judgments and drawing conclusions about the results, I decided to learn more about TCP Split Handshake and the reasons why a security equipment may be vulnerable.
TCP Split Handshake in RFC 793
Since TCP is a connection-oriented protocol, every connection begins with a “handshake” defined in RFC 793. The handshake defines three well defined steps and for this reason it is called “TCP Three Way Handshake.”
The host initiating the connection, referred as the client, send to its peer, referred as the server, a synchronization packet, or SYN. In order to correctly identify the beginning (and the subsequent “state” of the session, the SYN packet contains an initial Sequence Number (ISN) which corresponds to a pseudo-random number.
Upon reception of the SYN packet, the server acknowledges that, and generates its own SYN. This “SYN/ACK” packet contains both the server’s Initial Sequence Number, as well as an acknowledgment number equal to the client’s Sequence Number plus 1. The fact that the server sends a single packet to initiate the connection on its side and to acknowledge the initial SYN sent from the client is known as piggy-backing and, as explained later, is the fundamental aspect in which TCP Split Handshake differs from Three Way Handshake.
At this point, in order to establish the session, the client concludes the Three Way Handshake and acknowledges the server’s SYN/ACK, sending a packet with its own ISN incremented by one, as well as its acknowledgement number equal to the server’s ISN plus 1.
As mentioned above, in the second phase of the handshake, the piggy-backing allows the server to use a single packet to send its own SYN and to acknowledge the SYN packet received from the client (ACK). However, let us assume that the server could decide to split the second phase of the handshake and send a dedicated ACK packet to acknowledge the client SYN, and a further dedicated packet with its own SYN. This is exactly what is stated at section 3.3, page 27, of RFC 793, which introduces an intriguing four-step process:
1) A --> B SYN my sequence number is X 2) A <-- B ACK your sequence number is X 3) A <-- B SYN my sequence number is Y 4) A --> B ACK your sequence number is Y
As a consequence, one might expect that an RFC 793 perfectly compliant client be capable to silently accept packet two, explicitly ACK packet 3, and hence complete the handshake more-or-less normally. At least in theory…
In reality, in such similar circumstances, NSS test have shown that some network security devices, with the sole firewall function enabled, get confused and behaves in a stateless manner. In few words, if even the client behaves as stated in the RFC, that is it is able to correctly establish the session even if it accepts separated ACK and SYN packets from the server, the network security device, on receiving the SYN from the server (packet 2), loses the awareness of the session and lets the traffic flow without enforcing any security control as if it belongs to an uncontrolled session (in theory an unknown or out-of-state session should be blocked). This means that a malicious payload conveyed through a TCP Split Handshake intiated session could go through the firewall and as a consequence, an attack scenario is quite straightforward: an attacker could think to use a server-side malicious script to establish the session by mean of a TCP Split Handshake and consequently install an executable on the client (a very fashionable event in the last days), for instance, by mean of an ActiveX Buffer Overflow on the target client browser.
The bad news is that this kind of attack is not new, and a similar attack scenario was reported for the first time approximately one year ago (with different behaviours reported for clients and security devices). The strange side of the story relies on the fact that this behaviour may not be considered a real vulnerability, but rather an occurrence covered by RFC not correctly implemented or not enabled on the default configuration by security vendors (please consider that RFC 793 also includes a further method for establishing a TCP connection dubbed “TCP Simultaneous Open” in which two TCP hosts simultaneously attempt to open a connection to each other via a SYN packet).
Last but not least…
For the record, as previously stated, NSS Labs released a remediation report containing the indications needed to mitigate (where necessary) the occurrence of the TCP Split Handshake for the affected technologies. Moreover two vendors (Cisco and Fortinet) added some indications as reported in the following:
- According to an official blog post, Cisco was not able to reproduce the issue occurred in NSS Labs Test and is further investigating the TCP Split Handshake attack on its devices.
- According to an official response in a blog post, Fortinet is not susceptible to TCP Split Handshake attack if IPS and Antivirus protections are enabled. A special IPS signature has been developed and a firmware update is scheduled for May in order to block TCP Split Handshake attack with only firewall enabled:
- For Juniper devices the line “set security flow tcp-session strict-syn-check” must be inserted into configuration (this option affects all the traffic, so it must be set with caution);
- Palo Alto is working to release an official fix between mid-April and early May;
- For Sonicwall devices, the option “Enforce Strict TCP Compliance” must be enabled (also in this case this option affects all the traffic and must be set with caution).
Related Articles
- Other Considerations On TCP Split Handshake (paulsparrows.wordpress.com)
Pingback: Looking Back… « Il Blog di Paolo Passeri
Nice work. It can be easily understood! Thank you for your works.
Pingback: TCP Split Handshake: Why Cisco ASA Is Not Susceptible « Il Blog di Paolo Passeri
Pingback: TCP Split Handshake: The (Never)ending Story… « Il Blog di Paolo Passeri
Very nice analysis Paolo, I’ve quoted you in my blog post.
Anyway I think that one of the lessons we, as security professionals, need to understand is that maybe the entire process of firewall testing should be re-thinked. As Breaking Point says in it’s article commenting the report, in a more real-life situation.
I’ve seen too many marketing press releases in the past months, and this is not good for the infosec industry.
If I understand this correctly, the attacker wanting to exploit this technique must first gain access to the server, to set up a malicious script there that will perform a split handshake?
But well, if an attacker is able to gain access to your server and install own scripts intercepting TCP connections, then you already have a very bad situation. A security hole in the firewall doesn’t matter a lot in that case, because this means that the whole security of your server is compromised, and this should be your main concern rather than concentrating on some obscure security vulnerability in the firewall…
You are right, anyway, there are some points that must be kept into consideration.
First, in my opinion, the whole question has raised so much noise because it looks like some vendor apparently “forgot” to implement (or underevaluated, hiding behind non default configurations) an occurrence specifed in the RFC of TCP (even if I must confess that, between the professionals I disccused with, no one was aware of 4-way hanshake).
Secondly, I would not be worried of an internal server rather than an external server, specifically “dressed up” to implement an RFC TCP Split Handshake attack. With a little more immagination (but not too much since it looks a plausible scenario), this must be analyzed having in mind the attack models used in the most meaningful infosec events of beginning 2011. In many cases attackers installed a RAT on the victim hosts and controlled them by mean of a C&C server, after acctracting the user to a malicious server. In a similar scenario, TCP Split Handshake could be used to exploit a vulnerability on the host machine for executing arbitrary code to install the RAT (after “checking in” the user on o a malicious server), in a completely transparent manner for the perimeter firewall, or also to control the victims in “stealth mode” (Provided the perimeter devices has only firewall enabled).
As far as the compromission of a server is concerned, I am not surprised anymore after LizaMoon and its consequent Mass SQL Injection infection which turned million of servers in (indirect) malware vectors…
Pingback: Other Considerations On TCP Split Handshake « Il Blog di Paolo Passeri
Most firewalls are vulnerable to this and other attacks because they wait for attackers to use a technique before they defend against it. Actually, this case is even more embarrassing for them, since there was a research paper published on this technique last year, so anyone still vulnerable today just isn’t keeping up with the field.
It’s a real pity that McAfee Firewall Enterprise (MFE) was not part of the test performed by NSS Labs as it would have shown how secure it is.
MFE also prevents this because it monitors TCP negotiation more precisely than most of other firewalls. Again, this is a great example of how McAfee Firewall blocks attacks before they are “discovered” because it is secure by design.
This is the so called “positive or proactive model” of security opposed to the “negative or reactive model”.