Message-ID: <BFD4D243999BA5458F6A8AC2CB357505A56B05@xmb-hkg-416.apac.cisco.com>
Date: Tue, 20 Dec 2005 08:39:44 +0800
From: "Paul Oxman \(poxman\)" <poxman@...co.com>
To: <full-disclosure@...ts.grok.org.uk>, <bugtraq@...urityfocus.com>,
	<info@...ont.com>
Cc: "psirt \(mailer list\)" <psirt@...co.com>
Subject: Re: Unauthenticated EIGRP DoS

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

Download attachment "Cisco_Full_Disclosure_eigrp.txt.asc" of type "application/octet-stream" (10291 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists