Forgot your password?
typodupeerror
Security Networking

Embedded Devices Leak Authentication Data Via SNMP 58

Posted by Soulskill
from the duct-tape-won't-fix-this-leak dept.
msm1267 writes: "Researchers have discovered previously unreported problems in SNMP on embedded devices where devices such as secondary-market home routers and a popular enterprise-grade load balancer are leaking authentication details in plain text. The data could be extracted by gaining access to the read-only public SNMP community string, which enables outside access to device information. While only vulnerabilities in three brands were disclosed today, a Shodan search turns up potentially hundreds of thousands of devices that are exposing SNMP to the Internet that could be equally vulnerable."
This discussion has been archived. No new comments can be posted.

Embedded Devices Leak Authentication Data Via SNMP

Comments Filter:
  • SNMP is Boss (Score:4, Informative)

    by Shatrat (855151) on Friday May 16, 2014 @05:21PM (#47021391)

    I've done some programming to interact with SNMP enabled devices and I don't think people realize just how much information is exposed this way, and often by default.
    You don't have to know anything about the device to 'walk' it and pull all available information if the community string is still set to 'public'.

    • Re:SNMP is Boss (Score:4, Informative)

      by jandrese (485) <kensama@vt.edu> on Friday May 16, 2014 @05:35PM (#47021521) Homepage Journal
      For years SNMP has been referred to as "Security's Not My Problem". SNMP v.1 and v.2 are horrendously insecure, and v.3 is only marginally better and at the same time too complicated for most people to set up. I would hope that most home routers would not open a SNMP port to the internet. If they do, I would consider that a major security flaw in the device, even if it doesn't choose some stupidly obvious default community string, like "public".

      Sadly, fixing this is sometimes quite difficult. I have a printer that opens up SNMP to the network. It has the option to change the community string and even the option to go to SNMP v.3, but if you change the community string all of the vendor supplied utilities and drivers can no longer communicate with the printer, and there doesn't appear to be any way to change it. So that feature ends up be entirely useless. Then again, you would have to be mental to hook up a printer directly to the internet in the first place.
      • Re:SNMP is Boss (Score:4, Interesting)

        by myowntrueself (607117) on Friday May 16, 2014 @05:53PM (#47021687)

        Also SNMPv3 is very poorly supported by many monitoring tools.

        I sometimes wonder if SNMPv3 is *deliberately* made awkward and easy to misconfigure, somewhat like IPSEC...

      • by arth1 (260657)

        SNMP in itself isn't insecure, it is un-secure. There's a big difference. The "public" community in SNMP isn't supposed to contain anything except what's public. If someone exposes non-public data there, that's not SNMPs fault.
        Someone can misconfigure a web server to serve the /etc directory too, but that isn't a fault with the HTTP protocol.

        • SNMP Write Communities are inherently insecure; you're writing data to a device with a plaintext credential. The whole POINT of a SET vs GET community is that one is considered "non-public".

          Sorry, you're not correct.

          • by arth1 (260657)

            SNMP Write Communities are inherently insecure; you're writing data to a device with a plaintext credential. The whole POINT of a SET vs GET community is that one is considered "non-public".

            Sorry, you're not correct.

            The post you replied to talked about the "public" community. The "public" community is hard set to read-only in any implementations I have seen since the 90s. You need a write-enabled community to write.
            Enabling those and giving access other than on secured ports is folly, and not a fault of the protocol.

            • SNMP Write Communities are inherently insecure; you're writing data to a device with a plaintext credential. The whole POINT of a SET vs GET community is that one is considered "non-public".

              Sorry, you're not correct.

              The post you replied to talked about the "public" community. The "public" community is hard set to read-only in any implementations I have seen since the 90s. You need a write-enabled community to write.
              Enabling those and giving access other than on secured ports is folly, and not a fault of the protocol.

              The default R/W community string for most devices is "Private". However, pretty much all network devices come with SNMP R/W disabled by default.

              There are a number of ways to make SNMP a bit less open. For example, you can restrict sections of the MIB table. This is best practice for any router that is on the internet as SNMP can be used as a DDOS attack by constantly requesting the entire MIB table. In addition, access lists are your friend.

              That being said, these manufacturers were just being really stu

            • by pnutjam (523990)
              Whaoh, we know, "Security is Not My Problem"
      • but if you change the community string all of the vendor supplied utilities and drivers can no longer communicate with the printer, and there doesn't appear to be any way to change it.

        For windows printers, the setting for the SNMP string is under the port setting. Many vendors have alternate locations in the queue where they store SNMP strings, like the "communications" tab for Xerox printers.

        HP requires the printer to be on "public" during autoconfiguration only, once that is done you can change the string.

  • Embedded devices have no business connecting to the internet.

    Yeah, I've heard all the crap about my fridge can email me that I am out of milk. Bull. No one really wants that.

    The only embedded device people want to connect to the internet are camera phones.

    If it doesn't connect to the internet than security is far less important.

    If it does connect to the internet, it needs a constants stream of updates to maintain security. Because security is not a set and forget thing, but a constant job. And tha

    • Yeah, I've heard all the crap about my fridge can email me that I am out of milk. Bull. No one really wants that.

      A sales guy from upstart home security company knocked at my door a while back.
      I was in the middle of dinner...
      He wanted to sell me on all the cool new features that a smart home can provide, such as what you describe above.

      I told him no thanks, and he wanted to know why.

      I told him I've been working in IT for quite a while and I understand all the security risks inherent with such systems, and I don't want to have to worry about all the extra crap I have to secure in my house, besides the usual th

    • Embedded devices have no business connecting to the internet.

      You do realize that most of the devices identified are home routers and DSL modems, right? Their whole purpose is to connect to the Internet. Sigh.

      • One of us needs to re-read TFA, because I read it as enterprise firewalls, I read where it said twice that they are not consumer devices, and where it said there are thousands (not millions) of them connected to the internet.

        • I double checked and I see there are TWO links in TFS. The one I read focuses on load balancers. The other one does indeed talk about cable modems.

          • I double checked and I see there are TWO links in TFS. The one I read focuses on load balancers. The other one does indeed talk about cable modems.

            Yeah. I read the second link, not the first. :) Here's the bit I was referring to:

            Heiland and fellow researcher Matthew Kienow also disclosed similar issues in the Ambit U10C019 and Ubee DDW3611 cable modems, as well as the Netopia 3347 series of DSL modems. The cable modems leak not only user names and passwords, but also WEP keys, WPA PSK and SSID information. The DSL modems, meanwhile, also leak WEP keys, WPA PSK and SSIDs.

            So I guess we're both right. Good for us! :)

        • One of us needs to re-read TFA, because I read it as enterprise firewalls, I read where it said twice that they are not consumer devices, and where it said there are thousands (not millions) of them connected to the internet.

          I was replying to the poster who said the devices shouldn't be connected to the Internet. I guess he didn't read either one of the linked articles.

    • >Yeah, I've heard all the crap about my fridge can email me that I am out of milk. Bull. No one really wants that.

      I do, but only because it means a burglar drank my milk. You know, if I had milk.
    • by Bert64 (520050)

      Embedded devices do and should connect to the internet, the key is in the device being built properly in the first place and being updated if/when necessary. A properly designed embedded device will have only the features it requires, and thus a very small number of things that *might* need updating.
      Most routers and firewalls are embedded devices, and they would become pretty useless if not connected to the internet.

      The problem is that devices are designed to be "easy to use", which means "enable everything

  • or isn't it always good practice to disable the public community string as well as creating an egress filter to block all outgoing snmp?
    • by Shatrat (855151)

      It is, and to use the more secure SNMPv3 where possible, but too many otherwise technically competent people don't really understand SNMP.

      • It is, and to use the more secure SNMPv3 where possible, but too many otherwise technically competent people don't really understand SNMP.

        Too many somewhat-knowledgeable IT people think they know everything, as well.

        In some situations (windows printing) SNMPv3 isnt supported, and v1/2 is a necessity. Others, you have a fleet of X000 devices, half of which do not support v3. Feel like having 2 management systems?

      • by arth1 (260657)

        It is, and to use the more secure SNMPv3 where possible, but too many otherwise technically competent people don't really understand SNMP.

        Or they understand it quite well, but deliberately choose to not use SNMP v3 because the reason why they're using SNMP in the first place is its low overhead and short latencies. SNMP v3 defeats that purpose, and especially for small embedded devices, which don't have data processing power for AAE, nor much configurability after the EPROM has been burned.
        A remote readable weather station is a good example.
        Better to limit the MIB to only expose information you'd be comfortable posting on a public web page.

    • or isn't it always good practice to disable the public community string as well as creating an egress filter to block all outgoing snmp?

      It is. But that breaks a lot of config tools for switches routers and printers. Doh!

  • by NotSanguine (1917456) on Friday May 16, 2014 @05:42PM (#47021597)

    Authentication data/encryption keys should never be exposed via the read-only (public) SNMP community. This is just crappy implementation. Surprise, surprise. By now, SNMP v3 [ietf.org] should be the only version implemented on *any* device, given that the standard was published in 1999.

    According to TFA, most of the affected devices have been EOL'd, but are still in use and/or are for sale in secondary markets. Even so, I'd be surprised if any of these even existed before 2004, a full five years after the SNMP v3 spec was published. Sigh.

    Okay I know, a huge number of devices from almost every manufacturer default to SNMP v1 or v2c with no encryption whatsoever. But that doesn't make it right, nor does it excuse the inclusion of private data in the public MIB. I'm just glad I don't have any of those devices.

    • By now, SNMP v3 [ietf.org] should be the only version implemented on *any* device, given that the standard was published in 1999.

      According to TFA, most of the affected devices have been EOL'd, but are still in use and/or are for sale in secondary markets. Even so, I'd be surprised if any of these even existed before 2004, a full five years after the SNMP v3 spec was published. Sigh.

      WEP was broken in 2001. My local DSL ISP provides wireless routers to their customers. They come from the ISP configured with WEP. In 2014.

  • Best way to do a full recon before exploit. If end user does not have it installed, please do so. Next step is to get copy of Address Book for proper spear phishing
  • by myowntrueself (607117) on Friday May 16, 2014 @05:58PM (#47021743)

    When I was in a certain 3rd world country, which shall remain nameless, I found that a router at the National Datacenter had snmp public exposed to the world. It was interesting to find that it had ports named for all the ISPs in the country and a mirror port carrying lots of data, the volume of which corresponded to the sum of all the ISP's ports... and all these ISPs routes went through that National Datacenter.

  • by Anonymous Coward

    Never has any problems, and if it does the crew at open BSD will "fork and fix".

  • Will people ever learn.

    • If you'd included a question mark, we could have applied Betteridge's law of headlines.
      And of course, the answer to your question would have been "No."

  • SNMP is not secure, which is fine.

    Encoding private data like passwords in a way that it's retrievable via SNMP is retarded, like making your Apache default.html page have the root username and password in it.

    SNMP is a protocol; if you choose to share stupid data over it, you're stupid, not the protocol.

    • by Gothmolly (148874)

      And I can't spell spectacularly, but that's not the point.

    • by hax4bux (209237)

      Complaining about V1 community strings makes as much sense as "discovering" that telnet is insecure.

      Don't use V1 if you are concerned about this. There is no promise of security and never was.

      • by NotSanguine (1917456) on Friday May 16, 2014 @11:35PM (#47023221)

        Complaining about V1 community strings makes as much sense as "discovering" that telnet is insecure.

        Don't use V1 if you are concerned about this. There is no promise of security and never was.

        The issue isn't the SNMP version, but that the MIB [wikipedia.org] includes the passwords and encryption keys. Which makes this even worse -- it's not a bug, someone had to actually think that it was a good idea for that information to be publicly available. Sigh.

We are experiencing system trouble -- do not adjust your terminal.

Working...