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

Open Source and The Internet of Things: A Reality Check Building Better IoT

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.

 

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

MORE BY THIS AUTHOR

A Resolution for Prosperity in Product Development

| Jan 4, 2017

For many, the start of a new year is a time of reflection and renewal. Every year we see a flurry of resolutions for the new year. These resolutions can take many forms and typically focus on health, lifestyle and prosperity. For this blog I’m going to focus a bit on the prosperity aspect.

| MORE >

Top 3 Open Source Security Lessons for 2016

| Dec 27, 2016

GHOST stories, Dirty COWs and IoT Attacks Three high profile open source security events that happened in 2016 and lessons can be learned from them. With another year under our belts, it’s a great time to look back at open source security vulnerabilities. #3 — CVE-2015-7547 CVE-2015-7547 is often

| MORE >

Don't Be the Last to Know about a Security Vulnerability

| Nov 11, 2016

We’ve all been there. Some key piece of information is known by some, but not you. It could be a party, an office tradition, or that someone expected you to do something. When you find out, it’s normal to have a sinking feeling, but you adjust and deal with the situation. Plus, if you’re anything

| MORE >