Hacker 'handshake' hole found in common firewalls(networkworld.com)
networkworld.com
Hacker 'handshake' hole found in common firewalls
http://www.networkworld.com/news/2011/041211-hacker-exploit-firewalls.html
7 comments
From the linked paper, the 'trick' here is for the attacker to improperly respond to a tcp connection initiated from the target.
The standard handshake looks like:
Syn ->
<- Syn / Ack
Syn ->
The 'split handshake' looks like:
Syn ->
<- Syn
Syn / Ack ->
<- Ack
As a result, the hypothesis is that the intermediary router could incorrectly flip the roles of client and server, and incorrectly forward untrusted packets from the outside 'client'.
The standard handshake looks like:
Syn ->
<- Syn / Ack
Syn ->
The 'split handshake' looks like:
Syn ->
<- Syn
Syn / Ack ->
<- Ack
As a result, the hypothesis is that the intermediary router could incorrectly flip the roles of client and server, and incorrectly forward untrusted packets from the outside 'client'.
I guess I don't fully understand the NSS labs attack here. In both of the scenarios laid out by Macrothink it appears that control of the server (that would be protected by the firewall) is needed for the attack to be carried out. Can an outside attacker really gain access to an otherwise blocked server this way, or is this more of a case of evading logging or IDS/IPS rules? Unless I misunderstand (which seems likely) it seems something like disabling the security cameras after you break into a bank so that they can't record you taking the money out.
Could anyone explain to a simpleton how the NSS version of the attack works using only client access?
Could anyone explain to a simpleton how the NSS version of the attack works using only client access?
The "server" doesn't necessarily need to be the target in an attack. The attacker would be in control of the server in this scenario, and the "client" is a machine within the targeted network. The "client" and "server" labels are only representative of who is initiating the tcp connection.
Hi! Thanks for your response. I didn't mean to get us hung up on the terminology. Let's call one machine the "Internet side" and one machine the "Protected side". I have read the Macrothink paper another time, and I still believe that you need to modify the behavior of the "Protected side" host (ie, you'd need to have prior access) before this attack would work. Is that incorrect?
Unfortunately, I haven't had time to read through the paper, and only got through the first few pages. From what I see though, the point of the attack is to punch through by using the improper handling of the split handshake by a client, which apparently fools some firewalls. For this to happen, you would only need to get a client to open a tcp connection to your malicious server, which is trivial. I'll have to take a closer look at the paper later on to to give more detail though. Hopefully someone else will chime in in the meantime.
And, from the Macrothink paper, it looks like it's not so much "open an inbound connection through the firewall" as "trick the firewall into not scanning the payload". Not relevant for, say, home routers that don't do scanning in the first place.
"NSS Labs recently tested half a dozen network firewalls to evaluate security weaknesses, and all but one of them was found not to be vulnerable"
What does this say I don't even
What does this say I don't even
Like much of this article, it says "I can't form a coherent sentence.".
Just change "all but one" to "only one".
Just change "all but one" to "only one".
I get the sense this is being hyped because of the cloak-and-dagger feeling engendered by the phrase 'hacker handshake', more than the flaw itself.
Does this affect the OpenBSD packet filter (PF) at all? Should I be concerned if I am using PF as my firewall of choice?
I haven't verified PF, but it seems that it wasn't even tested. My guess is that PF is not vulnerable because PF has a pretty good understanding of how TCP works. For example, it can do SYN proxying, where PF talks to each side itself rather than just blindly forwarding things through the firewall:
"Normally when a client initiates a TCP connection to a server, PF will pass the handshake packets between the two endpoints as they arrive. PF has the ability, however, to proxy the handshake. With the handshake proxied, PF itself will complete the handshake with the client, initiate a handshake with the server, and then pass packets between the two. The benefit of this process is that no packets are sent to the server before the client completes the handshake. This eliminates the threat of spoofed TCP SYN floods affecting the server because a spoofed client connection will be unable to complete the handshake. "
"Normally when a client initiates a TCP connection to a server, PF will pass the handshake packets between the two endpoints as they arrive. PF has the ability, however, to proxy the handshake. With the handshake proxied, PF itself will complete the handshake with the client, initiate a handshake with the server, and then pass packets between the two. The benefit of this process is that no packets are sent to the server before the client completes the handshake. This eliminates the threat of spoofed TCP SYN floods affecting the server because a spoofed client connection will be unable to complete the handshake. "
They also report that many of them fall over under fuzzing attacks
Not sure I agree with the word "common". "Expensive" would be better.
Who would use security software that doesn't ship with the source code, anyway? How can you trust something that you can't even see?
Who would use security software that doesn't ship with the source code, anyway? How can you trust something that you can't even see?
You're kidding right? I've never seen a major enterprise yet that didn't use one of those brands of firewalls. Maybe Pix's and Palo Alto's are common for bootstrapped startups, but they're ubiquitous in big business networks.
Corporate firewalls aren't about trust, they're about box ticking and support contracts (and if you're lucky, you get some protection in there too)
And this is why I setup all my firewalled machines like they were outside my router. Just In Case.
For more details about the attack consider reading:
The TCP Split Handshake Attack: Practical Effects on Modern Network Equipment (BreakPoint Systems, 2010) http://nmap.org/misc/split-handshake.pdf