Date: 30 Dec 2001 16:14:32 -0000
From: [email protected]
To: [email protected]Subject: Possible security problem with Cisco ubr900 series routers
Problem: RW access to the MIB, and eventually
access to the router config, using ANY (yes, ANY)
community name.
The following routers were tested:
ubr920, ubr924, ubr925
image file for the ubr925 is as follows:
ubr925-k1sv4y556i-mz.121-3a.XL1
snmp-server commands used in each router config,
not just the ubr925:
snmp-server engineID local 0000000...(the rest)
snmp-server community hardtoguess RO
no snmp-server ifindex persist
snmp-server manager
These SNMP community names are just a few of the
many used:
xyzzy
agent_steal
freekevin
fubar
Notice, that not once, was the RO community name
of 'hardtoguess' used, and there was no mention in
the config of any RW string. A 'sh snmp comm'
turned up only the RO name, as well as the widely
documented 'cable-docsis' problem.
Notice that no RW community is set. Several routers
were tested. Solarwinds Network Browser was used,
as well as the snmpset/snmpget/snmpwalk tools
available in Linux. Tests were done from different
machines, using several different OS'es, and these
machines being placed on several different networks.
Cisco PSIRT was contacted, and also a local cable
provider, where it was determined that this provider
definitely uses the same make and model of routers.
The cable company responded only to the second
part of the message, which was a request for
prices of business-grade cable service. The
response from Cisco was as follows:
This behaviour in SNMP access is due to DOCSIS
1.0 standards which
specifies that by default, there is no restrictions on
SNMP access to
the device. Cisco has to comply with DOCSIS
standards in order to
produce a CableLabs certified product. Cisco has
tried very hard to
convince Cablelabs that their approach is wrong, but
have had no
success. Cablelabs standards provides a
mechanism (via a DOCSIS config
file) to automatically configure SNMP access list as
the device attaches
to the network. It is assumed (by Cablelabs) that
prior to this time,
security is not critical since the device gets its
configuration (via
the DOCSIS config file) before anyone can do any
harm.
The document is TP-OSSI-ATPv1.1-I01-011221.
The specific is on 2.1.7 CM Network management
Access and SNMP
Co-existence (OSS-07.1), 1 Default Access.
It is on page OSS-7.1 page 3 of 11.
It states "The Default Access test verifies the CM
agent supports full
SNMP access from an NSI side NMS and from a
CPE side NMS after the CM
completes registration with the basic1.cfg
configuration file. The term
"Default Access" implies no
docsDevNmAccessTable row and no SNMPv3
configuration was supplied to the CM. Any SNMP
read and any SNMP write
community string can be used for this test, since
compliant CMs will
allow open access in the Default Access condition."
This document is available from Cablelabs at
http://www.cablemodem.com/ .
The docsis spec has explicit requirements about the
implementation and
it modifies what is mentioned in RFC2669. It is also
explicitly stated
that it overrides the RFC should any conflict arises.
Cisco's
implementation has been certified by CableLabs
multiple times.
Once Cablelabs changes its requirement Cisco
would make the mdifications
to its products.
----end of response from Cisco------------------
I may be wrong, but it seems to me that a
cablemodem or cablerouter being used already
out on the internet, would already have loaded
the DOCSIS config file, and thus the SNMP
access would depend only on the snmp-server
commands entered into the IOS config.
Possible workaround would be to create a specific
RW community name, and make it accessible only
from a machine on the internal network, or to stop
using SNMPv1 altogether, or not to use SNMP at all.
At this time, I have not tested any of these potential
solutions.
Regards,
Scott
Security Secrets
Wichita, KS
