Security Hole In SNMP

wiredog writes: "From ZDNET comes the news that there is apparently a serious security flaw in the Simple Network Management Protocol, used to control routers and other network devices." An anonymous reader points to the CERT advisory as well.

Comments

Not much scanning for it yet.

[UnderAttack]

So far, DShield does not have too much scanning for it yet (data).
But I guess the kiddies are still sharpening the tools...

FreeBSD may be vulnerable...

[NewbieSpaz]

If you're running FreeBSD check on this:
FreeBSD has issued the following FreeBSD Security Advisory regarding the UCD-SNMP / NET-SNMP package:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisorie s/ FreeBSD-SA-02:09.snmp.asc.

From patches to kings

[caferace]

Seeing as how CERT was aware of this last summer, and has been working with vendors (ALL the big names) to get it corrected at least we can hope that the patches are available.

Getting them installed may be a different story. There are probably a lot of "forgotten" SNMP devices out there...

I thought SNMP was a security hole...

[mumblefish]

How many other protocols tell you "That's the wrong password, try this one ...".
It's probably changed since I last worked with it, but it just looked kindof funny.

matt

Re:I thought SNMP was a security hole...

[fiber_halo]

It hasn't worked that way for a long time, but here's what used to happen in some implementations:

- Send an SNMP set or get to a box. Use any ol' random community string.
- The box then sends an SNMP trap to its management station which contained the cleartext real community string.

If you had a packet sniffer, you could easily get the community string. I don't remember offhand if the trap contained the read-only or read-write string, but still, either way, I don't want a device doing that.

That was a long time ago. I can't imagine any devices still have such a hole unless they haven't been upgraded in years.

Not a SNMP hole

[Anonymous Coward]

This is a security hole in many implementations of SNMP, not in the protocol itself. This means that products can be patched without switching to a new protocol. Of course, SNMP devices will still be insecure if you don't change the default community strings (and even then, SNMPv1 sends the strings in plaintext).

Re:Not a SNMP hole

[Quill_28]

Actually this is first post that has made any sense. The problem in not with the SNMP protocol, but rather the software that implemented SNMP. This means the one hack(crack) will effect net-snmp but not MS's crappy agent and vice-versa. btw security problems with the SNMP protocol have been addressed in SNMPv3. Also, in most cases the only thing the crackers can do is shut the box down. I know DoS is a big deal, but taking over a router is bigger.

Re:Not a SNMP hole

[tqbf]

If this was a hole in an SMTP server it would make sense to say that it's specific to the server. Because the protocol in question in SNMP, it is NOT valid to make this assumption. Virtually all implementations of SNMP trace a lineage back to a common, ancient implementation.

The reason for this is that SNMP uses an incredibly complicated wire format: ASN.1/BER. ASN.1/BER is based on the (once seductive) idea that you could avoid interoperability and extensibility problems by (in effect) defining a programming language to encode and decode data structures. As long as you implement the primitives of the language, third parties can implement arbitrarily complex constructs on top of the protocol without changing your code.

The reality, of course, is that almost all queries fit into a tiny subset of the "language", and that the "language" itself is so complicated to implement (relative to other protocols) that nobody is willing to "reinvent the wheel".

So they all downoad the (free) CMU or UCD SNMP library and use that.

Hence, everyone is vulnerable.

Re:Not a SNMP hole

[tqbf]

Nobody uses SNMPv3.

Nobody uses SNMPv2

Everyone uses SNMPv1

People will ALWAYS use SNMPv1. Nobody will set up a new authentication infrastructure just for SNMP. They will build ad-hoc backchannels to isolate SNMP from the rest of the Internet. They will fail repeatedly, but it won't be nearly as expensive as deploying an entire new security infrastructure for network management.

This is the same reason why nobody will ever use DNSSEC, and why everyone uses SSH. SSH did the simplest thing possible and left the infrastructure up to the consumers. DNSSEC and SNMPvNG repeatedly fucked this simple problem up by trying to mandate more of the environment than was required to get off the ground.

Re:What is the flaw?

[richw]

Looks to me like there's a pretty complete analysis of the flaws on the CERT page linked to in articlie

End of email from SANS...

[heliocentric]

Turning off SNMP was one of the strong recommendations in the Top 20 Internet Security Threats that the FBI's NIPC and SANS and the Federal CIO Council issued on October 1, 2001. If you didn't take that action then, now might be a good time to correct the rest of the top 20 as well as the SNMP problem. The Top 20 document is posted at http://www.sans.org/top20.htm

Re:End of email from SANS...

[klieber]

Did you even bother to read the CERT advisory?

"As a general rule, the CERT/CC recommends disabling any service or capability that is not explicitly required, including SNMP. Unfortunately, some of the affected products exhibited unexpected behavior or denial of service conditions when exposed to the OUSPG test suite even if SNMP was not enabled. In these cases, disabling SNMP should be used in conjunction with the filtering practices listed below to provide additional protection. "

