[NEWS] Cisco PIX TCP Connection DoS

• Previous message: SecuriTeam: "[TOOL] TFTP Filename Bruteforcer"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: list@securiteam.com
Date: 27 Nov 2005 14:06:17 +0200

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

  Cisco PIX TCP Connection DoS
------------------------------------------------------------------------

SUMMARY

"The <http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/> Cisco PIX
Firewall delivers strong security and, with market-leading performance,
creates little to no network performance impact."

By crafting a special TCP packet and sending it to a vulnerable Cisco PIX,
remote attackers can cause the program to no longer respond to legitimate
packets.

DETAILS

Vulnerable Systems:
 * PIX version 6.3
 * PIX version 7.0

PIX 6.3:
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. Connections will remain blocked
for approximately two minutes after which connections will be allowed.
This behavior may be seen on all firewall interfaces but can be expected
to have the most impact on TCP connections originating from higher
security level interfaces to lower security level interfaces.

Since the spoofed packets have an incorrect checksum, they are silently
discarded by the destination and the firewall will not see a RST packet
from either the destination or the legitimate source and will hold the
embryonic connection open until the embryonic connection timeout which is
2 minutes by default.

The root cause is due to the spoofed packet creating an embryonic
connection which sets up the TCP sliding window. A valid packet from a
real host using the same connection as the spoofed packet sends a SYN over
the same connection. The sequence number of the valid packet is
out-of-window and rejected by the firewall's TCP sequence number check.
Any subsequent retransmissions of the valid packet are also out-of-window
and are rejected by TCP sequence number check.

Other spoofed TCP SYN packets that create embryonic connections can also
cause this behavior, blocking legitimate TCP connections until the
embryonic connection times out.

For discarded TCP connections originating from lower security level
interfaces to higher security level interfaces, TCP Intercept can be
configured on "STATIC" commands by setting the "emb_limit" to 1. This
results in the PIX proxying all connection attempts after the first
connection. The 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 incorrect checksum. TCP
Intercept may impact firewall performance and should be tested before
being enabled in a production environment.

PIX software version 6.3 does not verify the TCP checksum of packets
transiting through the firewall.

Because the PIX does not verify the TCP checksum, the malformed TCP packet
is allowed through the firewall in a half-opened, embryonic state.

The destination host discards the received malformed segments.
Because the firewall does not see a return segment from the destination
host it holds the half-open TCP connection open until the embryonic
timeout which is set to two minutes for PIX 6.3 and earlier software.

Because the firewall is holding a connection open, any additional packets
with the same protocol, IP addresses, and ports will be treated as part of
the existing half-open connection. In this case, a legitimate SYN packet
following the malformed SYN will be discarded because it is outside of the
window of acceptable sequence numbers established by the malformed packet.

Workarounds:
Issuing the commands "clear xlate" or "clear local-host <ip address on the
higher security level interface>" will allow the firewall to pass
connections again.

TCP connections discarded because of this issue can be verified by
enabling "debug fixup tcp". 'Out of Window' drops will then generate
messages that begin with "tcpseq: discard old packet". Debug messages may
impact firewall performance and should be tested before being enabled in a
production environment.

PIX/ASA 7.0:
By sending a TCP SYN packet with an invalid checksum through a PIX
firewall, the PIX will block new TCP connections using the same source and
destination TCP ports and IP addresses. Connections will remain blocked
until the embryonic connection timeout which is 30 seconds by default.
This behavior may be seen on all firewall interfaces but can be expected
to have the most impact on TCP connections originating from higher
security level interfaces to lower security level interfaces.

Since the spoofed packets have an invalid checksum, they are silently
discarded by the destination and the firewall will not see a RST packet
from either the destination or the legitimate source and will hold the
embryonic connection open until the embryonic connection timeout which is
30 seconds by default.

The root cause is due to the spoofed packet creating an embryonic
connection which sets up the TCP sliding window. A valid packet from a
real host using the same connection as the spoofed packet sends a SYN over
the same connection. The sequence number of the valid packet is
out-of-window and rejected by the firewall's TCP sequence number check.
Any subsequent retransmissions of the valid packet are also out-of-window
and are rejected by TCP sequence number check.

Other spoofed TCP SYN packets that create embryonic connections can also
cause this behavior, blocking legitimate TCP connections until the
embryonic connection times out.

This behavior can be verified by issuing the command: "show asp drop"

The counter for "TCP RST/SYN in window" or "TCP SEQ in SYN/SYNACK invalid"
should increment for every packet dropped in this manner.

Workarounds:
Several workarounds exist for this issue.

1. Issuing the commands "clear xlate" or "clear local-host <ip address on
the higher security level interface>" will allow the firewall to pass
connections again.

2. The default TCP embryonic connection timeout is 30 seconds. This
default can also be modified which further mitigates the issue. This
workaround should be effective regardless of the cause of the issue.

This configuration example sets the TCP embryonic connection timeout to 10
seconds for the default "global_policy" policy-map:

access-list tcp_inspection extended permit tcp any any
access-list tcp_inspection extended deny ip any any

class-map my_inspection_tcp
match access-list tcp_inspection

policy-map global_policy
class my_inspection_tcp
set connection timeout embryonic 0:00:10

service-policy global_policy global

3. 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.

This example proxies all TCP connection attempts originated from any
firewall interface
after the first connection for the default "global_policy" policy-map:

access-list tcp_inspection extended permit tcp any any
access-list tcp_inspection extended deny ip any any

class-map my_inspection_tcp
match access-list tcp_inspection

policy-map global_policy
class my_inspection_tcp
set connection embryonic-conn-max 1

service-policy global_policy global

4. When invalid checksums are the cause of this issue, PIX/ASA software
version 7.0 can be configured to verify TCP checksums which will eliminate
the impact. Verifying TCP checksums may impact firewall performance and
should be tested before being enabled in a production environment.

This example verifies TCP packet checksums for the default "global_policy"
policy-map:

tcp-map verify-chksum
checksum-verification

access-list tcp_inspection extended permit tcp any any
access-list tcp_inspection extended deny ip any any

class-map my_inspection_tcp
match access-list tcp_inspection

policy-map global_policy
class my_inspection_tcp
set connection advanced-options verify-chksum

service-policy global_policy global

ADDITIONAL INFORMATION

The information has been provided by <mailto:rivener@cisco.com> Randy
Ivener (rivener).
The original article can be found at:
<http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038971.html> http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038971.html

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

• Previous message: SecuriTeam: "[TOOL] TFTP Filename Bruteforcer"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]