If you’ve followed security news over the past few days, you’ve probably seen a lot of hoopla about a TCP split-handshake vulnerability that can affect firewalls and other networking and security devices. Many of the Media’s articles characterize this complicated TCP connection attack as, “a hacker exploit that lets an attacker trick a firewall and get into an internal network as a trusted IP connection” or as a “hole” in firewalls. I’m not sure that these descriptions properly characterize this vulnerability, and I suspect many administrators may not really understand how this attack works (let alone what it does and doesn’t allow an attacker to accomplish). I hope to try and rectify that in this post.
Before I jump into a description of this attack, WatchGuard XTM owners probably want to know if they are vulnerable to this attack. The answers is, No. Our XTM appliances do not allow TCP split-handshake connections. Furthermore, we also enable a feature called TCP SYN checking by default on our devices, which further protects against TCP state-based attacks. Later in this post, I’ll go into more detail on how we tested this, but for now, know that our appliances are not susceptible to this attack. With that out of the way, let’s look at this attack.
What is the TCP Split-Handshake Attack?
To understand the TCP split-handshake attack you need to understand how network devices build TCP connections. I’m going to assume you are familiar with the TCP three-way handshake. If not, this guide will walk you through it. Most network administrator understand this three-way handshake technique quite well, and many gateway security devices (like stateful firewalls) are designed to enforce it. However, less people know about another legitimate way to build TCP connections, called the simultaneous-open handshake. With a simultaneous open connection, both a client and server send a SYN packet to each other at about the same time. Then both sides also send ACK packets to each other in response. This slightly different variant of the TCP handshake doesn’t happen much in the real world, however, it’s a perfectly legitimate way to start a TCP connection (according to RFC 793).
This brings us to the TCP split-handshake (also sometimes called a Sneak ACK attack). As the name suggests, the split-handshake combines aspects of the normal three-way handshake with the simultaneous-open handshake. Essentially, a client sends a SYN packet to a server, intending to complete a normal three-way handshake. However, rather than completing the client’s three-way handshake, a malicious server starts by replying as though it were doing a simultaneous-open connection, and then starts its own three-way handshake in the other direction — from server to client. So in essence, even though the client started the connection to the server, the logical direction of this connection gets reversed.
This is a fairly quick and high-level description of this attack. If you are a technically oriented person that wants to know the nitty-gritty details, I highly recommend you read, The TCP Split Handshake: Practical Effects on Modern Network Equipment. It is the defacto document describing this attack. If you just want the highlights, I also recommend this article. It characterizes the attack well, without diving too deep into the technical detail.
So What Can an Attacker Accomplish with this Attack?
OK. At a high-level, you now know that the TCP split-handshake attack is a sneaky way that a malicious server can reverse the logical direction of a connection that a client initiates. But what exactly does that mean? What can an attacker do with that, and how bad is it?
First, you should know that this attack cannot punch holes in your firewall, willy-nilly, without user interaction. A key mitigating factor to the attack is that a client within your network must first make a connection to a malicious server on the internet, before this attack can even start. Some of the descriptions of the attack, which claim an external attacker can trick a firewall into giving them access as a trusted IP, seem to leave this fact out. So if you were worried that external attackers can just hop through your firewall on their own, don’t be.
Furthermore, when this attack succeeds, the attacker isn’t even getting free reign on the victim computer or your network either, instead the attacker has only reversed the logical direction of your client’s initial connection. This could be bad, as I will explain in a second, but it is not immediate full access to the victim computer or your network.
What this attack really comes down to is an IPS (or other security content-filtering) evasion attack. The key issue is this attack logically reverses the direction of a perfectly legitimate connection your client initiated. This doesn’t really mean the attacker can do anything new on the victim computer, but it may confuse gateway security scanning services that protect your client. Many security systems, like IPS, antivirus (AV), and other content-filtering systems rely on the direction of traffic to decide how to scan it, or even if they will scan it. If an attacker can confuse the gateway devices as to the direction of traffic, it may be able to evade security scanning or IPS policies.
However, if the malicious web server adds the TCP split-handshake connection to the same attack, your IPS and AV systems may be confused by the direction of the traffic, and not scan the web server’s content. Now the malicious drive-by download would succeed, despite your gateway security protection.
So to summarize, the TCP split-handshake attack may help malicious servers to bypass security scanning services on your gateway security devices. However, it will not allow external attackers to bypass your firewall policies, and it requires an internal client start the connection in the first place.
Is My X-brand Network Device at Risk?
Now you know the true impact of TCP split-handshake attacks. They don’t allow attackers to totally bypass firewalls without user interaction, but they could help attackers evade your security services, assuming your clients connect to them. The next question is, are my network devices vulnerable?
To help you answer that question, I’m going to share how I tested WatchGuard’s XTM appliances.
The authors of the paper I mentioned earlier (The TCP Split Handshake: Practical Effects on Modern Network Equipment) included a special Ruby script in their paper called fakestack.rb. This script sets up a server on port 8080, that listens for incoming connections, and replies to those connection using the TCP split-handshake connection method. If this malicious connection succeeds, the script reports, “The handshake’s a LIE!” You can use this script to test your network equipment, and see whether or not it allows TCP split-handshake connections to complete.
I recommend you use fakestack.rb with a Linux computer. I used my Backtrack 4 installation. Fakestack.rb requires another ruby script called PacketFu, which in turn requires something called PcapRub. The whitepaper above explains these dependencies. Once your have all this installed, you simply have to disable your computer’s local host firewall (on 8080 at least), and run fakestack.rb (sudo fakestack.rb eth0 8080).
Once you have fakestack running, I recommend you first get a client to connect to it directly, without any firewall or gateway device in the mix. This way you can see what happens when the split-handshake connection succeeds. Open a web browser (IE or Firefox) on a Windows computer that is on the same network, and try to connect to the IP of the computer running fakestack, on port 8080 (http://x.x.x.x:8080). You will not see anything in the web browser. However, if you look at fakestack’s output, you will see it generating packets, sending certain replies, and if the attack works, it returns that “handshake’s a lie” message.
Once you have fakestack working, testing your own network gear is simple. Simply put the fakestack computer on the external side of your firewall, IPS, or security appliance, and get an internal client to try to connect to fakestack. If fakestack returns the handshake is a lie message, then you know your security gear may be vulnerable to this attack. However, if you don’t get the handshake is a lie message, fakestack wasn’t able to complete the split-handshake connection, and your device must be doing something to prevent it.
This is the test I did with our XTM appliances. When a client behind an XTM appliance tries to connect to fakestack, the connection never completes. Meanwhile, the XTM logs report:
|2011-04-15 19:18:37 Deny 192.168.39.204 192.168.39.38 63316/tcp 8080 63316 0-External Firebox tcp syn checking failed 40 31 (Internal Policy) proc_id=”firewall” rc=”101″ tcp_info=”offset 5 A 1845100933 win 64″|
|2011-04-15 19:18:37 Deny 192.168.39.204 192.168.39.38 63316/tcp 8080 63316 0-External Firebox Denied 44 31 (Unhandled External Packet-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 6 S 794513233 win 64″|
Our packet handling engine does not recognize split-handshake connections as legitimate connections. Furthermore, split-handshakes trigger our TCP syn checking feature too, which is enabled by default.
This test shows that WatchGuard devices don’t allow split-handshake connections. You can use the same test to figure out whether or not your other network security devices handle TCP split-handshake connections properly.
So in summary:
- The TCP split handshake attack is not an attack that allows attackers to punch holes in firewalls without user interaction. However, it is a significant vulnerability that could allow attackers to evade security services like IPS, assuming the attacker can entice the victim to a malicious server.
- WatchGuard XTM appliances are not vulnerable to the TCP split-handshake attack, since we do not allow split-handshake connections. We tested this using a script designed by the discovers of the attack, called fakestack.rb.
- If you want to know how your other network gear responds to TCP split-handshake connections, use fakestack.rb to test.
I hope this post helped clear up some potential misinterpretations about this complex vulnerability, and has shown you its true severity and impact. Feel free to share your thoughts and ideas about this flaw in the comments section. I find it quite interesting and would love to discuss it. — Corey Nachreiner, CISSP. (@SecAdept)
Mark Kneidel says
We have a Watchguard Firebox X Core E-Series (X550e) firewall. The article should address the vulnerabilities of all models Watchguard supports.
Is our model vulnerable to the attack?
Corey Nachreiner says
Any model running 11.x is not vulnerable, including e-Series. They all use the same packet filtering engine, and TCP syn checking. The model I specifically tested with fakestack.rb happened to be a 5-Series that is on my desk, which is why I specifically call out XTM appliances. However, all our hardware that runs the XTM 11.x firmware uses the same packet handling engine, so are not vulnerable either.
PS. I also suspect pre-11.x versions to be fine too, but haven’t found the time to test. Since 11.x is the most recent firmware on all supported hardware platforms, it’s what I’m most concerned with.
Adam Powers says
Excellent summary. Best I’ve seen on the split handshakes. Thanks Corey.
Corey Nachreiner says
Thanks… I hoped it would be useful. 🙂
This is true, but the ‘TCP SYN checking’ feature is usually disabled in my case because some customers reports problem with access to certain websites (syn checking failed). So if I disabled this feature in the firewall config, the firewall is vulnerable, right?
Corey Nachreiner says
Actually, no. We will prevent a TCP split-handshake connection from building even without the TCP SYN checking option checked. Our packet handling/filtering engine simply doesn’t allow a connection to build this way. Since I saw the “Syn checking” message clearly in the log, I know SYN checking triggered during my first test… so I tried it again without SYN checking… the connection was still unable to complete, and in that case only the “Unhandled external packet” log came up.
So you don’t really need our default SYN checking feature to block this. However, that feature can protect you from many other state-based attacks too. So I personally recommend it.
Reed Smith says
Great article Corey…nicely done.
Corey Nachreiner says
Very clean and concise explanation on the 3 ways of TCP Establishment with stress on Split Handshake
Sohail Akrim says
Thanks, it’s really informative and good article.
Chad Cowden says
I hope you will still look at this blog. We are using a XTM520 and are up to date on current Subscriptions from the UTM bundles. We have three different external interfaces and no matter what one we go out of, we get the same generic “page cannot be displayed error”. We just replaced an X5500e that worked just fine, it was on the 11.3.2 software…..and now we have the XTM520 with 11.4.2 and get the following errors:
2011-10-25 21:51:21 Deny 10.0.105.100 184.108.40.206 http/tcp 4915 80 1-Trusted 3-Springnet – 2 Denied 48 125 (Outgoing-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 7 S 1443943316 win 252″ src_user=”[email protected]” Traffic
2011-10-25 21:51:45 Deny 10.0.105.100 220.127.116.11 http/tcp 4921 80 1-Trusted 6-NuVox1 Denied 48 125 (Outgoing-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 7 S 4035285704 win 252″ src_user=”[email protected]” Traffic
2011-10-25 21:51:48 Deny 10.0.105.100 18.104.22.168 http/tcp 4923 80 1-Trusted 6-NuVox1 Denied 48 125 (Outgoing-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 7 S 3283900403 win 252″ src_user=”[email protected]” Traffic
2011-10-25 21:52:00 Deny 10.0.105.100 22.214.171.124 http/tcp 4925 80 1-Trusted 6-NuVox1 Denied 48 125 (Outgoing-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 7 S 1673658241 win 252″ src_user=”[email protected]” Traffic
Please advise on how to fix this issue, or what the issue is?
Corey Nachreiner says
Sorry, for the late reply, Chad. Since this was posted in an older post, I didn’t see it till now. I hope you figured out the issue. This really isn’t the medium for WatchGuard tech support, and I’m certainly not as skilled at figuring out issues as out actual support staff. Nonetheless, I did take a peak at the logs you posted. Unfortunately, they seem truncated in your past… I believe there is probably more text after the “Traffic” part of that log line… the remaining portion should help identify why the deny happened. In any case, I can see the “Outgoing” service is the denying policy, so it should just be a matter of looking at you rules for that service, and figuring out why trusted to “NuVox1, is not allowed by it. I assume NuVox1 is a name you gave an interface or VLAN?
Anyway, you best bet for figuring out these issues is to either submit a support request to our support page, call support, or try the support forms…
Rob G says
Nice article Cory. I realize this is an older post so I hope this still gets to you. I recently setup a new XTM series 3 firewall. I had to disable the syn check feature in order to get the firebox to stop dropping SMTP traffic. Once I disable that feature SMTP traffic passed just fine. Do you know why this enabled feature would block all SMTP traffic? Thank you much…
Corey Nachreiner says
Off hand, no. I’m not sure why syn checking would prevent your email server from receive/sending SMTP traffic. Our syn checking mechanism follows pretty normal RFC standards, so it shouldn’t muck up normal TCP handshakes… However, it’s not totally uncommon to run into weird, corner-case interoperability issues. May I as if it’s an Exchange server, or something else. We have worked well with Exchange (one of the most popular SMTP servers) in the past… Does syn checking prevent the server from receiving mail or sending it (or both)? Anyway, I can ask some of my support engineers if they have encountered this sort of issue, but I personally haven’t.
Incredible quest there. What happened after? Good luck!
Thank you after five years, I learned something I am now on the way to white hacker
usha room heater says
I really like you words and appreciate your article post. Really Cool please keep writing.