Security Problem in Cisco ubr900 Series Routers
Author - Cushman
Publisher - HNC Network
Date - Thursday, 3rd January - 4:26am
URL - 
http://www.hack-net.com/media/news/?viewArticle=3Dyes&articleID=3D199913001

--- Originally released by the HNC Network ---

First of all, thank you for the opportunity to write for
HNC. This potential vulnerability surfaced while performing a
network security audit for a client. The router in question is
a Cisco ubr925, but further tests revealed that this also worked
for the ubr920 and the ubr924. I did an SNMP sweep of this router,
and eventually the others, and discovered that no matter what SNMP
community name I used, I could get read-write access to the MIB,
and eventually access to the IOS config. Most of the routers had
these lines in their config:

snmp-server community hardtoguess RO
no snmp-server ifindex persist
snmp-server manager

However, not once did I ever use the 'hardtoguess' community
name. Please also note that this config does not have a read-write
community name set. The image file name for the ubr925 is:

ubr925-k1sv4y556i-mz.121-3a.XL1

but once again, please let me note that this is just from one of the
routers tested. On a side note, using 'sh snmp comm', these routers
also had the well documented 'cable-docsis' SNMP community. To verify
the validity of this problem, and to keep from getting mega-flamed, I
had several different people, including one from HNC, test this to be
sure. This was tested on several routers, all in production, from
several different programs on different operating systems, all from
different networks and locations. The results were all the same.

Like a good hacker, I immediately notified Cisco's PSIRT,
and tried to get some others in Cisco to escalate it. Even though
I still stand by and defend Cisco and their wonderfully made routers,
I was rather disappointed by their reply, 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 ...

(this portion deleted for brevity, and to save someone's butt other than 
my own)

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 
modifications* (spelling corrected) to its products.

*- - - end of response - - -*

Anyhow, correct me if I am wrong, but this seems to say that during
testing and/or installation phase, any community name can be used,
and then once the DOCSIS config has been implemented, the snmp-server
commands in the Cisco IOS config take over. Let me remind you that
these were routers already being used by clients, and configured by
network engineers employed by the ISP.

Disclaimer: This problem may be unique to this set of routers, or
this specific configuration, although evidence points
to the contrary. No slander, libel, or defamation of
any kind is intended toward Cisco or Cablelabs.

Since this is my first post, I'd like to send out greets to
ShizNiz, vac, stucc0, RLoxley, teeceep, stopper, [t]hief, Electro-,
and all the rest at #hackphreak on Undernet, where you'll usually
see me idling. Happy New Year!

http://www.hack-net.com/media/news/?viewArticle=3Dyes&articleID=3D199913001