Slashdot Mirror
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.
So far, DShield does not have too much scanning for it yet (data).
But I guess the kiddies are still sharpening the tools...
---- join dshield.org Distributed Intrusion Detec
This appears to be quite serious... check out the list of vendors: http://www.cert.org/advisories/CA-2002-03.html#ven dors
It includes Cisco, Microsoft, HP, Sun, Novell, and many others. When it comes to SNMP bugs, it would seem that most vendors are created equal.
Natural != (nontoxic || beneficial)
Getting them installed may be a different story. There are probably a lot of "forgotten" SNMP devices out there...
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
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).
Who's in charge of Acronyms around here? It's not an SMTP problem!
"You are not a beautiful and unique snowflake."...Tyler Durden
Disabling SNMP doesn't close the SNMP hole, in some cases. Apparently, the hole may be in SNMP itself.
Best Slashdot Co
What do you expect from a protocol named Security's Not My Problem?
Looks to me like there's a pretty complete analysis of the flaws on the CERT page linked to in articlie
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
Wheeeee
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.
Edith Keeler Must Die
Even without the aforementioend flaws (whatever they are), SNMP is a truely horrible protocol. The only real security in most implementations is based on IP Address and SNMP Domain Name. Most network devices will be "polite" with their IP addresses (especially when DHCP is enabled), so taking over an IP address is rarely a problem (assuming IP spoofing doesn't suit your needs). And the Domain Name is rarely difficult to brute-force.
But this assumes that security is even configured at all. So many network devices support SNMP these days that anything less than perfect administration can result in all kinds of trouble. Be honest: how many networks that you know of don't have several devices set to the "public" domain with no address filtering. Hello, Denial of Service.
After all these years of (alleged) focus on network security, I'm pretty shocked that there isn't a widely deployed standard based on public-key encryption, digital signatures, and other means of access control. You can't really make the argument that this is rocket science anymore...
Help save the critically endangered Blue Iguana
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.
The software vulnerabilities could be exploited to varying effect, Lindner added. In some cases, PCs, routers and other devices could be shut down or cut off from the Internet. "In the extreme case, you could exploit a buffer overflow to take control of the device," Lindner said.
:-)
Unfortunately the article is of provides too little information to know what's actually going on. A search on Google, as of yet, provides equally little information on this or these "bugs." Funny how much the above vagueness sounds like behaviour people used to engage in order to take over IRC channels. Perhaps some of the solutions that have been implemented in other areas can benefit this one... DoS attacks on http servers anyone? The CERT advisory, on the other hand provides the necessary information, but how many people are really going to read that?
The one thing I dislike reading ZDNet, is how they state it could affect "PC's." Perhaps people who haven't figured out IPTables or who fail to use ZoneAlarm are at risk. With the extent of today's always-on internet connections it seems that most of the problems facing the end user, ie: worms, viruses, stolen data, wrecked systems, etc., are the result of insufficient knowledge concerning the tool they are using. Now if you can't drive a car without a license.... ?? Well think about it.
What! You don't think computers can kill?
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.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
This means that if you like to configure yoru routers using SNMPv1 and someone intercepts your UDP packet, they can read the community string (normally used as an ad-hock password) you use and have access to your NE (network element).
This is a common security failure with a LOT of telecom equipment. Normally, if you enable SNMP on your boxes, keep the conguration port (normally found outside of service ports) inside a private LAN and hope for the best!
And the kicker is, I work for a telecom company implementing SNMP solutions on OOSes and EMSes. Even after 5 years or SNMPv2 being out (SNMPv3 has also come out in the last few years), most NE's being produced on the market (save for the big boys -- Nortel, Cisco, etc) come with standard SNMPv1 managment and configuration capabilities. Safe surfing.
the scariest thing about this is that windows ships with snmp off by default, making it (at least at first) immune. what are the odds?
go get it
IANA Programmer, IANA Sysadmin, I'm just a user... Mod appropriately, please.
But still, this notice strikes me as excellent. First, it draws attention to a hole that can be patched, and I'm sure a number of programmers are grabbing down what source they can to implement a fix for it. Corporations who bitch and moan about how security flaws should not be broadcast to the world strike as not being willing to fix them quickly, or are willing to sell packages with flaws in them and hope to get away with it. Yay CERT!
Second, while the magnitude of impact may be great, it's sure a change from the near-weekly "a hole has been found in Microsoft Product X" announcements we get. It stands out because we don't get "Major security hole in basic technologies" announcements very often - usually they're linked to some broken MS implementation of it, or a proprietary protocol looking for adoption.
Plus, it goes to show that the Internet is an interdependent community that relies on basic technologies to work, rather than perpetuating the myth that Microsoft *is* the Internet. And the community will either fix the problem, or adopt a new, more rigorous standard.
And speaking of rigorous, isn't it nice that the basic standard has stood up this long under heavy usage? Can MAPI32 say the same thing? Or VBScripting? Or IIS? Or...
I love watching big stuff break for two reasons - I'm a pyromaniac who loves to see thinks go up in flames, and I'm always uplifted by a well-executed community response.
GMFTatsujin
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.)
1) Don't run it if you don't use it.
2) If you use it and implemented it the way it's supposed to be implemented (listen only to trusted hosts) - upgrade with the next roll-out.
3) If you use it but don't know what you are using - get a clue, so that you fall in 2). Every lister on your box can fail you, be prepared, you have none to blame but yourself.
This is why I've always tended to run snmp on a non routable address block. It's saved me a few times.
I've noticed there's a lot of secrecy in this code. How do I, as an adminstrator who uses SNMP confirm any of this? All of these descriptions are about as vague as saying "We have a secret exploit that will kill any machine using the ICMP protocol, not exactly sure but it exists!". Does anyone have any more information as to what exactly this exploit does in order to crash. This is just not enough information:
Numerous vulnerabilities have been reported in multiple vendors' SNMP implementations. These vulnerabilities may allow unauthorized privileged access, denial-of-service attacks, or cause unstable behavior. If your site uses SNMP in any capacity, the CERT/CC encourages you to read this advisory and follow the advice provided in the Solution section below.
From what I can glean from a quick read of the advisories, is that it's not a flaw in the *protocol*, but a flaw in the many *implementations*. Big difference (but still quite annoying to fix up, especially for vendors whose hardware isn't flashable).
-me
Love many, trust a few, do harm to none.
Stupid job ads, weird spam, occasional insight at
Why does a vulnerability need to be discovered for people to realize that allowing any type of services (telnet, tftp, snmp or http) from outside your internal network to your router is outright stupid?
And in the case of an ISP, they should know their IP addresses and what addresses they use for internal machines, so creating simple Access Control Lists in their routers to deny all snmp from everywhere except their own internal machines should be as common sense as One leg at a time when putting your pants on while standing up.
access-list 161 permit tcp 192.168.148.0 0.255.255.255 any eq 161 access-list 161 deny tcp any any eq 161
http://news.com.com/2100-1001-835602.html
n g/c06/snmpv1/
/
h tm
h tml
n mp.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/testi
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.
SNMP - simple management tool for hackers?
http://www.nwfusion.com/newsletters/sec/1004sec1.
Windows 2000, SNMP and Security
http://www.securityfocus.com/focus/microsoft/2k/s
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.
From the looks of this announcement, this may well be the most serious security vulnerability ever published; it's a root hole in literally every piece of Internet infrastructure deployed to date (assuming lack of filtering; but remember that most networks aren't properly firewalled off internally from customers and insiders). If CERT can't successfully coordinate a response to this vulnerability, why should we trust them with any other problems?
SNMP is a bad protocol. It's universally hated and derided by implementors. This is an amazingly great example of the problems that spring from shallow implementation gene pools; most of these vulnerabilities are probably due to code in CMU and UCD's (related) SNMP libraries. This is an excellent example of why it is critical to diversify implementations of core protocols on the Internet. Some incredibly hardworking researchers have been working towards these ends for years; the network engineering community has largely responded to them with derision . Think about this.
This problem was so subtle that it wasn't detected for years and years, even though the vulnerability boils down to simple buffer overflows. This is because SNMP is an ASN.1/BER protocol. There are like four bazillion ways to represent a length in BER. Talented researchers have continuously reiterated the need for simple, modular protocols to replace the rickety ad-hoc mess we use now. They have again met with derision from the network engineering community. Think about this.
Finally, the fact that SNMP is an insanely complicated protocol has not been lost on attackers. The very fact that CERT "accelerated" the release of this advisory indicates that they knew attackers "could" find some of these vulnerabilities. The fact is that some black hats almost certainly have worked this out. If we had published last year, when the discovery was made, just like the overwhelming majority of other vulnerabilities, the problem would have been fixed a year ago. If you manage a large network, how do you know you haven't already been compromised? Attackers have had years to exploit these problems without you knowing about it.
Why isn't anyone learning from these mistakes?
Security's
Not
My
Problem!
ucd-snmp 4.2.2 is not vulnerable, unless the OpenBSD packaging of it is broken. See the vendor statement for net-snmp.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Yeah.. sorry about that, I was looking elsewhere when I left the tcp portion in there. I meant to change it to /any/.
:-}
Thanks!
Disable snmp-sets (which allows the remote admin to change data on the target system). I only use SNMP for infomation gathering, and do nothing with snmp-sets.
We do the same, almost universally, certainly for all of our Cisco routers and switches. Unfortunately, that does not address all the issues here, as some of these are buffer overflows which are independent of community string and allow DOS attacks. Unfortunately, the grisly details don't seem to be available - CERT refers to docs at mitre, but mitre currently isn't disclosing what these contain.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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?
That's one particular effect of the vulnerabilties on the products of one vendor (actually, multiple vendors, because of Cisco's acquisitions).
As expected, the Cisco notice does not contain any explanations which would make easier for you to conduct your own tests.
Probably. I'd actually bet they only tested one version and didn't test 4.2.2 (which would have told them it was safe). It's easier to just say "4.2.3 is safe" and not test the rest of the versions.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
So what? SNMP is so ludicrously insecure as a protocol in the first place, this bit of news is like saying "new security vulnerability in the doors of cars that don't have locks in the first place." Between the fact that there's no granular access control, no widely accepted authentication that isn't plaintext, and simply no reason for the outside world to be able to communicate with anyone's network via SNMP in the first place, if anyone has SNMP accessible by others they were screwed long before this discovery. I doubt this changes much one way or the other.
For your security, this post has been encrypted with ROT-13, twice.
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).
buffer overflows are platform and agent dependant. you can't just say the protocol SNMP has inherent overflow problems.
no doubt some vendors' implementations have overflows and DOS issues. note the CERT title Multiple Vulnerabilities in Many Implementations . this is a far cry from the blanket statement that slashdot used as their headline (sigh).
--
"It is now safe to switch off your computer."
No, it's Exchange Server. Stupid Non-technical Manager's Proposals.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
I was honestly expecting the CERT advisory to be something like "90% of all SNMP agents were found to be using the default community strings. Your pants our down, buddy, turn off the agent."
Seriously, I've always been surprised the script kiddies haven't gotten hold of this. How hard would it be to write something that finds vender X's boxes and shuts down their interfaces? Switches cannot always be behind firewalls, and the ones in front are the juicy ones.
If you don't know these names you can always check out the OVForum and join the fun. I've been "working with" these guys for quite a few years and if you want to tap some of the most experienced network engineers that deal with SNMP for the largest companies in the world then you're welcome to stop by. Yes, it's HP OpenView centric, but unless it's really off-topic then general questions are, generally, tolerated.
So that this is not taken as a totally self-serving reply here are some suggestions that I use that generally mirror the recommendations from CERT:
Create a separate VLAN or management network for your LAN infrastucture.
Protect this management network from the rest of the network via a firewall or at a minimum access-list.
Use access-list or similar technology to limit SNMP access to your WAN infrastructure from your management network, or better yet specific network management servers.
Use SNMPv3 if at all possible.
Just like any other security matter, make sure that you are running the appropriate version of code and or patches on your systems.
Hope this was helpful!
Fred Reimer
If you mean using access lists to protect the SNMP process, sorry but:
This is probably what we'll end up doing anyhow, to narrow our vulnerability while we certify a new release, but it's by no means a true fix for the problem.
If you mean turning off SNMP altogether in the router, it's like poking out your eyes to protect them from sun damage. Network Management Systems (as well as a lot of my home-brewed scripts) assume that SNMP is present and working. Still, in some cases, it may actually be necessary.
I still stand by my original point - if the OpenBSD crew can audit their kernel code and theb OpenSSH code, why can't Cisco and Microsoft (OK, forget MS, they just don't care), with more money than I can think about, do the same?
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
chongo (was here)
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..."...
A na lysis+Diagramming/Network+Inspector/Overview.htm
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+
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?...
--
Time is on my side
Now, considering that many cable modems are owned by the USER, not by the cable supplier, how will they be updated?
If the modem can be updated remotely by the ISP, then it can also be updated by some 5|<r!97 |<!66!E, and that scares the hell out of me.
If the modem can only be updated from the client's side, then how the hell will the cable company know if what update to direct the user to?
And worst yet, what if the modem cannot be reflashed? I can just see the conversation now:
www.eFax.com are spammers
I was made aware of this test suite just a few days before CERT put out it's alert on this - early I might add. The software has been available on that WEB site for MONTHS! Anyone who cared to download it could've tested this themselves - it's a pretty complete test suite.
:-)
;-)
Anyway, I was asked to test this set of tools against MSFT servers and then some networking hardware. So far the tests against WIN2K have been pretty good. I've managed to get SNMP to die gracefully a total of 2 times. No BSOD, the service simply dies. Howver in order to do this I had to run all 4 test sets at once and damn near FLOOD the machine I was testing - over 5meg worth of data at one point. When the service did die it didn't die consistantly - that is to say we cannot pick a single "magic packet" to kill WIN2K's SNMP service. Starting all test suites at the same point kills the service only occasionally and always at different test sets. I've been told via word of mouth that NT4 is even more robust - we're testing that next.
IF we get the same results from NT4 then it would seem to me that Microsoft's response to this isn't so bad. Their software doesn't APPEAR to be particularly vulnerable - hell if anything I was surprised at how robust it seemed to be with the absolute FLOOD of pure crap we were sending it's way - SNORT was going nutz BTW noting "potentially dangerous traffic" (lol).
Networking hardware may or may not be effected more easily. We've had some procurement issues but I expect we'll be attacking some test equipment soon - starting with CISCO stuff. Network management software also tends to talk SNMP. TIVOLI (note IBM didn't really mention this in their response - AIX?!), Compaq Insight Manager, TNG, HP OpenView, and many others could be effected. We're going to test what we can based on what we use. Printers and other networked office equipment might also have issues but that's low on my list of priorities right now.
Overall, I'm not really worried by this YET. When it was first brought to my attention the message was one of panic - that this software would be the "kiss of death" for most anything running SNMP even if the Community string wasn't known. Well, so far it's really yet to kill much of anything in our lab! I'm sure we'll find some things that keel over more quickly but so far our primary operating platform has shrugged off 99% of these attacks and our IDS spotted it even without having an alert put on it just for this traffic.
Anyone else testing this software? Finding problems? Hint: it seems to work best when run off of LINUX\Java. When run on a WIN2K\Java platform it didn't appear to form the packets correctly - we're getting different\better results on LINUX (shrug). I'd still be careful to only test this on isolated test netowkrs though - just in case
Build it, Drive it, Improve it! Hybridz.org
Kindergarden lesson.
Don't talk to strangers.
And this means you do not connect a vulnerable server to the internet to download patches.
We'll see how it plays out. Methinks it will cause much less problems than such as Code Red. Looks like the *BSDs may have had it pretty well patched for a year or so. Guess the closed-source don't have very good eyes.
Often times they do...do a tracert on any UUNET dialup and find the dialup server and dump the MIB tree. I think you will be suprized at the information you can learn AND change.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95