Embedded Devices Leak Authentication Data Via SNMP 58
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."
SNMP is Boss (Score:4, Informative)
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)
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)
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: (Score:3)
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. /etc directory too, but that isn't a fault with the HTTP protocol.
Someone can misconfigure a web server to serve the
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
Re: (Score: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.
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.
Why connect them to the internet? (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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.
where most == none (Score:2)
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.
sorry, there are TFAs. cable modems indeed (Score:2)
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.
Re: (Score:2)
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:
So I guess we're both right. Good for us! :)
Re: (Score:2)
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.
Re: (Score:2)
I do, but only because it means a burglar drank my milk. You know, if I had milk.
Re: (Score:2)
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
Re: (Score:1)
Is there any reason I should keep the router's preinstalled firmware and not flash openwrt as fast as I can?
Custom firmware/voided warranties (Score:2)
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 ar
"if the software didn't cause the damage" (Score:2)
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
Re: (Score:2)
Fair enough, bricking the device was a poor example as it's likely to be presumed a software fault. But 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? What if you flash a wireless router and you subsequently get in trouble because it is found to be transmitting other than in accordance with the local regulations? There are issues that could be related to the software change, but it might
fair enough (Score:2)
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 do
Re: (Score:2)
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 prov
Re: (Score:3)
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 e
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:SNMP has no useful purpose (Score:4, Insightful)
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: (Score:2)
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
Is it just me... (Score:2)
Re: (Score:3)
It is, and to use the more secure SNMPv3 where possible, but too many otherwise technically competent people don't really understand SNMP.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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!
Poorly Implemented MIBs? Shocking! (Score:4, Informative)
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.
Re: (Score:2)
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.
SNMP is awesome (Score:1)
Re: (Score:1)
Already happening. (note: most things that have the bandwidth to actually be useful for such things a) don't run SNMP (colo hosts), or b) are run by people with a clue who limit access to SNMP.)
leaking all over the place... (Score:4, Interesting)
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.
Open WRT (Score:1)
Never has any problems, and if it does the crew at open BSD will "fork and fix".
In. plain. text. (Score:2)
Will people ever learn.
Re: (Score:2)
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."
TFA spectactularly fails at the Internet (Score:2)
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.
Re: (Score:2)
And I can't spell spectacularly, but that's not the point.
Re: (Score:2)
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.
Re:TFA spectactularly fails at the Internet (Score:4, Informative)
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.
Re: (Score:2)
someone had to actually think that it was a good idea for that information to be publicly available. Sigh.
It isn't publicly available... The Brocade device that they highlight is a switch. Management ports for switches should not be exposed to the internet. Using "public" for snmp read-only community is a definite No-No. The Brocade device appears to support restricted views for SNMP community strings.
Simply put, a misconfigured device will always be a security risk. Hire better engineers.
Read the second link. The devices mentioned there are consumer grade cable/DSL modems, it's the non-technical end user who needs to hire better engineers? In those cases, it's the vendor who needs to hire better engineers.
As far as the Brocade devices are concerned (or any SNMP enabled device for that matter), Authentication data/encryption keys should *never* be exposed via a RO SNMP community, regardless of the type of device. Even if said device is for internal use only. Or were you unaware that at