TCP Split Handshake and How It Could Affect Your Firewall Configuration

firewall1For those of us who work in the security world, a recent attack called TCP Split Handshake has caused many of us to question what is considered secure and what best practices are. This attack circumvents a rudimentary firewall configuration called “established session” in which a firewall will permit a session that was initiated from a “secured” network to go to the Internet “unsecured” and back based on the fact that it was initiated from a secured and trusted source.  This mechanism is based on RFC 793 by which a client initiates a connection to the server sending a SYN packet with an initial random sequence number. The server acknowledges the SYN packet by sending back the initial sequence number in addition to its own sequence number (the initial number plus 1). This handshake exchange establishes the state of the connection.  The response from the server, in which one packet acknowledges the client’s initial request and initiates its own connection, is how the attack is created.

The TCP Split Handshake is conducted by changing the response from one packet to acknowledge the initial SYN and initiate a new connection to two packets, one for each.  Interestingly enough, many firewall’s vendors lose the ability to maintain state in this condition and, sessions become listed as “established” when, in actuality, they were never initiated by the client. Since most security professionals allow connections initiated from the inside to go to the Internet and come back unfettered based on the assumption that the firewalls can figure out the state of the connection, this attack leaves a large number of firewalls, networks, users, and companies unprotected.  Palo Alto Networks was the first to fix this flow by patching their code to 4.0.2, however other vendors have been slow to follow suit and some are in flat out denial of the fact despite the NSS’s ability to simulate the condition multiple times in multiple scenarios.

Please check with your firewall vendor to see if your firewall is affected by this attack and/or contact CrossRealms, Inc. for further information.