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.


Open Source and the Internet of Things: A Reality Check

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.


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 >

Dramatically Reduce the Time to Container Vulnerability Resolution

| May 2, 2017

I'm excited to preview the results of our latest efforts to dramatically reduce the time from container vulnerability disclosure to resolution. Some of you may have read my blog post in January advocating Black Duck’s work with the Red Hat OpenShift Container Platform. The goal of that effort was

| MORE >

Top 4 DockerCon 2017 Sessions

| Apr 12, 2017

DockerCon 2017 is around the corner, starting in a few short days. Like most attendees, I like to look for the sessions that most impact my professional life. Lately that’s container security at production scale, and if you’ve dug into the topic in the past you’ll know it’s a bit messy! The

| MORE >