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 what are the alternatives? If SNMP is so vulnerable, what can be done? Will firmware for all hardware (routers, etc.) need to be upgraded? Sounds like a pretty big flaw.
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
I suspect it's because I metamodded as 'unfair' a bunch of 'modslapped' posts.
Once again a security flaw is found, but nobody tells anyone what the security flaw is. While they take there time to fix it, crackers are hard at work trying to figure out what it is and how to exploit it. If they told everyone what it is right away, there would be a patch and the problem would be solved before any bad stuff happened.
MS has the same policy that these guys do. One day MS is going to get hacked while they take their time writing a patch, maybe then they'll wake up.
The GeekNights podcast is going strong. Listen!
If you're running FreeBSD check on this:e s/ FreeBSD-SA-02:09.snmp.asc.
FreeBSD has issued the following FreeBSD Security Advisory regarding the UCD-SNMP / NET-SNMP package:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisori
------
Random, useless fact: I type in startx entirely with my left hand.
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...
good sporge my friend.
How can you write an article that long without using any specific details at all about what the problem actually is?
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
How silly to deploy a less-than-perfect protocol so widely with no real diversity in its implentations, and indeed no built-in security.
Once again, we are faced with the meltdown of the Internet as we know it... To be honest, I'm a lot more worried about all the unsolicited advertising and spam melting down the Internet then some teenagers with extra time on their hands.
--Nick
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?
What I would like to know is why it took CERT so long to release this information.
:P
CERT has a 45 day release policy, which apparently they are ignoring!
Many vendors have apparently known of this issue since last Fall! A bit longer then the 45 day policy.
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
Everyone who ever bothered to learn anything about security knows that SNMP is a very insecure protocol, and as my MCSE instructor (believe it or not) told us, DO NOT RUN SNMP ON THE INTERNET! Anyone who does gets what he or she deserves.
snmp-server host [snmp server ip] [community string] snmp
I'm not sure if ACL'ing 162, 163, and 1993 from outside your network will do any good for this, but it can't hurt.
I know it's almost instinctive to push the idea of an "upgrade", but I don't think all shops are in a position to do that.
Fortunately, my own network is behind a NAT gateway, but would it be possible to tank my APC SNMP adapter (the old style w/o web), and my 3Com LanPlex 2500 FDDI switch?
SNMP is supposed to be a "simple" protocol, per se, which is generally supposed to be left untrusted. Given the turnaround for exploits, I'm surprised this one took so long to come out...even if it was hidden from the general public for so long.
// Agent Green (Ian / IU7 / KB1JQO)
// IEEE 802.3: All 10base Are Belong To Us
Was it really a good idea to place the details of the exploit on the site?
I'm not trying to make an argument for security through obscurity in all cases, but it seems like the right thing to do in this case, considering the potential damage and impracticality of fixing it in a timely manner.
If you actually read the advisory, you'll see that Microsoft is just as vulnerable as just about everyone else with an SNMP implementation. The bug is in SNMP, not any particular platform that the service resides on.
-jeremy
WTF was that!
"You are not a beautiful and unique snowflake."...Tyler Durden
...that the community strings (aka: passwords) are sent in cleartext?
-- The Hoss Man
SNMP
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
From the article
The flaws were found last year by a project group at the University of Oulu in Finland, said Lindner. The group informed the CERT Coordination Center last summer, and the watchdog has been working since then to inform network hardware makers of the problems.
Isn't this like finding a gas tank that occasionally blows up and only telling the vendor (and thus a crime because deliberately witholding information that WILL save lives, and/or prevent a LOT of damage (ie not telling the police about a bomb in a car that you know of))
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?
You'll notice that Microsofts response was to turn off the SNMP service until they get a patch ready.
-Jon
this is my sig.
Oh yeah...
Security Not My Problem
No, it is NOT. Re-read the article.
Pope denounces violence.
Rich get richer, poor get poorer.
Stallman denounces copyright.
. . . you get the idea.
~~~
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!
I'm sure the Linux fanboys will find some way to blame Microsoft for this.
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.
I have never really liked the idea that SNMP is available on some devices, like routers from the internet. Some ISPs i know install routers with SNMP enables from the internet, they setup a password but if you can bring it down without a password with some sort of overflow then we could get a lot of downtime.
:)
Would it help to restrict the IP's that can connect to SNMP. Some devices supports this. I guess it depends on which level the hole is at.
BTW, did anyone see the beaten up Cisco router (that connects Patty and Selma to the net) with flies buzzing around it the the lastest ep of the Simpsons.
What the hell does this have to do with SNMP? I mean.. Really.
Constitutional rights may be respected, repealed, or modified; but they must never be ignored.
At least in some capacity. See for yourself.
- Freed
"Coffee should be black as hell, strong as death, and sweet as love." -Turkish Proverb
Please take discussion about Slashdot moderation to the Meta Slashdot Discussion.
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."
This is incorrect!! If you read the information in the CERT alert you will find this is a problem with implementation of the protocol. Just happens that almost everyone implemented it wrong. It is a classic buffer overflow DoS.
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
show your true self!
OpenBSD Not Vulnerable 8-Feb-2002
;)
(of course
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
Which article? The CERT Advisory?
Excerpt from the "Vendors" section of that advisory:
"Summary:
All Microsoft implementations of SNMP v1 are affected by the vulnerability."
True, it's not installed or enabled by default, but that's true for many other vendors as well; hence, the '...just as vulnerable as just about everyone else...'
If you enable it on Microsoft, you're just as vulnerable as if you'd installed and run it on Linux, or *BSD, or have it enabled on Cisco, or whatever.
-jeremy
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.
Any Idiot knows that SNMP V1 never had any security built into it. I can't believe the stupidity of the whole industry. This is old news! It's time for people to move past SNMP V1. Has been for years.
by the way I found a new vulnerabiloty with Telnet if you have the user ID and password you can get in.
Warning, SNMP exists. As with other protocols, the software that implimentes it may be poorly written and in some circumstances may have serious flaws, leading to security problems.
In other news, OSHA reccomends not wearing a wedding dress while repairing heavy machinery.
Please people, someone explain to me why this is news.
Check your Karma... If it is below 1 you cannot metamoderate till you post something that gets modded up....
Really? hmmm:
Have you Meta Moderated Today?
This page was generated by a Flock of Random Ninjas for quan74 (451034).
From my user info page:
Karma 0 (mostly the sum of moderation done to users comments)
Next time think before you type.
Thank you.
With so many vendors having the same problem in their implementations, it makes me wonder if they started with the same source code. Sometimes we forget that code resuse can mean bug reuse too.
My University (formerly "America's Next Great University"), uses Cisco uBR900-series Cable Modem Routers (with VoIP option, although disabled) to provide Internet Access in our dorms. Some friends tested a published security flaw regarding SNMP and the uBR900-series.... In a nutshell, it works. And no matter how many times Communications goes back and changes the settings, all they have to do is use the SNMP exploit. Good, clean fun.
It means that certain packets might crash a MS machine, but those same packets would not effect a Linux(running net-snmp), Solaris(running their agent),etc machine. You gotta understand what OULU does, they throw tons of packets at every SNMP agent known to man. Then they see which packets kill which agent. They will do the same to every other protocol over the next few years(I believe)
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.
The one thing I dislike reading ZDNet, is how they state it could affect "PC's." Perhaps people who haven't figured out ...
Journalists who haven't figured out how to spell can't expect to have their writing taken seriously.
That's interesting, but I'm unsure what relevance it has to the simple fact that Microsoft's SNMPv1 implementation isn't excluded from this advisory.
I'm confused as to what your objection is, actually. Are we talking about the same thing?
-jeremy
Who's gonna trust someone who calls SNMP a language?
Net-SNMP (formerly ucd-snmp) is BSD-licensed, so that code is probably used in many commercial products. According the the CERT page, "All ucd-snmp version prior to 4.2.2 are susceptible to this vulnerability".
The thing that I find rather interesting is that, although the list includes almost every vendor known to man, there is at least one vendor that is noticably missing. Perhaps I missed it but, I was unable to find Nortel Networks a.k.a. Bay Networks a.k.a. WellFleet on the list. Now, synoptics was on the list and it was the merger of Synoptics and WellFleet that created Bay networks but, I don't see the more recent names anywhere. Saves me a lot of patching.
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
Post again so that we can mod it down as offtopic!
A security problem with SNMPv1 is that passwords are sent clear text.
A security problem with TCP is spoofing is poosible,
This problem is the implementation of the protocol by the vendors.
If I overloaded an http request and it caused the server to crash is this a problem with the implementation of the http server or the HTTP protocol?
I don't have an objection, its just that people say it's a problem with the protocol is it not just the implementation(coding) of it.
Hoping to help folks understand.
I would be interested in hearing your thoughts.
:)
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
/etc/services
SNMP uses UDP, not TCP:
$ grep snmp
snmp 161/udp
snmp-trap 162/udp
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
Oh, I see what you mean. Your objection was with this:
"The bug is in SNMP..."
not this:
"...Microsoft is just as vulnerable..."
You're right, I should have been more clear; the bug is in the implementation, not the protocol.
-jeremy
We've noticed that all are from a group called "NSDAP" something like the Nazi propaganda arm of the Third Reich.
The files we've found left behind (hacker droppings) are
All logs and sniffer dumps etc. were emailed to angelz1578@usa.net
Rather juvenile in my opinion. Oh well its always something.
Trey
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?
I did not see any mention about Linksys. Don't they sell routers..etc... There was even a recent exploit in their WAP11 wireless access points that increased their power output using SNMP!! Anybody has any opinions on this?
So this security flaw was NOT Redmond's fault. Yeah!
Good thing OpenSource software protects us from these kinds of lousy implementations.... oh wait a second, it didnt.
Both of you... Every damned bug or flaw ends up being a discussion of the MS evil that taints your *nix world. Spare us.
I am a member of a radical hate group that defies knowledge or understanding. The WEHATI (We Hate The Internet) will bring your house of cards crumbling to the ground, rendering your information based societies impotent agains the power of our pens. Die infoscum!
No, I am not a member of RIAA trying to stop trading on peer-to-peer networks... I am a member of WEHATI and we will bring down the ectronic monstrosity that so enthralls you and connects you and allows you to share our works...
Security's
Not
My
Problem!
Geezus... Anyone with a half ounce of brains who isn't a paper engineer realizes that SNMP security is like army intelligence... It sucks.
:->
Unless you need it, disable it... Many of us like to watch over our network (otherwise it's a serious CLM), so here's a tip - disable the WRITE access with SNMP and leave the READ access enabled...
Go ahead and tweek the community name for grins, but don't rely on that for any real security - anyone with a sniffer can get the community name the next time you query the box...
VLANs and other goodies just for SNMP protection seems like too much work... Just wait for SNMP 4
It's times like this when I'm really glad I ditched the sysadmin life. Not that I ever worked with SNMP, but I imagine if you were using it that you would have to patch all sorts of devices and OS's. Man, sucks to be those guys.
If you just walk a small part of the tree ( and I mean just one set ... ).
Very bloody dodgy, I've some servers were SNMP simply doesnt return any data at all ( although
the compaq software works ). Others were getting a reading causes SNMP to crash.
I bloody well hope 2K's SNMP agent is just a tad more stable =|
Apparently you didn't actually click through to the link. The advisory mentioned is not available at freebsd yet.
In other words, if you haven't kept up to date with ucd/net-snmp, you've got a problem.
Looking at the net-snmp code, it appears it was fixed last year sometime, actually.
The only so called flaw in SNMP is when huge provider backbones like UUNET and AT&T leave the write community string to the default "private" using the original SNMP protocol set and not the new version which supports secure communications and authentication.
I come across routers all the time on pipex style networks with fully modifiable MIB trees. This could include changing route interfaces, route metrics, disabling or turning off a router, etc. as well as viewing sensitive network information.
Other than that which is a huge hole per se, but not really relating to a deficiency in the protocol but only in the administration of said protocol. Maybe there's some buffer overflow problem or something other, but one thing is for sure -- any network device which has any merit at all has SNMP managemenet built-in, and is thus affected. This includes your typical Internet routers, your cable and DSL modems, your smart HUBs and switches, line monitoring devices, QoS networks, and any network operating system (Win2k, Linux, BSDs), etc.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
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?
*REAL* network managers travel to the physical location of each piece of gear and manage it via a laptop connected via the serial port. Anything less is unsecure as hell.
Anybody who runs SNMP is a moron. SNMP is like supergluing the ignition key of your car into the switch and permanently disabling the door locks so that they're permanently unlocked because your excuse is that it's just too much of a hassle to keep up with car keys and you always want pure convenient, unfettered access to your car anytime without having to be bothered with the keys. After all nobody is ever going to steal it because that is against the law, right?
The Cert Advisory email had a subject of "CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations" which I think covers just about any problems.
It wasn't until the body of the email that it mentions this is a problem with SNMP.
And I now see what you mean, I should have been clearer.
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).
MS has responded with unprecedented speed!
n /MS02-006.asp
http://www.microsoft.com/technet/security/bulleti
Well, there's not patch yet, but at least they have a bulletin.
Some of the companies I 've worked with unfortunately use some of their telnet passwords the same as their snmp. Some of the TACAS passwords used are cleared secure because of the "encryption" into it. Sadly, if SNMP uses the same passwords... The box comes undone.
Not too secure, besides, a lot of the consultants i work with use a default UN and PASS when configuring routers... Usually the account name and 'cisco' as an enable password. eecch.
I 've pushed hard for them to change that setting but it looks like too many low - end users were complaining. Fit hits the shan now.
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."
Christ, I've got 20+ Cisco routers and 40+ plus Cisco switches and EVERY GODDAMN ONE is vulnerable, including ones we installed in August. It's gonna take weeks to test new versions of software and then install it. And all because the fucking vendors are so goddamn lazy. The causes and solutions for buffer overflows have been available for YEARS. What are these assholes doing with all the money they extort from us?
One thing this does prove is the complete fallacy of trusting "professionally" written proprietary software. Cisco and Microsoft make more money than God and they are BOTH vulnerable to this crap.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
however, the link mentioned in this article was: "http://zdnet.com.com/2100-1105-835500.html"
which doesn't redirect back to zdnet.com.
In fact, the url is completely different from zdnet's usual (e.g.):
"http://chkpt.zdnet.com/chkpt/zdhpedittop/www.zdne t.com/techupdate/stories/main/0,14179,2845901,00.h tml"
notice how "http://zdnet.com.com/2100-1105-835500.html" wasn't filed under any section like 'techupdate' for example
To me, this really looks like a fake
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
it is somewhat amusing that a not insignificant percentage of the articles that make the front page of slashdot mention that their information source is zdnet...
eudas
Blessed is he who expects the worst, for he shall not be disappointed.
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
so history is repeating itself... :-)
"If we write our stuff in XML, everyone will be able to read it"
at least XML parsers are cheaper (in $$$ if not in memory or CPU terms) than ASN.1 parsers.
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
I know that SNMP really isn't hacker-friendly, but isn't it possible that if some GNU zombie cracker stops jacking off for a minute to write a DoS tool, that this could mean large - I guess 'segments' - of the internet would just become cut off? I'm just speculating here.
Help me to comprehend the situation.
I've read a lot of comments about how this operating system covers it, and this other one doesn't etc... This isn't really about computers, this is about routers, ALL routers have to talk to each other, and you can't block that. There's a strong possibility mentioned in the Fin's paper about using that to have a loverly worm created (likely by the same folks that gave us nimda et al) that just tries every vulnerability against all the routers... it's possible that you could take the entire net down in a few hours. Phone companies also use a lot of SNMP enabled gear that is vulnerable to the overflowing that most of this code would produce, so you could effectively take down ALL comms... from a mil standpoint this is downright frightening....
Oh god, that woman is John Romero!
checkout: nessus plugins
they have the two snmp vulnerabilities:
snmp_oversized_length_field_dos.nasl
and
snmp_oversized_length_field_dos_two.nasl
#1. Timothy. SNMP != SMTP. This is unfortunate but true.
#2. A statement like "SNMP is unsecure" is like saying "guns don't kill people, people kill people." It's the same type of logic. Debating it is futile.
#3. There are three versions of the SNMP protocol. These are v1, v2 and v3
#4. SNMPv1 is the most common. Sometimes the word security is used in the same sentance as SNMPv1. DO NOT LET THIS MISLEAD YOU!
#5. SNMPv3 has all the crypto that you need - yet uptake is a bit slow.
#6. Authentication in v1 is done by sending a "community string" in cleartext to port 161/UDP. That this is a little weak is nothing new.
#7. We are talking about two seperate problems here. Don't confuse them. The first is the old issue of "Everyone uses SNMPv1 but no one secures it" - The second problem (the one Timothy was telling us about) is about buffer overflows and format string vunrabilities in the SNMP agent and trap reciever (snmpd and snmptrapd).
Think of SNMP agent to SNMP as Apache to HTTP. That the protocol is flawed is one thing. That it's common to have bugs in the implementation that are independant of the flaws in the protocol is something else. That is what we are talking about.
SNMP is a good protocol - but it's not for everyones needs. If your box exposes snmpd on 161/UDP to the www then you deserve what you get. The place for SNMPv1 is on VLANS dedicated to network management that are not part of your 'distribution' network and are definately not part of your public network.
If someone can get to your management VLAN then you may find yourself with bigger things at hand than someone sniffing your community strings.
Here's your checklist:
[_] - SNMP isn't visible to the www from any of your endpoints.
[_] - Your endpoints have good packet filtering. Just say that you have an ADSL router and you are using SNMP on the router. Make sure that you can block packets from it's red interface and not just ask the snmp agent not to respond to non-local addresses. The reason is that if the SNMP agent has to refuse a given address then it could allready been too late.
[_] - If a box isn't being managed with SNMP - get SNMP off it.
[_] - Limit, where possible, SNMP traffic to VLANS that are designed for network management.
[_] - Where possible, use the highest possible version of the protocol. (if you can use v1, v2 and v3 then use v3!)
[_] - swap your community names often. Treat them just like any other network authentication mechanism.
[_] - Audit your own LAN for security.
Hope this helps.
Everyone I know who implaments SNMP in a network will use SNMP access lists. I think all SNMP products offer access list control. I agree with the person who said no one uses SNMP v2 or v3 (v3, which I've never even seen the specs for), but SNMP v1 does offer protection in access lists. A company just defines the access list to be of internal IP addresses or a few external IP addresses and no one is going to be able to hack anything.
:)
But lasty, the problem is an interesting one. Good to hear it's not a problem with the spec but with the way it's used in products. It's sometime interesting to see which Open Source product also has this bug and if it's a 1 for 1 match with Microsoft's bug. I remember from past exploits that there is almost always an open source product that has an exact exploit match with a MS product. Makes you wonder if they copy code
-Nicholas Blasgen
And now, of course, that's gone too.