Researchers at Akamai have been monitoring the growth of attacks leveraging Internet of Things (IoT) devices. These attacks are coming from compromised devices of various sorts. Akamai works hard to protect our customers and users from these attacks.
With other, non-IoT types of devices (including general purpose computers), owners can patch or reconfigure their systems to close vulnerabilities. In the Internet of Things, device owners are often at the mercy of vendor updates in order to remove their devices from the pool of botnet nodes. In some cases, IoT devices are entirely unpatchable and will remain vulnerable until removed from service.
In this series of articles, Akamai's Threat Research team and Security Intelligence Response Team will be working to raise awareness of these issues and provide steps that device owners and vendors can take to make the Internet safer from IoT devices.
Part 1: SSHowDowN Proxy
With some attacks, malicious actors install attack software on IoT devices and use them to perpetrate attacks directly. In the case of the SSHowDowN Proxy attacks, they are using the IoT devices to proxy attack traffic generated remotely by using a 12-year old vulnerability in OpenSSH.
For a detailed analysis of these attacks, please keep an eye on https://www.akamai.com/us/en/our-thinking/threat-advisories/ for the deep dive into the SSHowDowN Proxy Attacks.
Akamai has observed SSHowDowN Proxy attacks from these types of devices. Other devices types are likely vulnerable as well.
- CCTV, NVR, DVR devices (video surveillance)
- Satellite antenna equipment
- Networking devices (e.g. Routers, Hotspots, WiMax, Cable and ADSL modems, etc.)
- Internet connected NAS devices (Network Attached Storage)
If you have access to configure the SSH passwords or keys on your device, change those to passwords or keys that are different from the vendor defaults. Please note, this is typically not possible in the majority of Internet-connected devices.
If you have access to configure the SSH service on your device, take one or more of the following steps:
- Add AllowTcpForwarding No and X11Forwarding No to the sshd configuration file, usually found at /etc/sshd_config or /etc/ssh/sshd_config.
- Add no-port-forwarding and no-X11-forwarding to the ~/.ssh/authorized_ keys file for all users.
If you are unable to do either of the above, disable SSH entirely via your device's administration console. You can re-enable it for the duration of any tasks that require it, but be sure to disable it again when you are done.
If your devices are behind a firewall, consider doing one or more of the following:
- Disable inbound connections from outside your network to port 22 of any of your IoT devices.
- Disable outbound connections from your IoT devices except to the minimal set of ports and IP addresses required for their operation.
If you sell IoT devices that use an SSH daemon, please consider the following options:
- Use per-device passwords or keys for all SSH accounts. Disable password authentication when possible.
- Make it possible for end-users to disable sshd features without having to wait for a firmware release.
- Harden your ssh daemons by disabling all features not explicitly required by your device. This includes X11, port forwarding, agent forwarding, scp, etc.
- Include explicit inbound and outbound packet filtering.
Although the IoT devices we've seen attacking do take some steps to block abuse of the SSH servers in those devices, they have not taken steps to defend against CVE-2004-1653. They have blocked simple login by setting the administrative user shell to /usr/sbin/nologin or /bin/false/. That is a useful, but incomplete control.
Given credentials for a user account, often unchanged or unchangeable in IoT deployments, an attacker can use the -D or -L flags to ssh in order to turn the victim machine into a proxy (see diagram below) The -N flag can be added to prevent launching one of the disabled shells.
1) /> ssh -D 8080 -N firstname.lastname@example.org (requires "default" account credentials)
2) /> curl --proxy socks5h://localhost:8080 http://target.site/
Because these attacks are leveraging IoT devices, the mitigations proposed in the initial disclosure from 2004 are not available to the device owners.
Full technical details, including an examination of devices participating in these attacks will be made available as part of the detailed technical report shortly.