Heartbleed and the Internet of Things implications

Chances are good you have already seen news about the OpenSSL Heartbleed vulnerability (i.e., CVE-2014-0160). It’s a pretty significant bug, particularly since it impacts popular open-source web servers such as Apache (the most popular web server) and Nginx. This means that a combined population of up to 66 percent of the Internet is potentially impacted (based on data from Netcraft).

One significant area that has been covered less in the industry press is the impact this issue could have outside of the population of vulnerable web servers. Now clearly, the impact to web servers is a big deal. But consider for a moment what else might be impacted by this. Here’s a hint: it’s Internet of Things Day today. In other words, consider the impact on embedded systems and “special purpose” systems (like biomed or ICS).

OpenSSL has a very developer-friendly license, requiring only attribution for it to be linked against, copied/pasted or otherwise incorporated into a derivative software product. It is also free. This makes it compelling for developers to incorporate it into anything they’re building that requires SSL functionality: everything from toasters to ICS systems, medical equipment, smoke detectors, remote cameras, consumer-oriented cable routers and wireless access points. It’s literally the path of least resistance as a supporting library/toolkit when developing new software that requires SSL.

We’ve seen an analogue of this in the past. Remember the fallout from the string of ASN1 parsing vulnerabilities a few years ago (e.g., CVE-2003-0543 and CVE-2003-0544)?  Take a look at the long list of products and vendors affected by that bug in the link above. The underlying reason for the wide reach of that problem is that the code for ASN1 parsing was reused and recycled so extensively in other products. Because ASN1 parsing is hard to do, finding code that does it already and incorporating it into derivate software is a huge timesaver. Likewise, SSL functionality is complicated to write—it is advantageous to incorporate something that is already written (like OpenSSL), particularly when doing so doesn’t incur additional cost to you or lock you in to a particular operating system platform, such as with OS-specific proprietary libraries.

From a practical standpoint, there are a few ramifications to this. While a webserver can be upgraded (relatively) easily to use the fixed OpenSSL code, an embedded system is quite a bit more challenging to upgrade. Upgrading a biomedical system, for example, without careful coordination with the vendor who supplies it can (quite literally) have a life and safety impact to patients. Upgrading an ICS system, likewise, requires careful coordination and specialized testing.

Given these facts (and not to be hyperbolic about it), recovering from this issue could literally take years.

So what can organizations do about it? Patching webservers is obviously a good idea. Folks who run websites might also wish to consider getting a new certificate since it’s possible private key data might have been exposed. Everyday users might consider changing their passwords since they could have been exposed.

For the longer-term issue that could be lurking in embedded devices or specialized systems? That’s a thornier issue. One thing that could be helpful is encouraging vendors of those systems to confirm explicitly (and in writing) that they are not vulnerable to this if they provide SSL functionality (or to provide instructions on remediation if they are). By doing this, organizations with a population of these devices can get an assurance that someone at the vendor has at least evaluated the issue and how it might impact production deployments.

Ed Moyle
Director of Emerging Business and Technology, ISACA

[Source: ISACA]