-------------------=========================------------------- 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 UPDATE - CISCO Response : -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Response ============== This is Cisco PSIRT's response to the statements made by Amin Tora in his message: [ADVISORY] CISCO ASA Failover DoS Vulnerability, posted on November 14, 2005. The original email is available at http://www.securityfocus.com/archive/1/416544/30/0/threaded Attached is a cleartext, PGP signed version of this same email. This issue is being tracked by two Cisco Bug IDs: * CSCsc34022 -- ASA-PIX requires improved failover testing method This DDTS has been resolved and the fix will be available in an upcoming version of software. The standby firewall now validates both the IP address and MAC address of all active firewall interfaces while conducting failover ARP testing. * CSCsc47618 -- Authenticate all messages between Active and Standby Firewalls This DDTS is under investigation and while not resolved there is a workaround to mitigate the issue. We would like to thank Amin Tora for reporting this issue to us. We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in product reports. Additional Information ====================== The Release Note Enclosure for CSCsc34022 states: +------------------------------------------------ Symptom: +------- The Standby firewall in failover pair may not take over when the Active firewall loses power or crashes. Conditions: +---------- For this issue to occur, a duplicate IP address matching one of the active firewall's IP addresses must be present on the same network subnet as the firewalls when the active firewall loses power or crashes. When the active firewall loses power or crashes, the standby firewall's LAN failover interface will lose connectivity with the active firewall. This causes the standby firewall to ARP for the IP address of each active firewall interface. Because the active firewall is now unreachable, the duplicate IP address matching the active firewall will cause the standby firewall to receive a reply to the ARP attempt. Upon receiving the erroneous ARP reply, the standby firewall will believe that the active firewall is still reachable and prevent the standby firewall from taking over. Due to the timing of two concurrent failover tests, there are still cases where the standby firewall will be able to determine that the active firewall is down even when a duplicate IP address is present; however, this can not be guaranteed. Workaround: +---------- Connecting the LAN failover interfaces of the firewalls to switch ports may minimize but not completely mitigate the chance that an otherwise active firewall will lose connectivity to its LAN failover interface. Preventing or correcting IP addresses that duplicate the firewall IP addresses is a complete workaround for this issue. The firewall will detect and log duplicate IP addresses 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>. Additional information about this syslog message is available at: http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/sys log/logmsgs.htm#wp1282234 Additional information about configuring failover in PIX and ASA 7.0 is available at: http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/con fig/failover.htm Additional information about configuring failover in FWSM 2.3 is available at: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/mod_icn/fwsm /fwsm_2_3/fwsm_cfg/failover.htm The Release Note Enclosure for CSCsc47618 states: +------------------------------------------------ Symptom: +------- An attacker who can spoof the IP address and MAC address of an active firewall's interface may prevent failover from occurring. Conditions: +---------- When the active firewall loses power or crashes, the standby firewall's LAN failover interface will lose connectivity with the active firewall. This causes the standby firewall to ARP for the IP address of each active firewall interface. The standby firewall will only accept the ARP response if the source MAC address matches the active firewall's interface MAC address. An attacker who can spoof the IP address and MAC address of the active firewall's interface can lead the standby firewall to believe that the active firewall is still reachable and prevent the standby firewall from taking over. Workaround: +---------- Configure port security on all switch ports configured to be in the same vlans as the active and standby firewalls enabled interfaces. Port security must not be enabled on the switch ports connected to the active and standby firewalls interfaces. Port security will prevent an attacker from spoofing the active firewall's interface MAC address allowing failover to occur normally. This configuration should be tested before being enabled in a production environment. For information on configuring port security refer to: 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 For information about layer 2 attacks and mitigations refer to: SAFE Layer 2 Security In-depth Version 2 http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_sol utions_white_paper09186a008014870f.shtml Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_poli cy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt Regards, Randy Randy Ivener Product Security Incident Response Team (PSIRT) Cisco Systems, Inc. rivener (at) cisco (dot) com [email concealed] http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQ3kGnG4/EyDEWh8IEQKBhACbB6PVS/9UY3puPDYx5TZLxgkUp9IAoJem ExnCz+YJioSK6OOENgSorGa5 =Or3I -----END PGP SIGNATURE-----