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

"Just think of a computer as hardware you can program." -- Nigel de la Tierre

Working...