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