Untangle firewall & TCP Split Handshake attack?

[untubby]

I couldn't find anything here or with Google, so I apologize if this has already been covered in another thread. I recently read the NetworkWorld article about the NSS Labs tests against TCP Split Handshake attacks against common firewalls and wondered if the Untangle firewall has been tested, internally or publicly?

I can't yet post links, so for the articles, google: "Hacker handshake hole found in common firewalls"

or

"Network Firewall Group Test Q2 2011"

[f1assistance]

Any action or response? Also, just curious...
http://preview.tinyurl.com/3ttyt4r

[mrunkel]

Results from testing indicate that devices behind an Untangle can not be exploited using the TCP Split Handshake attack.

Without Untangle. The "Acking the SYNACK. The handshake's a LIE!" indicates that the handshake process was reversed.

Watching for SYNs on eth0 to 9999...
Listening on port 9999...
Setting up the fake stack...
Got a SYN with seq = 1632255684 from 74.211.245.66
Generating packets...
Duping and splitting SYN and ACK...
Sending ACK...
Sending SYN...
Got a SYNACK with seq = 1632255684 from 74.211.245.66
Acking the SYNACK. The handshake's a LIE!
Got a PSH/ACK with seq = 1632255685, probably the GET...
"GET / HTTP/1.1\r\nHost: web.runkel.org:9999\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.57 Safari/534.24\r\nAccept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\nAccept-Encoding: gzip,deflate,sdch\r\nAccept-Language: en-US,en;q=0.8\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3\r\nCookie: __qca=P0-937716156-1296600354269\r\n\r\n"
Acking the GET...
Delivering the payload...
Payload ack'ed with seq = 1632256145. RSTing, since FINs are for chumps.
Sent a RST

And now behind Untangle. The connection never completes.

Payload ack'ed with seq = 587182396. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 587182396. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 587182396. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 587182396. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1125290482. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1125290482. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1125290482. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1125290482. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1625042030. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1625042030. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1625042030. RSTing, since FINs are for chumps.
Sent a RST
Payload ack'ed with seq = 1625042030. RSTing, since FINs are for chumps.
Sent a RST

Of course, this is all a tempest in a teapot. In order for this exploit to do *anything* the user inside your network must connect to a hostile server with a program that can be exploited by the reversing of the connection direction. Pretty unlikely.

This is not an attack against a firewall, it's an potential attack vector against a client behind a firewall by a malicious server.

For those interested, the code comes from the following article: http://nmap.org/misc/split-handshake.pdf

[dmorris]

Yes, I doubt the connection can complete at all.

This could theoretically be used to sneak past layer-7 processing on some devices, but untangle has two separate TCP connections. It expects a combined SYN/ACK on the second connection. Without it, it won't complete and nothing will pass.

[untubby]

Thank you!