Preventing Connected Devices from Becoming IoT Bots

TCP Forwarding and OpenSSL Options Result in CVE-2004-1653On 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.

Examining CVE-2004-1653

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


Find Out More About the Internet of Things

Building Better IoT

IoT development is very much a Wild West style environment today, and with open source helping to build and sustain the IoT, 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. Another good step to protect yourself is staying informed about the additional security and privacy challenges IoT presents. These kinds of issues are exactly why the Department of Homeland Security is running National Cyber Security Awareness Month right now. 


Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Should You Replace Apache Struts? Maybe. Or, Maybe Not.

| Sep 14, 2017

It’s one hell of a year for Apache Struts. With the latest round of security disclosures comingled with the Equifax data breach, it's reasonable for users of Struts to start questioning if they should be migrating to another framework. After all, there have been five possible remote code execution

| MORE >

RSA Singapore Review - The Perils of Security Hubris

| Aug 4, 2017

With RSA Singapore now in the books, it’s time to look back on the event and a core theme of experiential learning. The stage was set for this with IBM’s Diana Keely highlighting how today’s attacks are rather reminiscent of successful tactics from the past — a form of cyber groundhog day. She

| MORE >

A Voracious Appetite for Open Source Software Worldwide

| Jun 15, 2017

At Black Duck Software, we work with the community and organizations to understand what responsible open source usage means. As part of that process, we view our connection to the open source community as a key component to both understanding where the development community is and educating them

| MORE >