The Mirai DDoS attack, using unsecured IoT devices as a vector, has hopefully awakened the industry to the necessity of incorporating security into solutions. Not as an afterthought, but as a business-critical function of all development from here on out. And, if you’re still not convinced, don’t worry there’s more to come.
Akamai Technologies, a provider of content delivery network (CDN) services, has published new research from its Threat Research team in which researchers Ory Segal and Ezra Caltum have identified several recent attacks leveraging a 12-year old vulnerability in OpenSSH to compromise IoT devices. The tem is calling it the SSHowDowN Proxy. A full report detailing the attacks is available for download here.
This research is not about a new vulnerability. In fact, it’s worse. This is a long-standing and continuing weakness in many default configurations of Internet-connected devices. The company says that this type of attack is now actively being exploited in mass-scale attack campaigns against its customers.
The report details that these SSHowDowN Proxy attacks originate from the following types of devices: CCTV, NVR, DVR devices (video surveillance); satellite antenna equipment; Networking devices (Routers, Hotspots, WiMax, Cable and ADSL modems); and Internet-connected NAS devices (Network Attached Storage).
Compromised devices can be and are being used to mount attacks against Internet targets and Internet-facing services like HTTP, SMTP and Network Scanning, and against the internal networks that host these connected devices.
“We're entering a very interesting time when it comes to DDoS and other web attacks; ‘The Internet of Unpatchable Things’ so to speak,” said 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.”
Akamai also recommended several ways to address this vulnerability. It’s important to change SSH password sand keys from the vendor defaults, of course, and if the device can offer file system access, there are coding solutions, including: adding “AllowTcpForwarding No” into the global sshd_config file, and adding “no-port-forwarding” and “no-X11-forwarding” to the ~/ssh/authorized_ keys file for all users.
If you can’t use either of the above fixes, or if SSH access is not required for normal operations, just go ahead and disable SSH entirely via the device's administration console.
Devices located behind a firewall can be protected by disabling inbound connections to port 22 and allowing only the minimal set of required ports to operate outbound traffic.
This stuff is no longer optional, so get off your complacent laurels and stop talking about how important security is to your company, because you aren’t doing enough.
Edited by
Stefania Viscusi
