-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Response ============== This is Cisco PSIRTs' response to the statements made from Arhont Ltd. Information Security in their messages: * Unauthenticated EIGRP DoS. * Authenticated EIGRP DoS / Information leak. posted on the 2005 December 19th 17:00 UTC (GMT). The original emails are available at: * Unauthenticated EIGRP DoS: http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330. html * Authenticated EIGRP DoS / Information leak: http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332. html Attached is a cleartext, PGP signed version of this same email. Cisco confirms the statements made. These issues are being tracked by two Cisco Bug IDs: CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye Message" CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage We would like to thank Arhont Ltd. Information Security, especially Konstantin V. Gavrilenko and Andrew A. Vladimirov for reporting these issues 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 ====================== Posting: Unauthenticated EIGRP DoS +--------------------------------- Original Posting: http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330. html Cisco confirms the reports made by Arhont Ltd. Within this article two separate vulnerabilities are raised: a) EIGRP ARP DoS attacks Reference is drawn to "http://www.securityfocus.com/bid/6443", which discusses EIGRP ARP DoS attacks. This topic has been previously addressed by Cisco. Please refer to: http://www.cisco.com/en/US/tech/tk365/technologies_security_notice09186a 008011c5e1.html This is documented in Cisco Bug ID: "CSCsc15285 -- EIGRP ARP DoS" No additional information is available at this time. b) Directed DoS attack employing the EIGRP "Goodbye Message" The EIGRP implementation in all versions of IOS is vulnerable to a denial of service on selective neighbors, if it receives a spoofed neighbor announcement with either mismatched "k" values, or "Goodbye Message" TLV . Forged packets can be injected into a network from a location outside its boundary so that they are trusted as authentic by the receiving host, thus resulting in a failure of integrity. Such packets could result in routing neighbor relationships being torn down and reformed. Repeated exploitation could result in a sustained DoS attack. From a position within the network where it is possible to receive the return traffic or create neighbor establishments (but not necessarily in a position that is directly in the traffic path), a greater range of violations is possible. For example, the contents of a message could be diverted, modified, and then returned to the traffic flow again, causing a failure of integrity and a possible failure of confidentiality. EIGRP can operate in two modes - Unicast Hellos; Multicast Hellos. IOS versions 12.0(7)T and later, unicast hellos will be rejected unless explicitly configured in the neighbor statements. Once static neighbors are configured, IOS will only accept hello packets from defined neighbors. Cisco is tracking this report as part of: CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye Message" Cisco recommends protecting from forged source neighbor packets leveraging MD5 authentication and/or infrastructure protection schemes. Within the workarounds section the following will apply: * Static configured EIGRP neighbors (IOS versions 12.0(7)T and later) * Blocking access to the core infrastructure * Configure anti-spoofing measures on the network edge * 802.1x based port security * MD5 Neighbor Authentication Posting: Authenticated EIGRP DoS/Information leak +------------------------------------------------ Original Posting: http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332. html Cisco confirms the reports made by Arhont Ltd. - From a position within an EIGRP authenticated AS where it is possible to receive/listen to EIGRP Hello Updates, it is possible, with reply attacks, to forge illegitimate hello packets in an authenticated AS. This can result in additional information about the EIGRP domain being collected from the triggered UPDATE packets, by the malicious device. This could also result in carrying out similar DoS attacks as per "CSCsc15285 -- EIGRP ARP DoS", however within an authenticated AS. Cisco recommends proper securing of the IGP routers. Mechanisms such as port security or 802.1x may be used to ensure only valid routing devices are connected to the common segments. Cisco is tracking this report as part of: CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage Within the workarounds Section the following will apply: * Blocking access to the core infrastructure * 802.1x based port security Workarounds =========== Ensuring that the infrastructure devices are protected, by both local and remote access means will help mitigate these vulnerabilities. Blocking access to the core infrastructure +----------------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure access control lists (ACLs) are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper entitled: "Protecting Your Core: Infrastructure Protection Access Control Lists", available at http://www.cisco.com/warp/public/707/iacl.html, presents guidelines and recommended deployment techniques for infrastructure protection ACLs. Exceptions would include any devices which have a legitimate reason to access your infrastructure (for example, BGP peers, NTP sources, DNS serves, and so on). All other traffic must be able to traverse your network without terminating on any of your devices. Configure anti-spoofing measures on the network edge +--------------------------------------------------- In order for an adversary to use the attack vector described in this advisory, it must send packets with the source IP address equal to one of the IP addresses in the subnet of the EIGRP neighbors. You can block spoofed packets either using the Unicast Reverse Path Forwarding (uRPF) feature or by using access control lists (ACLs). By enabling uRPF, all spoofed packets will be dropped at the first device. To enable uRPF, use the following commands: router(config)#ip cef router(config)#ip verify unicast reverse-path </pre> The configuration guide, available at: http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configur ation_guide_chapter09186a00804b046b.html presents guidelines on how uRPF works and how to configure it in various scenarios. This is especially important if you are using asymmetric routing. ACLs should also be deployed as close to the edge as possible. Unlike uRPF, you must specify the exact IP range that is permitted. Specifying which addresses should be blocked is not the optimal solution because it tends to be harder to maintain. Caution: In order for anti-spoofing measures to be effective, they must be deployed at least one hop away from the devices which are being protected. Ideally, they will be deployed at the network edge facing your customers. 802.1x based port security +------------------------- To prevent unauthorized local access to the routing subnets that the EIGRP neighbor relationships exist on, deploying 802.1x on the router and switches (in 802.1x mutual authentication) would help mitigate any local attacks. For further information on how to configure 802.1x and products supported refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft /123limit/123x/123xa/gt_802_1.htm#wp1166017 Static defined peers +------------------- If neighbors are explicitly configured post integration of CSCdm81710 (IOS versions 12.0(7)T or later), this acts as a workaround for these vulnerabilities. Pre CSCdm81710, explicit neighbors are still subject to DoS attacks of this nature. Example post CSCdm81710: router eigrp 1 network 192.168.1.0 network 192.168.66.0 neighbor 192.168.66.2 FastEthernet0/0 neighbor 192.168.66.1 FastEthernet0/0 no auto-summary For further information on Static defined EIGRP neighbors refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1 23tip2r/ip2_n1gt.htm#wp1110498 MD5 Neighbor Authentication +-------------------------- Enabling MD5, will mitigate remote malicious tear down of neighbors, by the methods described within this document. For further information on MD5 EIGRP Neighbor Authentication refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1 23tip2r/ip2_i1gt.htm#wp1106697 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_pol icy.html" This includes instructions for press inquiries regarding Cisco security responses. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQ6dPA3sxqM8ytrWQEQLWYgCgyjX8d2wlcy7X0p+punRpEx8XuNIAoJHl zdgDiSjTuzaPLdnXgayxeDvF =rOWF -----END PGP SIGNATURE-----
Attachment:
Cisco_Full_Disclosure_eigrp.txt.asc
Description: Cisco_Full_Disclosure_eigrp.txt.asc