Firewall security issue raised in report ignites vendors’ ire

A test by NSS Labs that found firewalls from five vendors are subject in one way or another to remote exploit by hackers has ignited furious response from vendors Fortinet and SonicWall.

Hacker “handshake” hole found in common firewalls

That NSS Labs study, released this week, says that independent security testing of six separate vendor firewalls showed five of them to be vulnerable to what’s known as the “TCP Split Handshake Attack” that lets a hacker fool the firewall into thinking an IP connection is a trusted one behind a firewall.

Firewalls from Cisco, Fortinet, Juniper , Palo Alto Networks and SonicWall had products that were criticized in the NSS Labs report (only a Check Point firewall escaped criticism about the ability to prevent the hacker “TCP Split handshake” attack). Now, two of the vendors, Fortinet and Sonicwall, are firing back at NSS Lab about how their firewall products were critiqued.

“NSS Labs tested the Fortigate-3950B platform using equipment supplied by a NSS customer and not configured by Fortinet,” said Patrick Bedwell, vice president of marketing at Fortinet, in a prepared statement. Bedwell’s remarks go on to say that Fortinet was “not given the opportunity to work with NSS Labs on the testing” but that “we have been working diligently with NSS Labs over the last month to remediate any issues raised in the test.”

The Fortinet statement says “the FortiGate platforms are not susceptible to split handshake attacks when AV [antivirus] and IPS [intrusion-prevention system] engines are enabled, which was suggested to NSS as the initial solution. In addition, following guidance received from NSS’ CTO, Fortinet developed new IPS signatures to explicitly block the handshake, which are available today to all customers. Lastly, Fortinet agreed to implement changes in our firewall functionality to explicitly block the split handshake after learning that NSS didn’t consider IPS signatures as a valid response for this particular test.”

Fortinet adds that while the majority of its customers use integrated firewall and IPS, “for those few customers who are using standalone firewall, we are finalizing the release of a firmware upgrade, to explicitly prevent the split handshake, which we plan to make available shortly.”

Fortinet also said “the IPS signature is a short-term work around to the split handshake, and provides immediate protection against this issue. Customers can enable a single IPS signature if they are not running the IPS feature that is included in the FortiGate consolidated security platform.”

NSS Labs President Rick Moy says in response to Fortinet’s remarks that ‘they were invited to the test but refused, which is why we had to use a client’s firewall that Fortinet had configured, which was default.”

Moy, who says he doesn’t believe the NSS Labs CTO provided them with advice about signatures, adds that Fortinet does “admit the firewall has some issues and they are releasing a patch.” He also questions whether they fully understand the TCP split handshake attack.

SonicWall is the second vendor with its hackles raised by the NSS Labs report . The report says the SonicWall NSA E8500 firewall doesn’t provide protection against the attack by default.

“They said we failed the test,” says Dmitri Ayrapetov, SonicWall’s product manager for network security, explaining why SonicWall is upset with the report from NSS Labs. He adds SonicWall has a checkbox-activated feature that can be turned on to address the TCP split handshake security issue, and that SonicWall repeatedly “asked them to turn it on” and change the box from the default setting. The NSS Labs report does point out the existence of this SonicWall checkbox-activated feature.

Ayrapetov acknowledges the protection against the TCP split handshake attack isn’t turned on by default in the SonicWall firewall, but SonicWall is considering changing that. One main thing under review, however, is that turning it on by default may cause operational problems. It can “cause interference issues when you turn it on,” Ayrapetov says. The reasons for this can be complex, but the interference generally occurs because of an impact on network performance, he says.

Moy says in his view, the protection mechanism should be turned on by default in firewall products. “Why is it not on by default?”

“It can be done,” he adds, noting Check Point made it through the test to show that, Juniper has come back with a fix and Palo Alto is also working to make a fix they have permanent in their product.