[NEWS] Vulnerabilities in Cisco IOS Secure Shell Server

From: SecuriTeam (support_at_securiteam.com)
Date: 04/12/05

  • Next message: SecuriTeam: "[NT] Ublog Multiple Vulnerabilities (Cross Site Scripting, Database Disclosure)"
    To: list@securiteam.com
    Date: 12 Apr 2005 16:18:36 +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

    - - - - - - - - -

      Vulnerabilities in Cisco IOS Secure Shell Server
    ------------------------------------------------------------------------

    SUMMARY

    Certain release trains of Cisco Internetwork Operating System (IOS), when
    configured to use the IOS Secure Shell (SSH) server in combination with
    Terminal Access Controller Access Control System Plus (TACACS+) as a means
    to perform remote management tasks on IOS devices, may contain two
    vulnerabilities that can potentially cause IOS devices to exhaust
    resources and reload. Repeated exploitation of these vulnerabilities can
    result in a Denial of Service (DoS) condition. Use of SSH with Remote
    Authentication Dial In User Service (RADIUS) is not affected by these
    vulnerabilities.

    Cisco has made free software available to address these vulnerabilities
    for all affected customers. There are workarounds available to mitigate
    the effects of the vulnerability (see the Workarounds section).

    DETAILS

    Vulnerable Products:
    These issues affect any Cisco device running an unfixed version of Cisco
    IOS that supports, and is configured to use, the SSH server functionality.

    To determine the software running on a Cisco product, log in to the device
    and issue the show version command to display the system banner. Cisco IOS
    Software will identify itself as "Internetwork Operating System Software"
    or simply "IOS." The image name will be displayed between parentheses
    shortly after this identification (possibly in the next line), followed by
    "Version" and the IOS release name. Other Cisco devices will not have the
    show version command or will give different output.

    The following example identifies a Cisco device running IOS release
    12.2(15)T14 (release train label "12.2T") with an installed image name of
    C806-K9OSY6-M:

    Router1>show version
    Cisco Internetwork Operating System Software
    IOS (tm) C806 Software (C806-K9OSY6-M), Version 12.2(15)T14, RELEASE
    SOFTWARE (fc4)
    [...]

    The next example shows a device running IOS release 12.3(10) (release
    train label "12.3 mainline") with an image name of C2600-IK9OS3-M:

    Router2>show version
    Cisco Internetwork Operating System Software
    IOS (tm) C2600 Software (C2600-IK9O3S3-M), Version 12.3(10), RELEASE
    SOFTWARE (fc3)
    [...]

    Additional information about Cisco IOS release naming can be found at
    <http://www.cisco.com/warp/public/620/1.html>
    http://www.cisco.com/warp/public/620/1.html.

    SSH protocol was introduced in the following IOS release trains:

     * IOS 12.0S (SSH version 1)
     * IOS 12.1T (SSH version 1)
     * IOS 12.2 (SSH version 1)
     * IOS 12.2T (SSH version 1)
     * IOS 12.3T (SSH version 2)

    To determine if the IOS image that your IOS device is running supports the
    server side of the SSH protocol, whether it is enabled (if supported), and
    the SSH protocol version being used (if SSH is supported and enabled), use
    the show ip ssh command in global mode:

    Router>show ip ssh
    SSH Enabled - version 1.5
    Authentication timeout: 120 secs; Authentication retries: 3

    The previous output shows that SSH is enabled on this device and that the
    SSH protocol major version that is being supported is 1. Possible values
    for the SSH protocol version reported by IOS are:

     * 1.5: only SSH protocol version 1 is enabled.
     * 1.99: SSH protocol version 2 with SSH protocol version 1 compatibility
    enabled.
     * 2.0: only SSH protocol version 2 is enabled.

    For more information about SSH versions in IOS, please check the following
    URL:
    <http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/gt_ssh2.htm> Secure Shell Version 2 Support.

    Note: SSH protocols versions 1 and 2 cannot interoperate, but usually a
    SSH server knows how to handle connections from clients using either
    version of the protocol, but in most cases the server has to be explicitly
    configured to do this. The latest revision of protocol version 1 is "1.5",
    which is documented in a now expired Internet Engineering Task Force
    (IETF) draft.

    The show ip ssh command was introduced in IOS release 12.1(1)T. If this
    command is not available then the IOS image in use does not have SSH
    server support and therefore it is not vulnerable to the issues discussed
    in this advisory.

    As you will see in the Details section, the behavior of the
    vulnerabilities described in this document can depend on the version of
    the SSH protocol that the IOS device is using. Therefore, it is important
    to use the show ip ssh command as shown above to obtain this information.

    When the show ip ssh command is executed on an image that does not support
    SSH the following output will be generated:

    Router>show ip ssh
                    ^
    % Invalid input detected at '^' marker.

    Router>

    Finally, even if the release and image running on an IOS device support
    SSH, the SSH server may not be enabled. The following example shows the
    output from the show ip ssh command on a device that supports SSH but that
    does not have the SSH server enabled (note the "SSH Disabled" message):

    Router>sh ip ssh
    SSH Disabled - version 1.5
    %Please create RSA keys to enable SSH.
    Authentication timeout: 120 secs; Authentication retries: 3
    Router>

    Products Confirmed Not Vulnerable:
    Devices not running IOS, running an IOS train without the SSH server
    functionality, or running an IOS version supporting SSH but without the
    SSH server enabled are not affected.

    See the Affected Products section for a detailed list of IOS release
    trains that implement the SSH functionality. In particular, the following
    IOS release train do not contain any SSH code:

     * All IOS versions prior to 12.0.
     * IOS 12.0 (mainline - the "S" train is affected.)
     * IOS 12.1 (mainline - the "T" train is affected.)
     * IOS 12.3 (mainline - the "T" train is affected.)

    Cisco IOS XR is not affected.

    No other Cisco products are currently known to be affected by these
    vulnerabilities.

    Details:
    Secure Shell (SSH) is a protocol that provides a secure, remote connection
    to a network device. There are currently two versions of the SSH protocol,
    SSH Version 1 and SSH Version 2, both of which are supported by Cisco IOS.
    The SSH server component of IOS identifies itself as version "1.5" if
    running only version 1.0 of the protocol, as version "2.0" if running only
    version 2 of the protocol, and as version "1.99" if running protocol
    version 2 with fall-back to protocol version 1.

    The SSH server feature of IOS enables a SSH client to make a secure,
    encrypted connection to a Cisco IOS device. This connection provides
    functionality that is similar to a telnet connection with the difference
    that all traffic between the server and the client, including
    authentication information, travels encrypted through the wires.

    TACACS provides a way to centrally validate users attempting to gain
    access to servers, workstations, routers, switches, access servers, and
    other network devices.

    The two vulnerabilities described in this document can cause denial of
    service (DoS) conditions that affect IOS devices configured to use the IOS
    SSH server feature for remote management.

    The first vulnerability may cause a device to reload when the IOS device
    is configured to act as a SSH version 2 server and any of the following
    events occurs:

     * The device is configured to authenticate users against a TACACS+ server
    (via a command like aaa authentication login <group name> group tacacs+
    local) and the account username includes a domain name. Please note that
    the device is not affected if users are being authenticated against a
    RADIUS server or the local user database.
     * A new SSH session is in the authentication phase (the server is waiting
    for a username or password) and another, already logged-in user uses the
    send command.
     * Logging of messages is being directed to a SSH session that is already
    established (through the terminal monitor command) and the SSH session to
    the IOS device terminates while the SSH server is still sending data to
    the client.

    This vulnerability is documented in the Cisco bug ID CSCed65778
    (registered customers only) -- Crash in SSHv2 due to TACACS+ username
    containing domain name.

    Note: this vulnerability affects SSH protocol version 2. SSH protocol
    version 1 is not affected.

    The second vulnerability consists of a memory leak that happens when an
    IOS device is configured to authenticate SSH users against a TACACS+
    server and the login fails due to an invalid username or password. This
    affects both SSH version 1 and version 2 connections. In the case of SSH
    version 2 connections, the memory leak occurs even after a successful
    login. Please note that the device is not affected if users are being
    authenticated against a RADIUS server or the local user database.

    The memory leak can be detected by running the command show tcp brief,
    like in the following example:

    Router#sh tcp brief
    TCB Local Address Foreign Address (state)
    637202B8 10.0.0.19.13294 172.16.112.29.49 ESTAB
    6371C978 10.0.0.19.13233 172.16.112.29.49 ESTAB
    636CB228 10.0.0.19.13041 172.16.112.29.49 CLOSEWAIT
    636B6900 10.0.0.19.12912 172.16.112.29.49 CLOSEWAIT
    63697548 10.0.0.19.12848 172.16.112.29.49 CLOSEWAIT
    63687930 10.0.0.19.12784 172.16.112.29.49 CLOSEWAIT
    635F4A80 10.0.0.19.12659 172.16.112.29.49 CLOSEWAIT

    In the output above, those Transmission Control Blocks (TCBs) in the state
    CLOSEWAIT will not go away and represent memory leaks. Please note that
    only TCP connections with a foreign TCP port of 49 (the well-known port
    for TACACS) are relevant.

    This vulnerability is documented in the Cisco bug ID CSCed65285
    (registered customers only) -- SSH leaks memory and buffers.

    Impact:
    Successful exploitation of the vulnerability described in Cisco bug ID
    CSCed65778 (registered customers only) may result in a reload of the
    device. Repeated exploitation could result in a sustained denial of
    service condition.

    Successful exploitation of the vulnerability described in Cisco bug ID
    CSCed65285 (registered customers only) may result in resource depletion.
    Repeated exploitation could cause a reload of the device, which in turn
    could result in a sustained denial of service condition.

    Software Versions and Fixes:
    A table listing all the vulnerable software versions and their appropriate
    fixes can be found at:
     
    <http://www.cisco.com/warp/public/707/cisco-sa-20050406-ssh.shtml#software> Software Versions and Fixes

    Workarounds:
    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.

    Mitigation Strategies
    Not all of the mitigation strategies listed will work for all customers.
    Some of the workarounds listed are dependent on which versions and
    feature-sets of IOS you have in your network.

    Configuring a VTY Access Class
    It is possible to limit the exposure of the Cisco device by applying a VTY
    access class to permit only known, trusted hosts to connect to the device
    via SSH.

    For more information on restricting traffic to VTYs, please consult:
     
    <http://cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a00800873c8.html#wp1017389> IP Services Commands: access-class Through ip mask-reply.

    The following example permits access to VTYs from the 192.168.1.0/24
    netblock and the single IP address 172.16.1.2 while denying access from
    anywhere else:

    Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255
    Router(config)# access-list 1 permit host 172.16.1.2
    Router(config)# line vty 0 4
    Router(config-line)# access-class 1 in

    Different Cisco platforms support different numbers of terminal lines.
    Check your device's configuration to determine the correct number of
    terminal lines for your platform.

    Configuring Access Lists (ACLs)
    In addition to configuring a VTY Access Class, it may be desirable to
    block all SSH traffic destined to your network infrastructure.

    Telnet and reverse telnet should be blocked as part of a Transit ACL
    controlling all access to the trusted network. Transit 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 "Transit Access Control
    Lists: Filtering at Your Edge" presents guidelines and recommended
    deployment techniques for transit ACLs:
     <http://www.cisco.com/warp/public/707/tacl.html>
    http://www.cisco.com/warp/public/707/tacl.html

    Configuring Infrastructure Access Lists (iACLs)
    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 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" presents guidelines and recommended deployment
    techniques for infrastructure protection ACLs:
     <http://www.cisco.com/warp/public/707/iacl.html>
    http://www.cisco.com/warp/public/707/iacl.html

    Configuring Receive Access Lists (rACLs)
    For distributed platforms, rACLs may be an option starting in Cisco IOS
    Software Versions 12.0(21)S2 for the 12000 series GSR and 12.0(24)S for
    the 7500 series. The receive access lists protect the device from harmful
    traffic before the traffic can impact the route processor. Receive path
    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 CPU load is distributed to
    the line card processors and helps mitigate load on the main route
    processor. The white paper entitled "GSR: Receive Access Control Lists"
    will help identify and allow legitimate traffic to your device and deny
    all unwanted packets:
     <http://www.cisco.com/warp/public/707/racl.html>
    http://www.cisco.com/warp/public/707/racl.html

    Control Plane Policing
    The Control Plane Policy (CoPP) feature may be used to mitigate this
    vulnerability, as in the following example:

    ! Do not police SSH traffic from trusted hosts
    access-list 140 deny tcp host <trusted host 1's IP address> any any eq
    22
    access-list 140 deny tcp host <trusted host 2's IP address> any any eq
    22
    [...]
    access-list 140 deny tcp host <trusted host N's IP address> any any eq
    22
    ! Trust an entire network if desired
    access-list 140 deny tcp <trusted network address> <trusted network
    mask> any eq 22
    ! Police SSH traffic from untrusted hosts
    access-list 140 permit tcp any any eq 22
    ! Do not police any other type of traffic going to the router
    access-list 140 deny ip any any
    !
    class-map match-all ssh-class
      match access-group 140
    !
    policy-map control-plane-policy
      ! Drop all traffic that matches the class "icmp-class"
      class ssh-class
         drop
    !
    control-plane
      service-policy input control-plane-policy

    Note: CoPP is available only in IOS release trains 12.0S, 12.2S and
    12.3T. Additional information on the configuration and use of the CoPP
    feature can be found at the following URL:
    <http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a00801afad4.html> Control Plane Policing

    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-20050406-ssh.shtml>
    http://www.cisco.com/warp/public/707/cisco-sa-20050406-ssh.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: "[NT] Ublog Multiple Vulnerabilities (Cross Site Scripting, Database Disclosure)"