Cisco Security Response: Full-Disclosure: Multiple Vulnerabilities within Cisco EIGRP

Document ID: 68459

http://www.cisco.com/warp/public/707/cisco-sr-20051220-eigrp.shtml

Revision 1.0

For Public Release 2005 December 20 0330 UTC (GMT)

Please provide your feedback on this document.

Contents

Cisco Response
Additional Information
Revision History
Cisco Security Procedures

Cisco Response

This is Cisco PSIRT's 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
  

Cisco confirms the statements made.

These issues are being tracked by two Cisco Bug IDs:

• CSCsc13698 ( registered customers only) -- directed DoS attack employing the EIGRP "Goodbye Message"
  
• CSCsc13724 ( registered customers only) -- 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 Cisco Systems.

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

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:

1. 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: Cisco Security Notice: Cisco's Response to the EIGRP Issue
   This is documented in Cisco Bug ID: CSCsc15285 -- EIGRP ARP DoS No additional information is available at this time.
   
2. 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.
   

Bugtraq 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 

The configuration guide, available at http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrpf.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/123tip2r/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/123tip2r/ip2_i1gt.htm#wp1106697

Revision History

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_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.