<<< Date Index >>>     <<< Thread Index >>>

[ADVISORY] CISCO ASA Failover DoS Vulnerability

-------------------=========================-------------------

   Advisory  : EPSIRT 051028-ASA01

   Title     : CISCO ASA Failover DoS Vulnerability

   Release   : November 14, 2005

   Author    : Amin Tora

   Severity  : Denial of Service

   Risk Level: Low

   Product   : CISCO Adaptive Security Appliances
               running: 7.0(0), 7.0(2), 7.0(4)

-------------------=========================-------------------

   --== Overview ==-

A possible denial of service against failover can occur due to a race 
condition when there is an IP conflict or spoofed ARP response upon 
active firewall failure.

   --== Details ==-

An inherent weakness in the CISCO ASA failover testing algorithm and 
methodology was identified and noted to CISCO TAC and PSIRT.  In 
general, the two weaknesses have been identified as a race condition 
between two different failover testing processes and a lack of 
authentication for failover messages between active and standby.  The 
prior condition has been resolved and will be available in an upcoming 
version of ASA software.  These conditions are noted in CISCO bug IDs:

  * CSCsc34022 - ASA-PIX requires improved failover testing method
  * CSCsc47618 - Authenticate all messages between Active and Standby 

In an Active/Standby configuration: 

When failover LAN communications goes down {i.e. cable problem, 
switch/hub failure, interface failure, ASA software bug, etc}, the 
standby firewall sends ARP requests on each of the segments for the IP 
address of the Active firewall to see if the Active is still alive.  If 
there is a response for AT LEAST ONE of the requests, the standby will 
NOT become active (i.e. there is no failover).

This scenario can occur when:

1. Failover LAN interface fails AND you have a failure on any of the 
other traffic carrying interfaces, EXCEPT for one.

2. Failover LAN interface fails AND you have a power failure on the 
ACTIVE firewall, AND there exists an "IP address conflict" with a 
traffic carrying interface.

Here, the "IP address conflict" can be another improperly configured 
device with the same IP as assigned on a traffic carrying interface, or,

it could be an ARP spoof attack.  

During such an outage, by sending at least one ARP response to the 
standby's ARP requests an attacker can cause a "failover denial of 
service" by not allowing the standby to become active - rendering the 
failover solution ineffective.

The "interface-policy 1" command may or may not resolve this issue as 
there is a race condition between to separate processes performing two 
separate tests {i.e. one for interface failure and one for the ARP 
test}.  Depends on who gets to the finish line first.


   --== Impact ==-

It is believed the severity on this issue is low. An attacker would 
require direct access to the network segment AND there would have to be 
some form of failure on the active firewall.

All these conditions must be met for an attacker to succeed with the 
denial of service:

       1. Have some form of access to a local segment of the firewalls:
       
                A. Direct physical access to network segment to connect 
                their own system (i.e insider) OR
       
                B. Somehow inject continuous ARP reply packets onto the 
                segment via tunneling, etc. OR
       
                C. Have access to a compromised host on that segment

       2. Have a failure on the primary.

       3. Respond with spoofed ARP replies to the standby's ARP request
       test.

The likelihood that all these conditions can be met is minimal but not 
impossible as other attack methods may prove effective.


   --== Mitigation ==-

1. Prevent or correct IP address conflicts on the traffic carrying 
segments.

2. The firewall will detect and log IP address conflicts with system 
log message:

%PIX-4-405001: Received ARP response collision from <firewall IP 
address/mac address of device with duplicate IP address> on interface 
<firewall interface>.

3. Restrict via port security and/or filter ARP communications with 
ACL's based on IP type 0x0806 and 0x0835.


   --== References ==-

Additional information about IP conflict log message:
http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/sys
log/logmsgs.htm#wp1282234 

Configuring failover on PIX and ASA:
http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/con
fig/failover.htm 

Catalyst 6500 Series Cisco IOS Software Configuration Guide Configuring 
Port Security 
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configura
tion_guide_chapter09186a0080160a2c.html 

Catalyst 6500 Series Software Configuration Guide 
Configuring Port Security 
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configura
tion_guide_chapter09186a008022f27b.html 

LAN Security Configuration Guides 
http://www.cisco.com/en/US/tech/tk389/tk814/tech_configuration_guides_li
st.html 

Blocking ARP packets with ACL's on 2970, 3550, 3560, and 3750:
http://www.cisco.com/en/US/products/hw/switches/ps646/products_configura
tion_example09186a0080470c39.shtml

HPing packet generator
http://www.hping.org/

ARP Spoofing using DSniff:
http://naughty.monkey.org/~dugsong/dsniff/faq.html


   --== Credit ==-

Amin Tora, ePlus Security Team


   --== Contributors ==-

ePlus Security Team:

        William Zegeer
        Christopher Cole

Outside Contributors:

        John Biasi
        John Guerriero
        Frank Vitale
        Everyone at CISCO PSIRT

-------------------=========================-------------------
EOM