Return-Path: <kretch@MIT.EDU>
Received: from grand-central-station.mit.edu by po12.mit.edu (8.9.2/4.7) id PAA21503; Fri, 16 Mar 2001 15:40:19 -0500 (EST)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA13755 for <network@MIT.EDU>; Fri, 16 Mar 2001 15:37:42 -0500 (EST)
Received: from mission-control.mit.edu (MISSION-CONTROL.MIT.EDU [18.18.0.100]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22411 for <network@MIT.EDU>; Fri, 16 Mar 2001 15:37:42 -0500 (EST)
Received: (from kretch@localhost) by mission-control.mit.edu (8.9.3) id PAA09274; Fri, 16 Mar 2001 15:37:42 -0500 (EST)
Message-Id: <200103162037.PAA09274@mission-control.mit.edu>
To: network@mit.edu
Subject: Cisco SNMP vulnerabilities and us
Organization: Massachusetts Institute of Technology
X-Uri: <URL:http://web.mit.edu/kretch>
Date: Fri, 16 Mar 2001 15:37:42 -0500
From: "James M. Kretchmar" <kretch@MIT.EDU>
X-Evolution: 000000db-0000

Ok, here's the lowdown on the Cisco SNMP vulnerabilities.  There
turned out to be four separate problems, only two of which applied to
us.

One (the problem I'll call the RW problem) is that you can use the RO
community to query the router for the RW community name.  This has
obvious bad implications.

The second (the problem I'll call the "ILMI" problem) is that you can
use a specific community name (ILMI :) set certain SNMP variables.
The variables you can set include the variables in the system group
(system.sysLocation etc) and variables in a certain ATM group.
There's nothing in the system group that will cause any kind of outage
if changed, it would just be slightly embarrassing.  The variables in
the ATM group, if changed, could actually affect service to any ATM
interfaces.

(For the curios, the other two problems were an unexpected RO
community name and another unexpected RW community name with access to
*every* writable variable.  The RO we don't care about since we're
using public anyway, the RW doesn't affect any versions of IOS we're
running).

Here's what was vulnerable to what:

                           RW           ILMI
       ----------------------------------------------------
       internal core    |  ok           VULNERABLE
       vbns-rtr         |  VULNERABLE   VULNERABLE
       w92-rtr-1        |  ok           ok
       - - - - - - - - -|- - - - - - - - - - - - - - - - -
       ILG's	        |  ok           ok
       remote sites     |  ok           NE20 VULNERABLE
       - - - - - - - - - - - - - - - - - - - - - - - - - -
       entry sw's       |  ok           ok

The big nasty one was vbns-rtr being vulnerable to getting the SNMP RW
community, which I was able to do actually do.

Here's where things stand in terms of fixes:

I did a temporary fix to the vbns-rtr RW problem by removing the RW
community and reloading the router.  The "right" fix is to take the
next maintenance release, 12.0(16)S, which comes out on Monday.  This
also turns out to be the best available fix for the ILMI problem on
vbns-rtr.  This means that until Monday or Tuesday night we'll be
without a RW community on vbns-rtr (no big deal) and (because of the
"I" problem) the ATM interface could be vulnerable to an outage (which
is a bigger deal, but the best course of action is still to wait for
the upgrade).

The fixes for the ILMI problem on the internal core routers, and
ne20-rtr is unfortunately a little lame.  It's to config:

	 no snmp-server view *ilmi

The thing that's lame about it is that it won't survive a reload of
the router. (This is because IOS considers the no form of this command
to be a default so it doesn't bother storing the line in the config).
There's not much we can do about it, but it also doesn't matter much.
The worst that can happen is a router reboots and we forget to enter
the command again and someone changes the sysContact.  Oh well.  I'm
looking into the next version of IOS we want for our core routers
(more for other reasons than this) and I'll make sure that upgrade
also takes care of this problem.

So that leaves us with:

                           RW           ILMI
       ----------------------------------------------------
       internal core    |  ok           fixed as far as we care
       vbns-rtr         |  temp-fix	UPGRADE
       w92-rtr-1        |  ok           ok
       - - - - - - - - -|- - - - - - - - - - - - - - - - -
       ILG's	        |  ok           ok
       remote sites     |  ok           fixed as far as we care
       - - - - - - - - - - - - - - - - - - - - - - - - - -
       entry sw's       |  ok           ok

At some point soon I'm going to chance the enable password and write
community since they were publicly available for a while.  I'll
coordinate this with folks, of course.

(Random data that Tom wanted follows at the end)

kretch

http://www.cisco.com/warp/public/707/ios-snmp-ilmi-vuln-pub.shtml
http://www.cisco.com/warp/public/707/ios-snmp-community-vulns-pub.shtml

A unexpected RO community added
	we don't care
B RW community exposed by RO walk of VACMIB
	CSCds32217
	CSCds19674 (cat)
	Most IOS releases in 12.0 (after 12.0(3)T) as well as most
           12.1 releases contain this vulnerability,
           and CatOS releases 5.4(1) - 5.5(2) and 6.1(1)
C RW cable-docsis
	CSCdr59314
	limited range of IOS releases based on 12.1(3) and 12.1(3)T,
          and it is fixed in 12.1(4) and 12.1(5)T
X RW "ILMI" can write to system group, LAN-EMULATION-CLIENT, PNNI MIB.
	CSCdp11863
	latter two groups affect ATM
