×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Embedded Devices Leak Authentication Data Via SNMP

Soulskill posted about 7 months ago | from the duct-tape-won't-fix-this-leak dept.

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

Sorry! There are no comments related to the filter you selected.

SNMP is Boss (3, Informative)

Shatrat (855151) | about 7 months ago | (#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 (3, Informative)

jandrese (485) | about 7 months ago | (#47021521)

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 (3, Interesting)

myowntrueself (607117) | about 7 months ago | (#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...

Re:SNMP is Boss (2)

arth1 (260657) | about 7 months ago | (#47023273)

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 (1)

LordLimecat (1103839) | about 7 months ago | (#47023295)

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:SNMP is Boss (1)

arth1 (260657) | about 7 months ago | (#47023347)

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:SNMP is Boss (2)

David_Hart (1184661) | about 7 months ago | (#47023789)

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 is Boss (0)

Anonymous Coward | about 7 months ago | (#47029933)

The default read community string is most often "public", and write community string is "private".

I have *never* seen read community as "private".

Re:SNMP is Boss (1)

pnutjam (523990) | about 7 months ago | (#47037685)

Whaoh, we know, "Security is Not My Problem"

Re:SNMP is Boss (2)

LordLimecat (1103839) | about 7 months ago | (#47023289)

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? (1)

gurps_npc (621217) | about 7 months ago | (#47021465)

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 that means embedded devices should not connect to the internet.

Re:Why connect them to the internet? (1)

Sir_Eptishous (873977) | about 7 months ago | (#47021577)

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 things I have(servers, pc's, WAP's, routers, etc;). He said something like, "well...(smirk) I can see you wouldn't be a good fit for us."

Re:Why connect them to the internet? (2)

NotSanguine (1917456) | about 7 months ago | (#47021639)

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 (1)

raymorris (2726007) | about 7 months ago | (#47023131)

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 (1)

raymorris (2726007) | about 7 months ago | (#47023145)

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:sorry, there are TFAs. cable modems indeed (1)

NotSanguine (1917456) | about 7 months ago | (#47023175)

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! :)

Re:where most == none (1)

NotSanguine (1917456) | about 7 months ago | (#47023179)

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:Why connect them to the internet? (1)

Jeff Flanagan (2981883) | about 7 months ago | (#47021665)

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

Re:Why connect them to the internet? (1)

Bert64 (520050) | about 7 months ago | (#47024201)

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 by default in the tiny chance that customers might use those features", and this is why most printers come with support for a whole load of protocols enabled by default when the average user will only ever use 1 of them. I can't think of the last time i tried to print anything via FTP, and yet many printers support that by default.

SNMP has no useful purpose (-1, Troll)

Anonymous Coward | about 7 months ago | (#47021499)

SNMP is worthless. It does nothing helpful.

Since it's a good security practice to disabled unused services, I disabled SNMP in my home router. Unfortunately, a portscan showed that even after configuring SNMP to turn off, the router was still listening and responding.

I flashed it with OpenWRT to fix it.

Re:SNMP has no useful purpose (1)

NotInHere (3654617) | about 7 months ago | (#47021559)

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

Re:SNMP has no useful purpose (0)

Anonymous Coward | about 7 months ago | (#47021655)

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.

Custom firmware/voided warranties (1)

Anonymous Brave Guy (457657) | about 7 months ago | (#47021917)

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 the software didn't cause the damage" (1)

raymorris (2726007) | about 7 months ago | (#47023185)

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.

Re:"if the software didn't cause the damage" (1)

Anonymous Brave Guy (457657) | about 7 months ago | (#47024681)

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 not be trivial to demonstrate that either way.

Of course in some jurisdictions there are statutory minimum levels of guarantee that vendors are required to provide, and sometimes there is also a presumption that the item was faulty if a problem happens within a certain period after purchasing it. My question is to what extent this will necessarily help you if you've modified some part of the device significantly, in this case by installing new firmware.

(Please note that I'm not claiming the law doesn't support that position in any specific place, I'm just asking for specific citations or other verifiable data to show that it really does. A lot of major manufacturers are on the record as saying that flashing firmware will void your warranty, which suggests they may fight claims in this area, which to me suggests it may not be worth pushing your luck without the law clearly being on your side.)

fair enough (1)

raymorris (2726007) | about 7 months ago | (#47025051)

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.

Re:SNMP has no useful purpose (1)

Bert64 (520050) | about 7 months ago | (#47024217)

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.

Re:SNMP has no useful purpose (2)

vux984 (928602) | about 7 months ago | (#47021913)

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... [openwrt.org]

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:SNMP has no useful purpose (1)

koreanbabykilla (305807) | about 7 months ago | (#47022899)

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:SNMP has no useful purpose (1)

LordLimecat (1103839) | about 7 months ago | (#47023313)

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:SNMP has no useful purpose (1)

vux984 (928602) | about 7 months ago | (#47023537)

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 (3, Insightful)

Shatrat (855151) | about 7 months ago | (#47021573)

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:SNMP has no useful purpose (0)

Anonymous Coward | about 7 months ago | (#47021765)

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.

Re:SNMP has no useful purpose (1)

jp10558 (748604) | about 7 months ago | (#47025305)

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.

Is it just me... (1)

Sir_Eptishous (873977) | about 7 months ago | (#47021519)

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?

Re:Is it just me... (2)

Shatrat (855151) | about 7 months ago | (#47021585)

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

Re:Is it just me... (1)

LordLimecat (1103839) | about 7 months ago | (#47023319)

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:Is it just me... (1)

arth1 (260657) | about 7 months ago | (#47023323)

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:Is it just me... (1)

houstonbofh (602064) | about 7 months ago | (#47021651)

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! (3, Informative)

NotSanguine (1917456) | about 7 months ago | (#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.

Re:Poorly Implemented MIBs? Shocking! (1)

cbiltcliffe (186293) | about 7 months ago | (#47022789)

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.

Re:Poorly Implemented MIBs? Shocking! (0)

Anonymous Coward | about 7 months ago | (#47023339)

We just got a "new" U10c019 ambit modem from Time Warner Cable less than 6 months ago.

Why do Republicans... (-1)

Anonymous Coward | about 7 months ago | (#47021621)

always attempt to add these backdoors. They're so stupid that they think we'll never find them. They're projecting. Again and again, their kind shows just how stupid and incompetent they are.

Re:Why do Republicans... (0)

Anonymous Coward | about 7 months ago | (#47021629)

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.

Hanlon's Razor (0)

Anonymous Coward | about 7 months ago | (#47021721)

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.

SNMP is awesome (1)

cyberspittle (519754) | about 7 months ago | (#47021627)

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

Reflection-attack (0)

Anonymous Coward | about 7 months ago | (#47021679)

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.

Re:Reflection-attack (1)

Cramer (69040) | about 7 months ago | (#47042059)

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... (3, Interesting)

myowntrueself (607117) | about 7 months ago | (#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.

Open WRT (1)

Anonymous Coward | about 7 months ago | (#47021807)

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

In. plain. text. (1)

sandbagger (654585) | about 7 months ago | (#47021879)

Will people ever learn.

Re:In. plain. text. (1)

cbiltcliffe (186293) | about 7 months ago | (#47022827)

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 (1)

Gothmolly (148874) | about 7 months ago | (#47022837)

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:TFA spectactularly fails at the Internet (1)

Gothmolly (148874) | about 7 months ago | (#47022845)

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

Re:TFA spectactularly fails at the Internet (1)

hax4bux (209237) | about 7 months ago | (#47022953)

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 (3, Informative)

NotSanguine (1917456) | about 7 months ago | (#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.

Re:TFA spectactularly fails at the Internet (0)

Anonymous Coward | about 7 months ago | (#47025847)

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.

Re:TFA spectactularly fails at the Internet (1)

NotSanguine (1917456) | about 7 months ago | (#47026051)

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 least 80% of corporate breaches are perpetrated by those on *internal* networks.

As for configuration, yes it's important to customize SNMP community strings and configure the device not to give out the keys to the kingdom. However, including sensitive information from the MIB for RO communities is just a dumb thing to do by default, regardless of the device.

IT folks should secure their devices, but it takes a special kind of stupid to enable access to private portions of the MIB via the RO community by default.

The vendors screwed up. That doesn't mean IT folks shouldn't secure their devices, but that does fuck all for consumers who wouldn't know an OID if it came up and smacked them in the head.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?