On October 11, Akamai Technologies released a report detailing its analysis of the recent massive DDoS attack originating from IoT devices. This attack targeted security site KrebsOnSecurity, which is hosted by Akamai, and the attack had a peak sustained traffic flow of 620 Gbps. I am particularly pleased to see Akamai being forthcoming about the nature of the attack and publishing some of the analysis from their threat response team.
For more details, the full report is available on the Akamai site.
As part of their analysis, the Akamai team highlights CVE-2004-1653. This twelve-year-old CVE covers a default configuration option that could be misused. This leads to the obvious question of “how could something so well-known hurt us today?" Unfortunately, we’re dealing with a classic case of product release procedures not accounting for side effects from default configurations.
In the case of CVE-2004-1653, the notes indicate the OpenSSH configuration parameter AllowTcpForwarding is set to 'on' by default, but anyone looking at the description on securitytracker.com will find it referencing services such as AnonCVS repositories (which they might not use), and that a primary attack vector might be the transmission of spam to a proxy server. These systems and concerns were completely valid in 2004, but the landscape has changed at bit over the intervening twelve years.
OpenSSH is a very powerful remote access component that achieves its power in part due to the possible configuration options present. One of the possible uses for OpenSSH is as a proxy, or tunnel, for internet traffic. OpenSSH contains multiple configuration options to tunnel traffic, but AllowTcpForwarding provides generic support. From a security perspective, it contains a note stating “Note that disabling TCP forwarding does not improve security unless users are also denied shell access,” so it’s entirely possible to miss this issue.
IoT development is very much a Wild West style environment today. We’re seeing a proliferation of capabilities released in an effort to rapidly fuel product demand. With rapid product release cycles, the potential exists for bugs to become deferred. The type of issue covered by CVE-2004-1653 should not exist in any modern device. As a product vendor, the following questions should’ve caught this misconfiguration — thereby preventing this type of attack.
- Why is tunneling of any form required for an IoT device?
- Why are well known credentials used within consumer grade devices when this is a known bad practice?
- What update measures are present within IoT devices to permit security issues to be addressed?
- How are any update measures secured?
- What security response process might vendors have for these issues?
With AllowTcpForwarding enabled, a misconfigured IoT device becomes a proxy, allowing an attacker to mask their identity and have their network traffic appear to originate from the IoT device. Password protecting access is only beneficial if a factory default password cannot be enabled on a deployed device. Assuming the misconfiguration doesn’t permit anonymous access, users with non-default credentials should be protected from attack.
Protect Yourself from Being Part of an Attack
So how can users protect themselves better when using connected devices (and preventing them from becoming IoT bots)? All end-users should validate that they have changed passwords for connected devices from the factory default to better protect themselves. Changing the default password is really a very basic step that all users should take when setting up any type of connected device. These kinds of issues are exactly why the Department of Homeland Security is running National Cyber Security Awareness Month right now.