

Hacker 'handshake' hole found in common firewalls - asymptotic
http://www.networkworld.com/news/2011/041211-hacker-exploit-firewalls.html

======
asymptotic
This article is based on a report release by NSS Labs titled "Network Firewall
2011 Comparative Test Results", released Q2 2011. Unfortunately the report
costs USD3,500.

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>

~~~
willscott
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'.

~~~
trotsky
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?

~~~
ominous_prime
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.

~~~
trotsky
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?

~~~
ominous_prime
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.

~~~
metageek
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.

------
masto
"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

~~~
metageek
Like much of this article, it says "I can't form a coherent sentence.".

Just change "all but one" to "only one".

------
user24
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.

------
calloc
Does this affect the OpenBSD packet filter (PF) at all? Should I be concerned
if I am using PF as my firewall of choice?

~~~
jrockway
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. "

------
willvarfar
They also report that many of them fall over under fuzzing attacks

------
jrockway
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?

~~~
theBobMcCormick
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.

------
bcl
And this is why I setup all my firewalled machines like they were outside my
router. Just In Case.

