Hacker 'handshake' hole found in common firewalls

[Ruwini]

Hi All,

Just wond the below from the Networkworld.com , is juniper SRX and SSG gear vulnerable to TCP Split handshake , we've got dozens of SRX gear running and this is scary... can any body please shed some light into this..

http://www.networkworld.com/news/2011/041211-hacker-exploit-firewalls.html?source=NWWNLE_nlt_daily_a... 

Regards,

ruwini

[tbehrens]

It's a server-initiated attack. The effect is to side-step existing IDP protections that shield clients from malicious servers. See http://nmap.org/misc/split-handshake.pdf

Enabling the TCP:AUDIT2C-SIMUL-SYN signature will protect against this attack according to the above paper.

I do not have access to the full NSS paper, only to the summary findings. I am not quite sure what the assertion that split handshake "allows an attacker inside the firewall as a trusted client" means outside of IPS/IDP. NSS specifically did not test IDP, but firewalling only.

There is a workaround for SRX firewalls, which may however impact applications that do not use TCP correctly.

set security flow tcp-session strict-syn-check

[Ruwini]

Hi,

Thanks for getting an insight into the issue  do you think there would be any repercussion in enableingthe following :

set security flow tcp-session strict-syn-check

Majority of my SRX deployments are for protecting the client networks from internet and in most cases the traffic would be HTTPS, SMTP , HTTP but i do have clients who are useing SAP ERP and FIX protocol.

Appreciate your feed back please..

thanks,

ruwini

[tbehrens]

It all depends on how the stack behaves. In the vast majority of cases, enabling strict SYN check won't break anything. Still, it's best to say to your clients: "This is what NSS found. This is what we propose to do to keep you secure. Please have an application test checklist handy, and give us a window. We will make the change, you will test all your applications"

That is really the only way to be sure that you won't break application X in a client environment.

Good luck!

[motd]

From what I read, its a server-based attack where a client connects to a server and then the server sends a specially crafted syn packet back. The firewall sees that syn and thinks the connection is initiated by the server.

I can see how this can confuse IDP because it performs different scanning on client-to-server and server-to-client traffic, but I have a hard time imaging how this is supposed to bypass firewall policies. Who on earth allows their servers to connect back to clients on random high ports? And even if you do, you already allowed the client to connect to the server in the first place, so this doesn't open any new ports.

Either I completely misinterpreted the explanation of the issue (I'm not going to pay for the entire document), or this seems like a lot of fuzz about nothing.

[rasmus]

strict syn check will resolve you issue

regards

[Ruwini]

Thankyou guys for the loads of information... I think we could finally see some light at the end of the tunnel and solve this issue.. perhaps NSS got over excited over the issue...

Thnakyou again...

Ruwiniw

EWIS - Sri Lanka

[Automate]

See: KB20877 (login required)

[link2ali]

No access to the KB even after log in.

[tbehrens]

That KB just lists the strict syn check config options. According to NSS, Juniper will make strict syn check a default setting from now on.

Still no word as to what NSS' test of pure firewalling with split handshake found. All of the papers I can find, including the one linked to by NSS, speak of how this technique can be used to bypass IDP protections. Which begs the question: Since it's server-initiated, and you specifically didn't test IDP, what exactly is the concern here?

NSS will have a webinar later today on it. I'm hoping they'll open the kimono a bit and don't just tell us to "buy the report."