Cisco Industrial Ethernet 3000 (IE 3000) Series switches running Cisco IOS® Software releases 12.2(52)SE or 12.2(52)SE1, contain a vulnerability where well known SNMP community names are hard-coded for both read and write access. The hard-coded community names are "public" and "private." Cisco recommends that all administrators deploy the mitigation measures outlined in the Workarounds section or perform a Cisco IOS Software upgrade. Cisco has released software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20100707-snmp.
Cisco Industrial Ethernet 3000 (IE 3000) Series switches running Cisco IOS® Software releases 12.2(52)SE or 12.2(52)SE1, contain a vulnerability where well known SNMP community names are hard-coded for both read and write access. The hard-coded community names are "public" and "private."
Cisco recommends that all administrators deploy the mitigation measures outlined in the Workarounds section or perform a Cisco IOS Software upgrade.
Cisco has released software updates that address this vulnerability.
Workarounds that mitigate this vulnerability are available.
This advisory is posted at http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20100707-snmp.
The following product is affected by this vulnerability:
The Cisco Industrial Ethernet 3000 Series switches are vulnerable when running any of the following Cisco IOS Software releases:
No other Cisco products are currently known to be affected by this vulnerability.
Other hardware models of Cisco switching products that are running the vulnerable Cisco IOS Software versions are not affected by this vulnerability.
Cisco Industrial Ethernet 3000 Series switches that are not running the Cisco IOS Software releases that is listed above are not vulnerable.
Cisco Industrial Ethernet 3000 Series switches that are running affected versions of Cisco IOS Software contain hard-coded SNMP read-write community names.
The Cisco Industrial Ethernet 3000 Series is a family of switches that provide a rugged, easy-to-use, secure infrastructure for harsh environments.
SNMP is used for managing and monitoring the device and community names are the equivalent to a password.
The hard-coded SNMP community names are:
snmp-server community public RO snmp-server community private RW
The SNMP community names can be removed; however, the hard-coded community names are reapplied to the running configuration when the device reloads. Cisco has provided a workaround that ensures the community names are removed when the device reloads.
Note: Configuring an access list or a restricted mib view:
snmp-server community public RO 99 snmp-server community private RW 99 snmp-server community public viewRO 99 snmp-server community private view RO 99 access-list 99 deny any
The proceeding works as a workaround until the device is reloaded. Once the device is reloaded the original configuration is inserted without the access lists or mib views assigned to the community names. Consult the workarounds section of this advisory.
This vulnerability was introduced as part of a new feature integrated into the affected releases called PROFINET. At the time of the publication of this advisory, PROFINET was only supported on Cisco Industrial Ethernet 3000 Series switches.
This vulnerability is documented in the Cisco Bug ID CSCtf25589 ( registered customers only) . This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-1574.
Manually Remove SNMP Community Names
Note: The following workaround is only effective until the device is reloaded. Upon each reload of the device this workaround must be re-applied. Cisco encourages performing a Cisco IOS Software upgrade as a permanent fix for this vulnerability.
Log in to the device, and enter configuration mode. Enter the following configuration commands:
no snmp-server community public RO no snmp-server community private RW
Saving the configuration will update the start-up configuration files; however the hard-coded community names will be reinserted to the running configuration when the device reloads. This workaround must be applied each time the device is reloaded.
Automatically Remove SNMP Community Names
By creating an Embedded Event Manager (EEM) policy, it is possible to automatically remove the hard-coded SNMP community names each time the device is reloaded. The following example shows an EEM policy that runs each time the device is reloaded and removes the hard-coded SNMP community names.
event manager applet cisco-sa-20100707-snmp event timer countdown time 30 action 10 cli command "enable" action 20 cli command "configure terminal" action 30 cli command "no snmp-server community public RO" action 40 cli command "no snmp-server community private RW" action 50 cli command "end" action 60 cli command "disable" action 70 syslog msg "Hard-coded SNMP community names as per Cisco Security Advisory cisco-sa-20100707-snmp removed"
For more information on EEM policies consult the Cisco IOS Network Management Configuration Guide - Embedded Event Manager Overview at the following link: http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_overview_ps6441_TSD_Products_Configuration_Guide_Chapter.html.
Infrastructure Access Control Lists
Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the device interface or the border of networks.
If SNMP management is not required on the IE3000, then dropping all SNMP traffic to the device is a sufficient workaround. The iACL below shows an example of an IE3000 with two interfaces configured with layer 3 access, dropping all SNMP queries destined to the IE3000:
!--- !--- Deny SNMP traffic from all other sources destined to !--- configured IP addresses on the IE3000. !--- access-list 150 deny udp any host 192.168.0.1 eq snmp access-list 150 deny udp any host 192.168.1.1 eq snmp !--- !--- 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 access-list to all Layer 3 interfaces !--- (only two examples shown) !--- interface Vlan1 ip address 192.168.0.1 255.255.255.0 ip access-group 150 in interface GigabitEthernet1/1 ip address 192.168.1.1 255.255.255.0 ip access-group 150 in
The white paper "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 at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml.
When considering software upgrades, consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution.
In all cases, customers should exercise caution to ensure the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance.
Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release specified in the "First Fixed Release" column of the table.
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory.
This vulnerability was discovered when handling customer support calls.
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.
|
Revision 1.0 |
2010-July-07 |
Initial public release. |
THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.
A stand-alone copy or paraphrase of the text of this document that omits the distribution URL is an uncontrolled copy, and may lack important information or contain factual errors. The information in this document is intended for end-users of Cisco products.
Vulmon