Akamai: 12-Year-Old SSH Vulnerability Fueling Internet-Of-Broken-Things DDoS Attacks, And Worse
from the security-as-a-distant-afterthought dept
We've increasingly covered how the "internet of poorly secured things" has contributed to a rise in larger DDoS attacks than ever before. The barely-there security standards implemented by companies more interested in hype than quality meant it didn't take long before hackers were able to incorporate "smart" refrigerators, power outlets, TVs and other IoT devices in the kind of DDoS attacks that recently took down security researchers like Brian Krebs. The end result is DDoS attacks that continue to break records, first 620Gbps in the Krebs attack, then more recently a 1.1 terabits per second attack on a French web host.But just how bad have things become? A new report by Akamai warns that hackers are using a 12-year-old vulnerability in OpenSSH to funnel malicious network traffic through IoT devices. SSH certainly can be implemented securely, but as with every other security aspect of the IoT, many hardware vendors aren't bothering to do so. Akamai's data indicates roughly 2 million devices have been compromised by this type of hack, which the firm dubs SSHowDowN.
CVE-2004-1653 is a default configuration in old versions of OpenSSH that can be exploited by an attacker to forward ports, letting a hacker route malicious traffic through the device as part of the overall DDoS command and control infrastructure. To pull this off you need the device's admin username and password; certainly not a problem in the IoT space where default logins are often the norm. Akamai notes that many IoT devices not only ship with this vulnerability intact, but with no ability to fix it:
"We’re entering a very interesting time when it comes to DDoS and other web attacks; ‘The Internet of Unpatchable Things’ so to speak,” explained Ory Segal, senior director, Threat Research, Akamai. “New devices are being shipped from the factory not only with this vulnerability exposed, but also without any effective way to fix it. We’ve been hearing for years that it was theoretically possible for IoT devices to attack. That, unfortunately, has now become the reality."Of course the internet-of-poorly-secured things isn't just useful for DDoS attacks. Brian Krebs has penned a new blog post noting how criminals are often using hacked IoT hardware as proxies to obscure their real location as they engage in tax return fraud and other criminal activity, courtesy of your not-so-smart WiFi-enabled tea kettle or home-automation system. An anonymous researcher tells Krebs he was able to track the various "honeypot" systems he configured as they were traded and sold as malware-infested proxies in exchange for bitcoin.
In short, flimsy Internet of Things security, combined with already often-dubious embedded security in routers, is kind of a throwback to the wild west of the 1990s when the idea of your mom's PC as a botnet participant was kind of novel. Krebs' source puts it this way:
"In a way, this feels like 1995-2000 with computers," my source told me. "Devices were getting online, antivirus wasn’t as prevalent, and people didn’t know an average person’s computer could be enslaved to do something else. The difference now is, the number of vendors and devices has proliferated, and there is an underground ecosystem with the expertise to fuzz, exploit, write the custom software. Plus, what one person does can be easily shared to a small group or to the whole world."And again, while the abysmal state of IoT security can often be funny, firms like Gartner predict that the population of Internet of Things devices will top 20.8 billion by 2020, up from 6.4 billion or so today. Researchers like Bruce Schneier have been warning for some time that the check is about to come due in the form of attacks that may put human lives at risk at an unprecedented scale, lighting a fire under researchers who believe that automated cyberdefense and self-healing network technologies we haven't invented yet are what stand between us and the not-so-smart device cyber apocalypse.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
Configure to prevent exploitation at the source
[ link to this | view in chronology ]
Re: Configure to prevent exploitation at the source
It causes some issues from time to time, especially when they auto-discover their counterparts or control devices on one subnet and don't think there might be another locally. I recently had an issue with chromecast like this: It was joined to the 2.4gHz wireless, which was technically being used as a sort of "device wifi" and my phone on the 5gHz wireless (on another subnet/vlan) wouldn't allow me to enter an IP - it just kept trying to search the one vlan/subnet.
That was before they released chromecasts with 5gHz support, so maybe they fixed this, but things like these non-considerations for more complicated home networks turn me off to most IoT devices. That and I trust the security in them so little I doubt I would let the vlan they are on out to the internet, which probably breaks most of them.
tl/dr: agreed, but that breaks a lot of the functionality of these things.
[ link to this | view in chronology ]
Re: Configure to prevent exploitation at the source
[ link to this | view in chronology ]
Re: Configure to prevent exploitation at the source
But the whole idea is to sell the customer the ability to monitor and control in-home devices from the outside. Within the home, what to do - install their app just to lower the temperature without standing up from the couch?
[ link to this | view in chronology ]
While this is a problem your coverage is portraying it falsely.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
ever single person should read this
http://www.stilldrinking.org/programming-sucks
[ link to this | view in chronology ]
the shame here is unrelated people being harmed.
[ link to this | view in chronology ]
Random Default Passwords
Many router manufacturers have at least gotten the message and burn a random default password into the rom. It goes on a sticker right next to the serial number.
Sure, there are plenty of other vulnerabilities in these devices that will never be patched, but using a random password should cut out most of the malicious activity we see today.
[ link to this | view in chronology ]
Liability
[ link to this | view in chronology ]
Re: Liability
[ link to this | view in chronology ]
Re: Re: Liability
[ link to this | view in chronology ]
Re: Liability
Likewise, if we follow your initial premise, getting your IoT device hacked because you were too stupid to change the default password or take other protective measures to prevent unauthorized access is not the fault of the manufacturer, particularly if as part of the setup instructions for the device, the manufacturer recommended changing the password or taking other protective measures.
To make this work, you'd have to prove malicious intent or neglect on the part of the manufacturer, who in most cases could probably point to their operating instructions and shrug such charges off.
[ link to this | view in chronology ]
Why are all these devices directly on Internet?
You'd think everyone is putting the spare key under the doormat.
[ link to this | view in chronology ]
Re: Why are all these devices directly on Internet?
Because it's cheaper.
Here's what the camera makers are doing at least:
Now you can easily check your cheap WiFi camera from the smartphone app anywhere. All you need to do is run the app once while connected to the local network.
The alternative is persistent connections and the vendor having to gasp actually maintain some infrastructure.
[ link to this | view in chronology ]
Re: Why are all these devices directly on Internet?
Some of these devices are routers.
It's bullshit to call this an SSH vulnerability. Perhaps enabling forwarding was an unwise default, but only authenticated users can use it. If SSH forwarding were disabled, the attackers could probably still log in as admin and enable SSH or other forwarding.
The default password is the problem. SSH shouldn't be enabled until the owner sets a password. Or maybe for a minute or two after a button is pressed, so they can set the password in the first place.
[ link to this | view in chronology ]
I'm confused
Surely ANY NATting router/firewall would block these attacks stone cold. If you can't probe the ports of the deivce, or hit it directly because it's behind a NAT, how does an attacker even know there's a device there to attack?
And if you DO want to access the camera (for example) from the Internet, surely this requires doing a port forward of the streaming port on the NAT? E.g. if it's HTTP-based, you'd forward some random (but known to you) port on the router to the camera's (non-routable)IP:80? Since it's not the SSH port, the SSH attack can't be used.
[ link to this | view in chronology ]
Re: I'm confused
See my previous comment.
These devices are meant to be used by smartphones away from home, but the manufacturers don't want to pay for infrastructure. Home routers have a feature, called UPNP, to allow devices to punch through the Network Address Translation (NAT) layer and become accessible to the public internet. These devices use that feature.
Turning off UPNP will not protect you if someone is close to your house in person, but will prevent the attacks talked about in the article.
[ link to this | view in chronology ]
Re: Re: I'm confused
Such a massive security risk.
[ link to this | view in chronology ]
Re: I'm confused
NAT and firewalling are completely orthogonal concepts that have nothing to do with each other. ...
[ link to this | view in chronology ]
The IOT industry is afraid. I have seen its true face.
The accumulated filth of all their greed and arrogance will foam up about their waists and all the heedless early-adopters and parsimonious developers will look up and shout Save us!... and I'll whisper no.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
We're fast approaching a physics limit that we have to choose between moving the data faster or processing the data. Of course everyone wants to move more data. This is why people are talking about high speed photonic processing of route packets. This is very simple processing not capable of much more than route tables. Any filtering you try to place after will be like drinking from a firehose. Not even dedicated ASICs will be able to keep up.
[ link to this | view in chronology ]
Re: Re:
Krebs is doing his job identifying both networks and devices that are more compromised. There's a Chinese network that is almost fully compromised. It's safe to say that blocking it all will help mitigate the problem for instance.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
IdiOT
[ link to this | view in chronology ]
Without forwarding the port?
[ link to this | view in chronology ]
In fact, many SSH protocols on the market use outdated and old ciphers, making SSH obsolete and vulnerable, which is the same as easily hacked SSH. I purchased SSH client for android here https://www.georgiasoftworks.com/connectbot-client-android, first making sure that they use the current encryption. GSW ConnectBot offers the most reliable encryption available on the commercial market! it adapts to your company, easily changes settings, and generally with a wide range of hosts.
[ link to this | view in chronology ]