back to article 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 …

  1. Anonymous Coward
    Anonymous Coward

    Honest question. What if password authentication is disabled and logging in requires a key?

    1. druck Silver badge

      Quite often these devices don't support key only login. But if they do, it is better than using a password.

      1. Crazy Operations Guy

        "But if they do, it is better than using a password."

        Except its been shown that most IoT devices are shipping with the exact same private key. Certificate-based auth would be extremely trivial to break...

    2. Justin Pasher

      @AC

      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.

  2. Ken Moorhouse Silver badge

    Suggestion

    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.

    1. Brian Miller

      Re: Suggestion

      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.

      1. Ken Moorhouse Silver badge

        Re: Suggestion

        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.

  3. Duncan Macdonald Silver badge

    Best fix - DO NOT BUY IoT devices

    With the current state of play IoT devices are for IDIoTs.

    If for some strange reason you want an IoT device then connect it to a wireless network that has NO connection to the internet.

  4. SL1979

    SSH and Internet Facing Devices

    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.

    1. Charles 9 Silver badge

      Re: SSH and Internet Facing Devices

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

    2. itzman
      Facepalm

      Re: SSH and Internet Facing Devices

      Why would someone run an internet-facing device with SSH open to the world, in the first place?

      Because it makes remote admin and remote access easy. Even from mobile devices that are not on reliable IP addresses.

  5. Crazy Operations Guy

    So, not an OpenSSH bug

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

    1. Paul Hovnanian Silver badge

      Re: So, not an OpenSSH bug

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

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022