[NEWS] Cisco IPSec IKE Multiple DoS Vulnerabilities

From: SecuriTeam (support_at_securiteam.com)
Date: 11/15/05

  • Next message: SecuriTeam: "[NEWS] Oracle Password Hashing Algorithm Assessment" 
    To: list@securiteam.com
Date: 15 Nov 2005 12:46:48 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Cisco IPSec IKE Multiple DoS Vulnerabilities
    ------------------------------------------------------------------------

    SUMMARY

    IP Security, or IPSec, is a set of protocols standardized by the IETF to
    support encrypted and/or authenticated transmission of IP packets. IPSec
    is a protocol commonly used in Virtual Private Networks (VPNs). The
    Internet Key Exchange (IKE) protocol is used to negotiate keying material
    for IPSec Security Associations (SAs) and provides authentication of
    peers.

    Multiple Cisco products contain vulnerabilities in the processing of IPSec
    IKE (Internet Key Exchange) messages. The vulnerabilities can be exploited
    to produce a denial of service.

    DETAILS

    Vulnerable Systems:
     * Cisco IOS versions based on 12.2SXD, 12.3T, 12.4 and 12.4T
     * Cisco PIX Firewall versions up to but not including 6.3(5)
     * Cisco PIX Firewall/ASA versions up to but not including 7.0.1.4
     * Cisco Firewall Services Module (FWSM) versions up to but not including
    2.3(3)
     * Cisco VPN 3000 Series Concentrators versions up to but not including
    4.1(7)H and 4.7(2)B
     * Cisco MDS Series SanOS versions up to but not including 2.1(2)

    The first case is LAN-to-LAN VPN operation in which two devices negotiate
    an IPSec connection between them for the purposes of connecting two remote
    LANs via an IPSec tunnel. In this case the devices negotiating the IPSec
    connection generally have static IP addresses, and the IPSec tunnel is up
    as long as there is traffic that needs to traverse the tunnel.

    Successful exploitation of the vulnerability on the Cisco MDS Series may
    result in the restart of the IKE process. All other Cisco MDS device
    operations will continue normally.

    The second case is a Remote Access (RA) VPN which is typically used to
    allow remote clients a connection to a secure network or service. A common
    example of this is a user connecting to a corporate network while away
    from the office. In this scenario, the remote user could be connecting
    from anywhere, and their IP address is not static, but rather dynamically
    assigned via the transport provider.

    Successful exploitation of the vulnerabilities on all other Cisco devices
    may result in the restart of the device. The device will return to normal
    operation without any intervention required.

    IKE is not a requirement for the establishment of IPSec connections.
    Depending on your requirements and the devices involved, it may be
    possible to statically configure the SA information and disable IKE. This
    type of configuration may not be possible in the case of RA VPNs due to
    the user's IP address being unknown prior to the establishment of the
    IPSec connection.

    Only Cisco IOS images that contain the Crypto Feature Set contain the
    vulnerable IPSec code.

    When receiving certain malformed packets, vulnerable Cisco devices may
    reset, causing a temporary Denial of Service (DoS).

    Workaround:
    The effectiveness of any workaround is dependent on specific customer
    situations such as product mix, network topology, traffic behavior, and
    organizational mission. Due to the variety of affected products and
    releases, customers should consult with their service provider or support
    organization to ensure any applied workaround is the most appropriate for
    use in the intended network before it is deployed.
    For customers that use IPSec, but do not require IKE for connection
    establishment, IPSec connection information may be able to be entered
    manually, and IKE can be disabled, eliminating the exposure.

    Note: Due to the potential complexity of configuring IPSec information,
    this is likely not a viable alternative for most customers, but is
    mentioned here for completeness. Please consult your product documentation
    for further information on static IPSec configuration.

    Restricting IKE Messages:
    It is possible to mitigate the effects of this vulnerability by
    restricting the devices that can send IKE traffic to your IPSec devices.
    Due to the potential for IKE traffic to come from a spoofed source
    address, a combination of Access Control Lists (ACLs) and anti-spoofing
    mechanisms will be most effective.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:psirt@cisco.com> Cisco
    Systems Product Security Incident Response Team.
    The original article can be found at:
    <http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml>
    http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NEWS] Oracle Password Hashing Algorithm Assessment"

    Relevant Pages