Embedded Devices Leak Authentication Data Via SNMP

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

Comments

SNMP is Boss

[Shatrat]

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

[jandrese]

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

[myowntrueself]

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

Re:SNMP is Boss

[arth1]

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.

Re:SNMP is Boss

[LordLimecat]

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.

Re:SNMP is Boss

[David_Hart]

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 stupid when they decided to store user login information, even if it is hashed, in the MIB table. I can only guess that it was being used to share information with their management software and, instead of developing their own protocol, they decided to take a shortcut and use SNMP.

Re:SNMP has no useful purpose

[Shatrat]

SNMP is the best way to keep an eye on a network of thousands of devices. Many useful things become useless if you only consider the context of your mother's basement.

Re:Is it just me...

[Shatrat]

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

Poorly Implemented MIBs? Shocking!

[NotSanguine]

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

Re:Why connect them to the internet?

[NotSanguine]

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.

leaking all over the place...

[myowntrueself]

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.

Re:SNMP has no useful purpose

[vux984]

Is there any reason I should keep the router's preinstalled firmware and not flash openwrt as fast as I can?

Installing OpenWRT is scary and confusing. Its not bad after you've done it a few times, but it's not at all obvious where to start.

The documentation and website isn't structured or layered to support end users. Its by openwrt developers for openwrt developers with end user stuff mixed in willy-nilly.

It starts out barely accessible to the average user and then rapidly veers off into territory beyond even the average computer nerd.

http://wiki.openwrt.org/doc/ho...

When people say a router is bricked, this very generally means, that it does not function properly any longer and the reasons can be various. First of all, you should calm down, relax and read flash layout, file systems in OpenWrt and bootloader CLI. Now depending on what exactly is broken, you have several possibilities...

Yes, calm down, relax, and learn about the differences between NAND and NOR flash, relatively obscure filesystems, master and partition boot records... no problem right? You do have JTAG cables right? And an Arduino board you can use to upload a sketch that will send the debrick commands via serial? How are your soldering skills because you might need them! Here's the serial pinouts for a DIR-835... your router might be different!

And I say this as someone who is using OpenWRT

Re:TFA spectactularly fails at the Internet

[NotSanguine]

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