Recently the information security landscape was abuzz over findings from a recent NSS Labs report on firewalls, wherein products were found to be vulnerable to a TCP split handshake attack. This attack concept was based on research by Tod Beardsley and Jin Qian of BreakingPoint Systems.
Normally, TCP is considered to use a “three-way handshake”, where applications start sessions with a SYN, which response is a SYN/ACK, followed by a corresponding ACK from the originator of the session, as outlined in RFC 793. What Beardsley and Qian noticed is that the RFC actually spells out in section 3.3 a four way process, and states that “steps 2 and 3 can be combined in a single message”. Note that although this is the typical way systems handle it, there is no requirement to combine the SYN and ACK of the recipient.
Without getting into the further nitty-gritty details, the bottom line of the research and the recent testing is that stateful network security devices relying on an expected handshake sequence can be fooled into thinking that a connection is originating from a trusted segment instead of from the actual source. Although Stonesoft was not a tested vendor we decided to independently verify StoneGate’s handling of this situation. You can read more about the issue in various articles, such as The CyberJungle, or Government Security News.
Stonesoft’s research team, the Vulnerability Analysis Group tested both the StoneGate IPS and StoneGate Firewall/VPN, using the same BreakingPoint tests as outlined in the research paper. Our initial conclusion is that neither product is affected by this issue. For the StoneGate IPS, a four or five-way handshake will fail to hide the payload (direction) from the IPS, with the four-way flagged as “TCP_Segment-SYN-Unexpected-Reply”, and the five-way scenario [which is also very unlikely in real-world environments] as “TCP_Window_Shrinked”. The four-way handshake situation is not set to terminate by default, but it can easily be set if conditions or policy warrant.
For the StoneGate Firewall/VPN, the behavior is dependent on an Advanced property of the firewall or firewall cluster, whether it operates in loose, normal, or strict mode, and the behavior is further influenced by whether traffic in any given rule is inspected or anti-virus applied. With inspection and anti-virus, attacks in the payload are detected regardless of the handshake mechanism. Loose and normal mode with no additional inspection methods will permit the handshake. Strict mode will drop the connection. In any situation, the StoneGate Firewall/VPN will not be confused as to the origin of the session, so the bottom line is as with all security policies in StoneGate: what is not expressly permitted, is denied.
Stonesoft looks forward to the opportunity to participate in future tests and supports community efforts to drive improved testing of network security systems. Only by bettering testing efforts can we continue to ensure our solutions remain
Network Security. Simplified.
written by markb - 1,365 views
\\ tags: information assurance, security threat, stonegate
(6 votes, average: 4.83 out of 5)
Loading ...
No Comments »
Recent Comments