BlueWolf's Howl

« Inspiration | Bluewolf's Howl | The Stats Jump »

November 30, 2005

Cisco's Response

In my 'Morning News' I found an interesting article:

Response to Cisco PIX TCP Connection Prevention

This is Cisco PSIRT's response to the statements made by Arhont Ltd.- Information Security in its message: [Full-disclosure] Cisco PIX TCP Connection Prevention, posted on November 22, 2005.
The original email is available at http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038971.html

For the layperson who may be reading... People (researchers) report things that they find which could be used to compromise a system. Responsible researchers report it to the company that wrote the software, and responsible companies address the issues with upgrades, patches and workarounds. That's the way it's supposed to work. And in most cases, that's how many systems get patched or fixed.

The thing I find interesting is the explanation of the exploit.

By sending a TCP SYN packet with an incorrect checksum through a PIX firewall, the PIX will block new TCP connections using the same source and destination TCP ports and IP addresses.

This happens because the TCP SYN from the spoofed IP | port opens up an embryonic connection (half-open) in the PIX. The normal way TCP operates is that the SYN is sent in one direction and all other traffic behind it (for that connection) waits for the SYN ACK to return and then sends an ACK to complete the 'three-way handshake' and then the traffic flows. If you spoof the IP | port of a legitimate connection, the legitimate SYN (and all the traffic behind it) never makes it to the device because it's waiting for the SYN ACK which never comes. [Since the SYN is a malformed packet, it's silently discarded by the destination and never acknowledged.] So the spoofed SYN botches things up for the legitimate connection. It's somewhat of a variation on the old SYN attack - where spoofed addresses send a series of SYN packets to tie up a device and thereby cause a denial of service. Instead of fake address traffic tying up the device, it's a spoof of a real address which ties up/blocks legitimate traffic.

Since this uses the way TCP/IP operates to cause its damage [as opposed to the way the software handles errors], I would imagine that this exploit could be used against other devices.

Interesting to note that this can be fixed in the latest release of PIX software. PIX software version 6.3 does not verify the TCP checksum of packets transiting through the firewall. PIX/ASA software version 7.0 can be configured to verify checksums, but this may impact firewall performance and should be tested prior to use in a production environment.

Also available in version 7.0 is the ability to configure TCP Intercept.

TCP Intercept can be configured to allow the PIX to proxy all TCP connection attempts originated from behind any firewall interface after the first connection. PIX will create and send the TCP SYN,ACK from the destination to the original source. Since the original TCP SYN packet was spoofed, the source IP address will not be tracking the TCP connection and it will send a TCP RST to the PIX. The PIX will then close the connection originating from the TCP SYN packet with the invalid checksum. This workaround should be effective regardless of the cause of the issue.

Kinda makes you wonder if they figured this one out before the researcher... since the capability to counteract it is included in the latest release. Also interesting is that it's not enabled by default -- which makes sense because of the performance impact. No one wants to upgrade their software and slow their traffic. But.... if there's an access problem and the problem is 'fixed' -- then it becomes 'acceptable' to take a performance hit to resolve the problem.

Posted by BlueWolf on November 30, 2005 09:11 AM