Decade-old SSH vuln exploited by IoT botnet armies to hose servers Hackers are exploiting a 12-year-old vulnerability in OpenSSH to funnel malicious network traffic through Internet of Things (IoT) gizmos, Akamai warns. The SSHowDowN Proxy attack [PDF] exploits a lingering weakness in many default configurations of internet-connected embedded devices. Compromised gadgets are being abused to …
From my reading of the articles (and my own testing), the issue at hand is that many default SSH daemon configurations for IoT devices leave TCP forwarding enabled by default (AllowTcpForwarding). This basically means "open proxy for people that can authenticate".
Once a user authenticates (be it via password or public keys), even if they don't have a valid shell defined for their account, they can still do port forwarding. Since many IoT devices are going to be using default username/password combinations, if someone can access the SSH daemon on that device, they can use it has a proxy. If they don't have the credentials or the public key (when using key based authentication), they can't do anything, even if AllowTcpForwarding is enabled.
Moral of the story: don't allow unprotected SSH to an IoT device (or really any device) and make sure it's not using default or common credentials for access. Also, if you don't need it, turn AllowTcpForwarding off.
One way I would think to fight this would be for manufacturers to undertake to file a list of MAC addresses that have been used for their IoT kit, and (ideally) for those manufacturers to pay into a fund which administers a simple piece of software which is installed on pc's and Mac's whose job it is to detect these MAC addresses on the network and disable them in some way if they do not respond correctly to a "what firmware are you running?" command (poisoning techniques being one method).
I think why having a master-list would work is that manufacturers have to keep tabs on MAC addresses they issue in any case. MAC address allocation is chargeable anyway so why not use part of that charge for this purpose? Ok MAC addresses can be changed, but we're talking about catching the low-hanging fruit here. Those that think that restricted publication of such a list is a security risk should remember that this utility would be introduced into a LAN's perimeter from a trusted source.
That's great, when you have a sysadmin who's on the ball. However, a lot of these are on networks where a professional sysadmin is either non-existent, or doesn't care. After all, the passwords haven't been changed from the factory defaults, and the devices are open for world+dog to violate.
My thinking is that this is a mandatory utility bundled into the setup software of the device. It could periodically poll a central repository for updated status info which could help mop up old devices that were built pre-poison.
AV companies should see this as a means of expanding the services they provide.
There will be people around who will reverse-engineer and publish methods of disabling this functionality, but as a percentage of the community using IoT devices as a whole, I would think that it will take the potency out of any DoS that is triggered.
I suppose the downside is that hackers will seek to destroy the functionality, and that is I suppose the reason why building this into AV software is the way forward, as the likes of AVG and Kaspersky have the expertise to ring-fence it.
Why would someone run an internet-facing device with SSH open to the world, in the first place? This should be protected by VPN and a firewall, or at least behind some type of firewall. I can't imagine why anyone would have SSH facing the whole internet. That's just asking for trouble.
It's also the ONLY way they can make money, and if the law comes knocking, there's always the back door...
No law on Earth will be able to stop them because e-tailers allow direct imports from hostile powers who don't care what happens to the west. And China has nukes...
The bug appears to be in the way people configure OpenSSH, not in OpenSSH itself. OpenSSH, by default, disables everything, unless you provide it with a configuration file that include a statement to enable it explicitly.
The problem here is that these IoT manufacturers are probably just copying the sshd.conf file from the developer's desktop (Probably also has "permitRootLogin=Yes" set...)
"IoT manufacturers are probably just copying the sshd.conf file from the developer's desktop"
And copying the same private/public key pair from the install image as well. I doubt there are too many IoT vendors that have gone through the trouble to run ssh-keygen on each unit shipped.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
