Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security

Security Hole In SNMP 267

Posted by timothy from the so-never-mail-passwords dept.
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.
This discussion has been archived. No new comments can be posted.

Security Hole In SNMP More

Security Hole In SNMP

Comments Filter:
  • 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.
    • That's what I actually did:

      (root@Insomnia)-(~)
      # apt-get remove snmp
      Reading Package Lists... Done
      Building Dependency Tree... Done
      The following packages will be REMOVED:
      snmp 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
      Need to get 0B of archives. After unpacking 343kB will be freed.
      Do you want to continue? [Y/n] Y
      (Reading database ... 15469 files and directories currently installed.)
      Removing snmp ...
      • Yeah, that's all great for you Debian users. Point is, there's many hundreds of thousands of devices on the internet (not just Desktop machines running linux, ya know?) that use SNMP.

        It's a really great and useful protocol, but if you have any intelligence at all, you firewall off all SNMP enabled devices from anyone you don't trust anyway.

        Either way, it's going to take a bit of work to patch all the machines using SNMP.

    • 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.

  • Not much scanning for it yet. (Score:3, Informative)

    by UnderAttack ( 311872 ) on Tuesday February 12, 2002 @04:06PM (#2995861) Homepage
    So far, DShield [dshield.org] does not have too much scanning for it yet (data) [dshield.org].
    But I guess the kiddies are still sharpening the tools...
  • If you're running FreeBSD check on this:
    FreeBSD has issued the following FreeBSD Security Advisory regarding the UCD-SNMP / NET-SNMP package: [freebsd.org]
    ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisorie s/ FreeBSD-SA-02:09.snmp.asc.

  • Interesting (Score:3, Insightful)

    by rabtech ( 223758 ) on Tuesday February 12, 2002 @04:09PM (#2995875) Homepage
    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.
    • Two funny bits about this:

      Sun, HP, and RedHat all listed links to the patches before patches were ready.

      In fact, as of this morning, only RedHat had coughed up a patch yet. But Sun and HP still recommend you install the nonexistent patch right away.

      Also, hmm, Microsoft doesn't use Open Source code, but their product is curiously affected by this vulnerability that mostly afflicts UNIX-based implementations...

  • From patches to kings (Score:3, Informative)

    by caferace ( 442 ) on Tuesday February 12, 2002 @04:09PM (#2995880) Homepage
    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...

  • 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
    • Um, the protocol has never operated that way so I'm sort of confused why you think it would. In fact, the version 1 and version 2 of the protocol wouldn't even answer at all if you sent it an incorrect community name. Version 3 does issue a "report" saying the cryptographic checksum was incorrect.
      • 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.
        • On many systems, the SNMP daemon/service can be configured such that the trap contains a so-called "trap" string, used exclusively to validate the trap. This prevents the problem outlined by fiber_halo above.

          For example, on a WinNT server that isn't too far from me, I bring up the [Network] control panel, hit the [Services] tab, double-click on the [SNMP Service] line, hit the [Traps] tab, and see that teh [Community Name] is set to "trap". Also, if I hit the [Security] tab, I see that the [Send Authentication Trap] checkbox is checked, so an invalid community string will cause a trap to be sent to the management station.

          On the other hand, the [Accepted Community Names] are set to "Public", with READ-ONLY rights, and "Private", with READ-WRITE rights. Finally, [Accept SNMP Packets From Any Host] is checked, rather than [Accept SNMP Packets From These Hosts]. This means that the system is rather open, but since it is behind a firewall that blocks all SNMP traffic, it isn't too much of an issue.

  • Numerous vulnerabilities have been reported in multiple vendors' SNMP implementations.
    Uh, doesn't this stink slightly of 'Protocol XXX was implementable insecurely, so it commonly was.'

    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

  • Not a SNMP hole (Score:4, Informative)

    by Anonymous Coward on Tuesday February 12, 2002 @04:12PM (#2995896)
    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 (Score:4, Informative)

      by Quill_28 ( 553921 ) on Tuesday February 12, 2002 @04:21PM (#2995959) Journal
      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 (Score:4, Informative)

        by tqbf ( 59350 ) on Tuesday February 12, 2002 @06:02PM (#2996537) Homepage
        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 (Score:4, Informative)

        by tqbf ( 59350 ) on Tuesday February 12, 2002 @06:11PM (#2996589) Homepage

        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:Not a SNMP hole (Score:3, Interesting)

          by hardaker ( 32597 )
          Actually, that's not true. Of a survey I recently took of SNMP users, 33% did use SNMPv3 and what's even better is that 15% of the total didn't use v1 at all.

          People are beginning to use v3 as the product vendors are beginning to ship it in the majority of the products. Unfortunately, it's still not "all", as you well know.

          (and as for dnssec, the reason it can't be used effectively now is that verisign won't let it be used because they refuse to sign the .com/.org/.net roots)
  • Who's in charge of Acronyms around here? It's not an SMTP problem!
  • Disabling SNMP doesn't close the SNMP hole, in some cases. Apparently, the hole may be in SNMP itself.

    • Re:The scary part is... (Score:3, Interesting)

      by 2starr ( 202647 )
      Well, yes and no. It sounds like there are some assumptions that are commonly made when processing traps. However, if someone wants to be malicious, those assumptions may not hold. But, the protocol isn't necessarily flawed. It just means that developers need to check their assumptions (like they should all the time).
    • Disabling SNMP doesn't close the SNMP hole, in some cases. Apparently, the hole may be in SNMP itself.

      How so? If there is no daemon listening on the port, how can a system be at risk? If I don't run an SNMP daemon, any SNMP data that hits my boxen will be dropped.

      Mind you, the implications of this issue is huge for those that run Tivoli / NetView or OpenView management systems.

  • Well duh. (Score:3, Funny)

    by Anonymous Coward on Tuesday February 12, 2002 @04:13PM (#2995905)
    What do you expect from a protocol named Security's Not My Problem?

  • Delay in release (Score:1, Interesting)

    by Anonymous Coward
    What I would like to know is why it took CERT so long to release this information.

    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. :P

  • End of email from SANS... (Score:5, Informative)

    by heliocentric ( 74613 ) on Tuesday February 12, 2002 @04:17PM (#2995936) Homepage Journal
    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
    • Let's not send the wrong message here... they said turn it off if you don't need it. Don't blow up your car just so no one will steal it. Lock the doors!

      Similarly, SNMP is a really useful tool that administrators should be making even more use of. They shouldn't get rid of it just because of this bug or the fact that lots of people use defautl passwords. That doesn't make the tool bad. Fix the bug(s). (Have there been other bugs recently?) Set the passwords. Save the car.
    • 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. "

  • ...but for a Cisco temporary fix, you can always try this line:

    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.
  • ...that the community strings (aka: passwords) are sent in cleartext?

  • SNMP's a pretty damned scary protocol anyway (Score:3, Insightful)

    by ErikTheRed ( 162431 ) on Tuesday February 12, 2002 @04:21PM (#2995963) Homepage
    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...
    • Ever heard of SNMPv3?
      • Sure... but a frail minority of network devices support V3. SNMPv1 is still the norm for all but a few device providers (CISCO).

        Face it... if you must use SNMPv1, make sure the router configuration port is on a private LAN and not accessible to the service ports you are providing. And pray someone doesn't break through.

    • The security in ANY service (*read: smtp, dns, snmp etc.*) is questionable when you do not restrict who is able to access it.

      Why, just because SNMP provides a community string as a level of deterent, you says it's insecure because of this? Anyone with a tinge of security mindedness knows that you don't want SNMP exposed to the world in the same way you don't want HTTP available to external IPs (on an intranet machine).

      If you bind the snmp daemon to the internal network, and disable snmp-sets, you have a pretty locked down information gathering service.

      I use SNMP as a remote information gathering tool for a home-brewed network monitor, No One can even know I am running SNMP untill they first break into my internal network.

      Not saying it can't be done, but if it was done, I'd have more to worry about than SNMP.

    • Even without the aforementioend flaws (whatever they are), SNMP is a truely horrible protocol.

      flaimbait...

      snmp has survived the years where others have tried and failed. perhaps this is horrible to you, but I call it interoperable and highly functional.

  • Apparently crackers already had half a year (Score:1, Interesting)

    by Anonymous Coward
    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? [apple.com] :-)

  • Wrong summation (again). (Score:5, Informative)

    by hardaker ( 32597 ) on Tuesday February 12, 2002 @04:28PM (#2995999) Homepage
    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 [net-snmp.org], 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.

  • No security in SNMPv1 (Score:4, Interesting)

    by Simpler ( 558434 ) on Tuesday February 12, 2002 @04:30PM (#2996006)
    SNMP v1 as defined in RFC 1213 and RFC 1215 has no security features built in to begin with. You have to go to SNMP v2 or v3.

    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.

    • No standardized version of SNMPv2 contains security either. Only SNMPv3 has security.

      Note: there were some defined versions of SNMPv2 that never made it very far through the standards process. These were snmpv2*, snmpv2c, snmp2p, ... They have never been deployed and though they might have been secure they really shouldn't be called SNMPv2.
    • they can read the community string (normally used as an ad-hock password) you use and have access to your NE (network element)

      not always. many vendors use ACL's (access lists) to police their PDUs based on various criteria (source ip being the most popular).

  • 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. :)
  • At least in some capacity. See for yourself. [cisco.com]

    - Freed

  • 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.

  • scary... (Score:2, Funny)

    by macsox ( 236590 )
    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?

  • Excellent (Score:3, Insightful)

    by GMFTatsujin ( 239569 ) on Tuesday February 12, 2002 @04:36PM (#2996041) Homepage
    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

    • Re:Excellent (Score:2, Funny)

      by Anonymous Coward

      IANA Programmer, IANA Sysadmin, I'm just a user... Mod appropriately, please.

      Ahh, the mark of someone trolling for karma.


      But still, this notice strikes me as excellent

      Really? I thought it was the clueless stick that strikes you. daily. The notice is no different than any other Cert notice.


      First, it draws attention to a hole that can be patched

      Just like every other security hole notice...


      and I'm sure a number of programmers are grabbing down what source they can to implement a fix for it.

      Wow. You're right. 0 is a number.


      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.

      While the magnitude of imoact of an asteroid hitting the earth may be great, it's sure a change from the near-weekly "an airport was shutdown due to a putz forgetting his camera" accouncements 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,

      Right. Like bugs in Microsoft Sendmail. Or Microsoft WuFTP. Or Microsoft Red Hat linux.


      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.

      Even more of the obligatory MS sucks, trying to dissipate the blame.


      And the community will either fix the problem, or adopt a new, more rigorous standard.

      Which explains why XWindows is the Linux windowing system of choice.


      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?

      And speaking of apples and oranges, do you understand the difference between a standard and an implementation?


      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.

      What's your point again?

  • Do as usual (Score:2, Insightful)

    by tyrr ( 306852 )
    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.
  • 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 [cert.org]:

    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.

    • 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).
  • 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
  • The most recent releases (15.3.1.7 and above) of all SNMP Research products address the vulnerabilities identified in the following CERT vulnerability advisories ...
    They've just announced 15.3. There's a version 15.2.1.7. Anyone know if that's what they really mean?
    • 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.
  • 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
    • Also if you have SNMP enabled on the routers themselves, IOS's SNMP server can be configured to use an access list:

      access-list 20 permit [monitoring ip address]
      snmp-server community [communityname] RO 20

      The access list number, 20, is arbitrary. It's in a range that denotes a simple IP access list.

  • http://news.com.com/2100-1001-835602.html [com.com]

    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/ [ee.oulu.fi]

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

  • CERT Considered Harmful. (Score:2, Insightful)

    by tqbf ( 59350 )
    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.

    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 [cr.yp.to] 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 [cr.yp.to] 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?

    • 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.

  • S.N.M.P. (Score:2, Funny)

    by Anonymous Coward
    Security's
    Not
    My
    Problem!
  • 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.
  • as someone qualified to comment on this (I've spent the last 15 yrs specializing in snmp and routers/networking) snmp isn't any more or less secure than it ever really was. ie, the protocol is fine; but some implementations may be sloppier in their bounds checking than others.

    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).

  • 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.

  • What amazes me is that non of the experts have posted on SlashDot (except for hardaker from NET-SNMP.org [net-snmp.org]). Where's Dougie? Where's Jim from AOL? Where's Norm from HP? Where's Wojcik? For the critically OpenSource croud, what about Shane.O from OpenNMS [opennms.org]. How about Wodisch? And you can't forget Bubba SNMP. Then there's Peckar from Fognet, and Imhoff, and Croft from VoiceStream, and Sorrel from T.RowePrice. Last but not least is Waldbusser. (appologies for those that I've missed. No, I didn't include all those that have authored SNMP RFC's, rather those that work with the protocol every day and have practical experience with various implementations, and whom I have personal experience).

    If you don't know these names you can always check out the OVForum [ovforum.org] 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

  • 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.

  • 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?...

  • As I understand it, many cable modems are controlled by SNMP - that's how some folks are removing the upload speed caps.

    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:

    Cable Company Rep: Sir, your modem is bad, and needs to be updated.
    Luser: But I'm connected just fine.
    CCR: But your modem has the SNMP flaw and is being used by bad people to do bad things.
    Luser: <Stack Fault> Me not understand. Me connected. You just trying make me spend money.
    CCR: Look, sir, if you don't get a new modem we will have to turn off your service.
    Luser (who had fully rebooted his speech centers): Fine! Then I won't pay my bill.
    CCR: Money talks, bs walks. OK, we won't make you update, we couldn't really anyway, goodbye.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close