Are IoT Devices "Pollutants" to the Internet?

IoTPollutants-header.jpg

I have written a couple of times about how poorly designed IoT devices are threats to our infrastructure and “pollutants” to the Internet. I want to tie that idea back to the importance of managing open source in the IoT market.

The Mirai attacks exploited a design weakness in the targeted IoT devices. Namely, the devices did not require users to change default passwords, and the attacker(s) correctly assumed that the majority of IoT device owners would not bother to change the passwords on their own. When setting up a device, whether it’s an Internet camera, DVR, television, baby monitor, or doorbell, most people want to make sure it performs the desired functions. If changing the password isn’t a required step, it’s not going to get done.  

IoT Vendors - Next Steps?

One of the IoT vendors whose devices were targeted has issued a partial recall, and also posted updated firmware on their website.

Yeah, that will fix things…

Most users may not know that their devices are affected, and are unlikely to install patches. (When was the last time you updated your router’s firmware?) Further, most IoT consumer likely don’t understand that a device or application may include undesired features or functions that allow these types of attacks.

Software Security Awareness

In many ways, IoT device manufacturers are just as naïve as their consumers. A design flaw like this demonstrates a complete lack of awareness of software security and a complete disregard for the people, systems, and services that rely on the Internet for commerce and vital services. The inability to update these devices remotely or push fixes to consumers ensures that this will happen again as the codebase ages.

Software does not always age gracefully.  The longer a codebase lives, the more likely it is to have vulnerabilities discovered. For example, take a look at the graphic below from Black Duck’s OpenHub; it shows the number of vulnerabilities in different versions of OpenSSL.

the number of vulnerabilities in different versions of OpenSSL

As shown, components in the version 1 “family” show many more vulnerabilities reported. This is expected, since the code has been available longer. We can see how exploiting the code would become easier over time.  

By itself, this is not a problem. But what if an old version of OpenSSL was used three or four years ago in an IoT device that does not allow simple, automated updates? 

Now we have a problem.  In fact, more than one.  Since January, 2013, 96 vulnerabilities have been disclosed in OpenSSL. Sixteen of those were scored “high” or “critical” by NIST – not including Heartbleed, which only earned a CVSS score of 5.0!

Is a Cyber EPA the Next Step?

I’m not criticizing these vendors for having bugs; no software is perfect. Developers make mistakes, and researchers will find new vulnerabilities in the open source used in software. In fact, we know from our Open Source Security Analysis that 67% of the commercial applications that use open source have vulnerabilities in those components. 

Instead, I’m arguing for accountability for manufacturers producing poorly designed and executed IoT devices. Hopefully we can address this at the industry level. It would not surprise me, however, to see regulators stepping in to protect the internet environment and punish IoT polluters. Device manufacturers can help themselves by taking software security more seriously, and ensuring that software updates or patches can be applied remotely. Consumers of these products can help by following basic security best practices. 

The State of Open Source Security

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

Vulnerability Remediation – You Only Have 4 Options

| Mar 29, 2017

In my previous post, I wrote about a simple process for triaging vulnerabilities across applications. Once you have the issues prioritized, the vulnerability remediation process is pretty straightforward. You don’t have a lot of options; either remediate the issue, ignore it, or apply other

| MORE >

Vulnerability Management and Triage in 3 Steps

| Mar 23, 2017

Security testing tools can help organizations build better software by identifying vulnerabilities early in the SDLC. For security professionals and developers, however, the hard work begins when the testing is complete. Once you have a list of vulnerabilities across multiple applications, what's

| MORE >

CVE-2017-2636 Strikes Linux Kernel with Double Free Vulnerability

| Mar 20, 2017

We often talk about how open source is not less secure (or more secure) than commercial software. For one thing,commercial software contains so much open source that it’s difficult to find anything that doesn’t include open source. There are, however, characteristics of open source that make it

| MORE >