Slashdot Mirror
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."
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'.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
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 that means embedded devices should not connect to the internet.
excitingthingstodo.blogspot.com
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?
We play the game with the bravery of being out of range
Is there any reason I should keep the router's preinstalled firmware and not flash openwrt as fast as I can?
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.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
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.
No, no, you're not thinking; you're just being logical. --Niels Bohr
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
It's the same reason they won't prosecute the banksters. They're working for them. They protect the criminals that do their bidding like G. Gordan Liddy. Their thugs are becoming pervasive.
There are two:
* You might not have enough technical experience to figure out how to flash OpenWRT. I assume your "as fast as I can" clause means that you are able, so go for it as soon as you plug it in :)
* You might prefer to flash DD-WRT or Tomato instead. Personally, I prefer OpenWRT, because it is 100% FOSS (except for the occasional blob wifi driver, which you're allowed to exclude if you're happy with Ethernet only).
Contrary to Internet rumors, and possibly even the EULA, your warranty can't be voided by installing custom software on the device, if the software doesn't actually cause the damage, so that reason isn't in my list.
Given the fact that SNMP is UDP, and the fact that it can have huge amplification-values, I think it is a matter of time before we see this attack vector used for ddos attacks like we have seen with DNS and NTP in the past.
Yes, I know you're a trolling moron, but geez! SNMP vulnerabilities on EOL'd hardware? Sight unseen, I know you're dumber than you look.
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.
In the free world the media isn't government run; the government is media run.
Nmap and SSH worked pretty well for me back when I was still living in my dad's basement. The first device type listed in the summary was home routers running in your parents' basement, so my argument does apply.
At work, where I manage thousands of customers' embedded devices, we use encrypted modbus. The crypto is mostly snakeoil, so we don't let customers put the devices on the Internet if they are in safety-critical systems (they do anyway), but at least it has some security, while SNMP has none. If it's on a private network, unsecured modbus is a lot easier than SNMP.
My classmate from grad school manages a 300 node imaging cluster using some automated tool that runs over SSH.
Never has any problems, and if it does the crew at open BSD will "fork and fix".
Will people ever learn.
---- The above post was generated by the Turing Institute. Maybe.
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
Contrary to Internet rumors, and possibly even the EULA, your warranty can't be voided by installing custom software on the device, if the software doesn't actually cause the damage, so that reason isn't in my list.
In which jurisdiction(s)?
If you're going to give a statement like that, which blatantly contradicts the stated position of lots of companies selling consumer devices that are subsequently modified/jailbroken, then you'd better have more than an AC post saying all those companies can't enforce their terms, because.
For example, I've just checked the current law here in the UK, and I've found various pages about the statutory minimal guarantees for consumer sales under EU law. I also found a couple of pages arguing that rooting/flashing your device can't therefore void the warranty, but their arguments didn't have much to do with what the law actually says. I did not find any documented case of someone flashing custom firmware onto a device without the manufacturer's support, bricking that device, and subsequently compelling the manufacturer to accept legal responsibility for the consequences.
So please enlighten us, AC, on why those Internet rumours and the clear public statements of many companies like smartphone and camera manufacturers on this issue are all unenforceable.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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.
"City hall" in German is "Rathaus" Kinda explains a few things......
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.
I want to delete my account but Slashdot doesn't allow it.
that almost never happens. Such an edge case its not even worth dicussing. If that happens to someone that cant figure out how to fix it, they should just go buy a better router thats always easy that they learned about in thier quest to install.
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.
GP said:
> if the software doesn't actually cause the damage, so that reason isn't in my list.
ABG replied:
> flashing custom firmware, bricking the device
GP specifically said his comments don't apply if flashing the new firmware bricks the device.
If the power adapter fails or an RJ-45 jack breaks those failures are clearly not caused by the firmware. Those are the kinds of things that often can not be excluded from warranty just because you ran third party firmware. The history of these laws has to do with car manufacturers demanding that purchasers use their service facilities and parts such as spark plugs and tires. Ford's warranty could CLAIM that it's void if you use third party tires or spark plugs, but that's unlawful and therefore unenforceable. They can deny warranty coverage only if they can show that the third-party spark plugs likely caused the damage.
Also look up "warranty of merchantability" and "fitness for a particular purpose". Sellers can't put terms on those, those are warranties granted by law. In some (most?) jurisdictions they are not allowed to impose certain limitations in the other warranties they offer.
I have had a number of routers in a "nearly-bricked" state. Its not really that much of an edge case, and from the way the documentation is written, it seems very common for people to lose patience and powercycle their router part way through the flash.
Dismissing the threat of a brick with this kind of a firmware flash is kind of irresponsible.
We just got a "new" U10c019 ambit modem from Time Warner Cable less than 6 months ago.
Its still scary and confusing, and given how much ink is spilled on the site about the situation, avoiding the situation, resolving the situation... it ~seems~ like it happens a lot, to someone who doesn't know better.
And ironically its going to happen with more frequency to precisely the people who don't know better -- because they are the ones likely to fail to follow instructions select the wrong firmware, reboot mid-process, and other 'oops' scenarios.
Or buy a router which already ships with the desired firmware preinstalled...
That way you know the device will be fully compatible with it. Buying random devices can often be problematic as manufacturers will change the specs without changing the model number and you might find yourself with a crippled version that can't run the firmware you want.
Really they should just give up developing their own crippled firmware and just ship one of the well known firmwares, would save a lot of development time and provide a better experience for users.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Agreed, some problems might _arguably_ be caused by firmware.
> what about more controversial issues, like the problem with running a speaker too loud and actually damaging the hardware that was doing the rounds a little while back?
A great example. Many intelligent people here thought that was definitely a hardware problem - the speaker should be able to handle anything the amplifier can put out. As a DJ and band tech, I know that MOST audio systems can be damaged by overmodulation. Speakers normally don'tbliw because it's too loud, but because one particular stage is overmodulated, creating something that more like a square wave than a sine wave. Speakers don't like square waves. An example would be turning your amp to 8, with your phone plugged in and turned all the way up. That's likely to blow speakers because your phone isn't outputting a clean wave at max volume. Pro audio equipment has indicator lights that warn when your getting into that territory so you can turn down the gain at the right stage, which often isn't the amp. So anyway, intelligent people can disagree on that case (and they do in fact disagree).
That's a disagreement of FACT though, not of law. The question is whether the firmware caused the damage, not whether or not the warranty applies to damage unrelated to the firmware.
I've only lightly played around with nmap, but tell me, does it get me CPU used from my Procurve switch? What about interface use on my Blade Networks switch? Temp readings from my minigoose environmental monitor? Memory use on my Windows Server?
Cause I can't see how with the man page of nmap. These devices don't expose that data via SSH as far as I can tell - sure, some of them you can get a terminal on them, but that's just for configuration.
Now, I could, I suppose, have a different proprietary or custom written monitoring tool for each set of devices, or, you know, one that speaks SNMP. I know which I chose.
Opera, Proxomitron-Grypen,GPG 0x0A1C6EE3