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.


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


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 >

Vulnerability Information Sources: The Hacker News vs. NIST

| Mar 16, 2017

While that may be a catchy title, it’s also the question I've been asking attendees at SCALE and Container World over the past few weeks. More precisely, “Where would you rather get your security vulnerability information from?” Now I’m going to pause here and let that sink in for a minute. Think

| MORE >

DevConf, OpenShift and Black Duck

| Jan 27, 2017

It’s that time again, a kickoff to the year’s activities. For me, the first event is DevConf, where I’ll be speaking on the joys of security in an ever increasing Agile and DevOps world. As is my wont, I’ll be presenting concepts that both challenge existing paradigms and provide a way forward. It

| MORE >