Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

   


   


   

















      :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FYI: Unauthenticated EIGRP DoS



 cisco -     

> ------------------------------
> 
> Message: 14
> Date: Tue, 20 Dec 2005 08:39:44 +0800
> From: "Paul Oxman \(poxman\)" <poxman@xxxxxxxxx>
> Subject: [Full-disclosure] Re: Unauthenticated EIGRP DoS
> To: <full-disclosure@xxxxxxxxxxxxxxxxx>, <bugtraq@xxxxxxxxxxxxxxxxx>,
>       <info@xxxxxxxxxx>
> Cc: "psirt \(mailer list\)" <psirt@xxxxxxxxx>
> Message-ID:
>       
> <BFD4D243999BA5458F6A8AC2CB357505A56B05@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
> 
>  
> -----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-Decemb
er/040330.
> html
>     * Authenticated EIGRP DoS / Information leak:
>  
> http://lists.grok.org.uk/pipermail/full-disclosure/2005-Decemb
er/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-Decemb
er/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_no
> tice09186a
> 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-Decemb
er/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/product
> s_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/ios12
> 3/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/ios12
> 3/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/ios12
> 3/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_vulnera
> bility_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-----
>  
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Cisco_Full_Disclosure_eigrp.txt.asc
> Type: application/octet-stream
> Size: 10291 bytes
> Desc: Cisco_Full_Disclosure_eigrp.txt.asc
> Url : 
> http://lists.grok.org.uk/pipermail/full-disclosure/attachments
/20051220/4406efd7/Cisco_Full_Disclosure_eigrp.txt.obj
> 
> ------------------------------
> 
> Message: 15
> Date: Tue, 20 Dec 2005 08:39:36 +0800
> From: "Paul Oxman \(poxman\)" <poxman@xxxxxxxxx>
> Subject: [Full-disclosure] RE: Authenticated EIGRP DoS / Information
>       leak 
> To: <full-disclosure@xxxxxxxxxxxxxxxxx>, <bugtraq@xxxxxxxxxxxxxxxxx>,
>       <info@xxxxxxxxxx>
> Cc: "psirt \(mailer list\)" <psirt@xxxxxxxxx>
> Message-ID:
>       
> <BFD4D243999BA5458F6A8AC2CB357505A56B04@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
> 
>  
> -----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-Decemb
er/040330.
> html
>     * Authenticated EIGRP DoS / Information leak:
>  
> http://lists.grok.org.uk/pipermail/full-disclosure/2005-Decemb
er/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-Decemb
er/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_no
> tice09186a
> 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-Decemb
er/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/product
> s_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/ios12
> 3/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/ios12
> 3/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/ios12
> 3/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_vulnera
> bility_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/AwUBQ6dOU3sxqM8ytrWQEQL75ACgprIi4RjgJICRAg8xMfWCfSciT+AAnA4r
> h8fOA5QaKJfB8l7iNLX/JpK2
> =B/ot
> -----END PGP SIGNATURE-----
>  
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Cisco_Full_Disclosure_eigrp.txt.asc
> Type: application/octet-stream
> Size: 10291 bytes
> Desc: Cisco_Full_Disclosure_eigrp.txt.asc
> Url : 
> http://lists.grok.org.uk/pipermail/full-disclosure/attachments
/20051220/a41daa73/Cisco_Full_Disclosure_eigrp.txt.obj
> 
> ------------------------------
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> End of Full-Disclosure Digest, Vol 10, Issue 62
> ***********************************************
> 




 




Copyright © Lexa Software, 1996-2009.