Home / Cisco Security / Security Advisories

Cisco Security Advisory

Cisco uBR10012 Series Devices SNMP Vulnerability

Critical
Advisory ID:
cisco-sa-20080924-ubr
First Published:
2008 September 24 16:00 GMT
Version 1.1:
Final
Workarounds:
See below
Cisco Bug IDs:
CSCek57932
CSCsg60220
CVE-2008-3807
CWE-264
CVSS Score:
Base 10.0, Temporal 8.3Click Icon to Copy Verbose Score
AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE-2008-3807
CWE-264

Summary

Affected Products

  • Vulnerable Products

    Cisco uBR10012 series devices that are running Cisco IOS and configured for linecard redundancy are affected. Cisco uBR10012 series devices can be identified by issuing the show version command. The following example shows output from a Cisco uBR10012 series device running Cisco IOS software release 12.3(17b)BC7:

    ubr10k#show version | include IOS
IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC7, RELEASE SOFTWARE (fc1)
ubr10k#

    Please refer to the document entitled "White Paper: Cisco IOS Reference Guide" for additional information on the Cisco IOS release naming conventions. This document is available at the following link: http://www.cisco.com/warp/public/620/1.html

    A Cisco uBR10012 series device configured for linecard redundancy will have a line similar to the following in the output of show running-config command:

    member subslot / working

    or 

    hccp  protect

    Any version of Cisco IOS prior to the versions listed in the Software Versions and Fixes section below is vulnerable.

    Products Confirmed Not Vulnerable

    Cisco uBR10012 series devices that are not configured for linecard redundancy are not affected.

    Cisco 10000 series devices are not affected even if they are configured for linecard redundancy.

    Other uBR platforms are not affected.

    No other Cisco products are currently known to be affected by this vulnerability.

Details

  • Cisco uBR10012 series devices need to communicate with an RF Switch when configured for linecard redundancy. This communication is based on SNMP (Simple Network Management Protocol). When linecard redundancy is enabled on a Cisco uBR10012 series device, SNMP is also automatically enabled with a default community string of private that has read/write privileges. Since there are no access restrictions on this community string, it may be exploited by an attacker to gain complete control of the device.

    Changing the default community string, adding access restrictions on SNMP or doing both will mitigate this vulnerability. The recommended mitigation is to do both.

    This vulnerability is documented in the Cisco Bug ID CSCek57932 ( registered customers only) and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3807.

Workarounds

  • Changing SNMP community string and restricting access

    By default, Cisco uBR10012 series devices that are configured for linecard redundancy use a community string of private. This community string can be changed in Cisco IOS versions 12.3(13)BC and later. It is recommended to change the community string and apply access control restrictions that only permit authorized devices SNMP access to the device.

    The following configuration example provides operators with information on changing the community string and adding SNMP access control restrictions using an access control list (ACL).

    access-list 90 permit host 
access-list 90 permit host 
access-list 90 permit host 
access-list 90 deny any

redundancy
  linecard-group 1 cable
    rf-switch snmp-community 

snmp-server community  rw 90

    When the SNMP community is changed on a Cisco uBR10012 device, is must also be changed on the RF Switch. It can be changed by the following command: 

    set SNMP COMMUNITY

    If there is an up-converter in the network, the SNMP community used by the up-converter must also be changed after changing the community string on the Cisco uBR10012 device. Information on changing the community string used by the up-converter can be found at the following link:

    http://www.cisco.com/en/US/tech/tk86/tk804/technologies_tech_note09186a00801f7622.shtml#communication

    If the Cisco IOS version does not support changing the community string, access control restrictions can be applied to the default community string. The following configuration example provides operators with information on applying access control restrictions to the default community string. 

    access-list 90 permit host 
access-list 90 permit host 
access-list 90 permit host 
access-list 90 deny any

snmp-server community private rw 90

    Using Infrastructure ACLs at Network Boundary

    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. iACLs are 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 iACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: 

    
!-- Permit SNMP (UDP port 161) packets from trusted hosts
!-- destined to infrastructure addresses.

!
access-list 150 permit udp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 161
!

!-- Deny SNMP (UDP port 161) packets from all other sources
!-- destined to infrastructure addresses.

!
access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES MASK eq 161
!

!-- Permit/deny all other Layer 3 and Layer 4 traffic in
!-- accordance with existing security policies and
!-- configurations.

!

!-- Permit all other traffic to transit the device.

!
access-list 150 permit ip any any
!

!-- Apply iACL to interfaces in the ingress direction.

!
interface GigabitEthernet0/0
  ip access-group 150 in
!

    The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here:

    http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

    Additional Mitigation Techniques

    Additional mitigation techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link:

    https://sec.cloudapps.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20080924-ipc-and-ubr

Fixed Software

Exploitation and Public Announcements

  • The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory.

    This vulnerability was found internally.

Cisco Security Vulnerability Policy

  • To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

Action Links for This Advisory

Related to This Advisory

URL

Revision History

  • Revision 1.1

    2009-April-16

    Removed references to the combined software table, as it is now outdated.

    Revision 1.0

    2008-Sep-24

    Initial public release.

    Show Less

Cisco Security Vulnerability Policy

  • To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

Action Links for This Advisory

Related to This Advisory