Re:What is the flaw?

[kindbud]

Once again a security flaw is found, but nobody tells anyone what the security flaw is.

Bullshit:

http://www.kb.cert.org/vuls/id/107186
http://www.kb.cert.org/vuls/id/854306

These are linked to on the first page of the CERT Advisory. RTFA, doofus.

Re:Alternatives

[stinky wizzleteats]

SNMP is well known to be a security problem (at least in the networking community). The answer is to cut all of it off at your firewall, and make sure your internal networks are zoned appropriately. The best way to deal with it right now is to put all your equpiments' management addresses in a management VLAN, of which none of the user ports are members, and then control access to it via the router you'll use to get to the VLAN.

Re:SNMP's a pretty damned scary protocol anyway

[Quill_28]

Ever heard of SNMPv3?

Wrong summation (again).

[hardaker]

The security flaw is not in the protocol, but rather in how people and companies have implemented it. Unfortunately, most people did in fact implement it in such a way that makes the products vulerable to crashing and /or buffer-overflow attacks. A good portion of the SNMP code to date is written based on early work from the cmu-snmp package, which was a reference release of the protocol. Hence, many of the companies and products that make use of that original code (including ucd-snmp and net-snmp, which I'm the lead developer for) are subject to the vulnerabilities as well. The ucd-snmp and net-snmp packages have been fixed as of a few months ago (and upgrading software is easy on linux, *bsd, etc boxes). However, people with flashroms containing software will have a much more challanging time getting updates from their vendors and installing them in a quick fashion if the deployment numbers of those types of boxes are large.

Re:What is the flaw?

[Florian Weimer]

Obviously, you have never read such notes, otherwise you would now that CERT/CC never releases information which can be used to reproduce problems. They do point to the problems, but do not provide details. (Most of the time, you can guess the concrete problem, though.)

In fact, there are several different buffer overflow and format string bugs, in different SNMP implementations. The OUSPG report (which triggered this advisory) seems to be more detailed, but I still have to read it. (OTOH, SNMP vulnerabilities are rather boring stuff nowadays, any sane person blocks SNMP at the closest router.)

Re:Alternatives

[gmack]

This is why I've always tended to run snmp on a non routable address block. It's saved me a few times.

Updated story on cnet's news.com and some links

[wavelet]

http://news.com.com/2100-1001-835602.html

To mitigate this vulnerability OULU (the guys that found this a year ago) has some good links at http://www.ee.oulu.fi/research/ouspg/protos/testin g/c06/snmpv1/

Securing SNMP on Solaris
http://ist.uwaterloo.ca/security/howto/2000-10-04/
Securing SNMP in Windows
http://www.sans.org/infosecFAQ/incident/SNMP.htm
Securing your Cisco Router when using SNMP
http://www.sans.org/infosecFAQ/netdevices/router.h tm
SNMP - simple management tool for hackers?
http://www.nwfusion.com/newsletters/sec/1004sec1.h tml
Windows 2000, SNMP and Security
http://www.securityfocus.com/focus/microsoft/2k/sn mp.html

Re:Bogus release number for SNMP Research?

[Steve Moulton]

Sure, I've a clue.

15.2.1.7 is a release that shipped for nearly
a year on some operating systems up to October
of 2001. We started shipping 15.3 in July, and
15.3.1.7 is the release that has changes
addressing the OUSPG-related issues, which started
shipping in October.

The 15.3.1.7/15.2.1.7 release number similarity
is an unfortunate accident - had I thought
about it we might have done it differently.

Those evil Microsoft d00ds

[Zico]

You'll notice that Microsofts response was to turn off the SNMP service until they get a patch ready.

Yeah, those bastards. Why can't they do things like the following model citizens?

• Red Hat: "Red Hat Inc. has investigated this vulnerablity, and currently has a candidate fix which is undergoing regression testing. Updated ucd-snmp packages incorporating this fix will be available shortly from this page shortly."
• Sun Microsystems: "Sun is currently generating patches for this issue and will be releasing a Sun Security Bulletin once the patches are available."
• Caldera: "A fix for supported versions of OpenServer 5 will be available at a later date."
• SGI: "SGI acknowledges the SNMP vulnerabilities reported by CERT and is currently investigating. No further information is available at this time."
• Cisco: "Cisco Systems is addressing the vulnerabilities identified by VU#854306 and VU#107186 across its entire product line."
• Netscape: "As a result, we have created fixes which will resolve the issues, and these fixes will appear in future releases of our product line. To Netscape's knowledge, there are no known instances of these vulnerabilities being exploited and no customers have been affected to date."
• Lucent: "Fixes for the rest of the affected product portfolio will be available shortly."
• HP: "Patches in process. Watch for the associated HP Security Bulletin."
• Novell: "The SNMP and SNMPLOG vulnerabilities detected on NetWare are fixed and will be available through NetWare 6 Support Pack 1 & NetWare 5.1 Support Pack 4. [None of which are available yet.]"
• Compaq: "At the time of writing this document, COMPAQ continues to evaluate this potential problem and when new versions of SNMP are available, COMPAQ will implement solutions based on the new code."
• Redback Networks: "Redback Networks, Inc. has identified that the vulnerability in question affects certain versions of AOS software on the SMS 500, SMS 1800, and SMS 10000 platforms, and is taking the appropriate steps necessary to correct the issue."
• Network Computing Technologies: "Network Computing Technologies has reviewed the information regarding SNMP vulnerabilities and is currently investigating the impact to our products."
• DMH Software: "It is unclear at this point if our snmp-agent is sensitive to the tests described above."
• Avaya: "Avaya Inc. acknowledges the potential of SNMP vulnerabilities and is currently investigating whether these vulnerabilities impact Avaya's products or solutions. No further information is available at this time."
• AdventNet: "The release of AdventNet Inc's. Service Pack correcting the behavior outlined in VU#617947, and OUSPG#0100 is scheduled to be generally available to all of AdventNet Inc.'s customers by February 20, 2002."

There is not secret

[RobertGraham]

The advisories contain a link to a tool that will test the vulnerability. There are no secrets being kept, it's all out in the open. The problem is that no "easy-to-use" tool has been created (except for checks that have been added to scanners).

Re:We're getting hit hard

[Anonymous Coward]

And this has to do with SNMP how?

Re:CERT Considered Harmful.

[ryanr]

According to ZDNet, this vulnerability was reported to CERT by a research team one year ago. It was only today announced in an advisory. CERT maintained a multiple-month window of time to suppress the advisory.

And yet, looking at the advisory, the most important vendors don't yet have patches . In particular, Microsoft, Cisco, and Sun remain vulnerable, with no released patches!

The entire rationale behind keeping vulnerabilities quiet is to enable vendors to fix the problem before the exploit falls into the hands of attackers. The entire rationale behind CERT's very existance is to act as a clearinghouse for vulnerabilities so that fixes can be coordinated prior to announcements. Virtually every credible security researcher has repeatedly exclaimed that CERT's model doesn't work. I can't imagine a clearer vindication for CERT's critics than this.

Not that I'm trying to validate CERT's model mind you...

They were somewhat forced into releasing today. There was a leaked early version of the advisory (with no details) that had a release date of February 20th. Details were spilling out from various sources. Given how many patches were announced today after the advisory, it's safe to say that those vendors must have been pretty close to being ready.

It also demonstrates that it's not possible to try and give that many vendors that much warning, and not have leaks.

we are seeing SNMP scans

[chongo]

We have seen SNMP scans at a rate of about 17 per 4 hours (~6/hr) as of 2300 PST. The rate has been steady for the past 23 hours. One would expect the scan rate to increase as the exploit tool gets into the hands or more script kids. Prior to this week it was rare for someone to probe the SNMP ports.

The scans are talking the IP address space in pseudo-random order. It appears to hold the top 16 bits constant while walking the lower 16 in a pseudo-random order. We have not seen simple SNMP scans that just walk up the IP address range.

It appears that the tool is initially just looking for open SNMP ports. The tool could be simply collecting open SNMP ports for later system cracking.

Old News. But it does bring up other issues..

[TeddyR]

The problems with SNMP mentioned here is actually OLD NEWS for any system administrator that can spell his/her job title. I know we came across this issue well over a year ago, with emails to those concerned that were not answererd, or were answered with "That how its supposed to work..."...

I, and most admins I know will completely block SNMP at the border routers (only allowed in through an IPSEC or VPN connection.). I used to have a simple demonstration of how "evil" unportected SNMP could be by showing admins just WHAT kind of info their SNMP enabled switches/routers haapilly gave out.. (quick hint: if u have the snmp tools in linux:

snmpwalk {ip address of any SNMP enabled cisco device} public

And watch as a list of the devices ARP tables shows you exactly which ports have which devices, as well as the routing table for the device and all sorts of info that any snoop can use to help them build a better picture of how the network is configures... [in fact, Fluke makes a software product called Network Inspector that uses the SNMP data from switches among other things to build a full network map including stuff to show things like exactly which switch port a device is on as well as the distance between two devices and how a packet IN THE SWITCH ENVIRONMENT travels from one device to another]

http://www.flukenetworks.com/us/LAN/Monitoring+A na lysis+Diagramming/Network+Inspector/Overview.htm

The other real issue that this brings up is what about the implementations of OTHER protocols like syslog? How many vendors use the same BASE code that may require a patch in flash as a firmware update?...