ïÔ×ÅÔ 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:
>
>
er/040330.
> html
> * Authenticated EIGRP DoS / Information leak:
>
>
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:
>
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
> ";, which
> discusses EIGRP ARP DoS attacks. This topic has been previously
> addressed by Cisco. Please refer to:
>
>
> 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:
>
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 , 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
> "
> bility_pol
> icy.html"
>
> This includes instructions for press inquiries regarding
> Cisco security
> responses. All Cisco security advisories are available at
>
> -----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 :
>
/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:
>
>
er/040330.
> html
> * Authenticated EIGRP DoS / Information leak:
>
>
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:
>
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
> ";, which
> discusses EIGRP ARP DoS attacks. This topic has been previously
> addressed by Cisco. Please refer to:
>
>
> 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:
>
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 , 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
> "
> bility_pol
> icy.html"
>
> This includes instructions for press inquiries regarding
> Cisco security
> responses. All Cisco security advisories are available at
>
> -----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 :
>
/20051220/a41daa73/Cisco_Full_Disclosure_eigrp.txt.obj
>
> ------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> Hosted and sponsored by Secunia -
>
> End of Full-Disclosure Digest, Vol 10, Issue 62
> ***********************************************
>
