The Unknown Knowns: Vulnerabilities Hiding In Your Devices

In 2002 then-US Secretary of Defense, Donald Rumsfield, brought public attention to a notion that information can be divided into three categories: known knowns, known unknowns, and unknown unknowns. As cybersecurity defenders, how can we apply this formulation to vulnerabilities?

• The known knowns: Vulnerabilities that have been explicitly discovered through scanning and testing. 
• The known unknowns: Newly created software that has yet to undergo any application security testing. 
• The unknown unknowns: Systems that the defender does not know about.

Others have posited that there is, in fact, a fourth dimension: unknown knowns, which comprise “that which we intentionally refuse to acknowledge that we know” or “do not like to know.” I believe that we can apply this formulation to security vulnerabilities as well, and we’ll explore this further below.

What is a vulnerability?

A vulnerability is any kind of inherent weakness in a system which could be exploited by an attacker to cause some type of unauthorized or unintended negative effect. It represents a potential risk. They come in many varieties including but not limited to:

• buffer overflow
• privilege escalation
• SQL injection
• missing encryption
• missing authentication
• weak passwords and keys

When exploited, they can allow for effects ranging from breaches of data confidentiality to data corruption to denial of service. Increasingly, in the world of embedded systems and IoT, vulnerabilities can further introduce risks to public health and safety.

CVEs and CPEs

For ICT systems which are marketed in the USA, when vulnerabilities are discovered they are typically cataloged in the National Vulnerability Database (NVD). Each vulnerability is described and profiled by type and severity and each is assigned a unique Common Vulnerabilities and Exposures (CVE) identifier. A well-known example is CVE-2014-0160 (aka Heartbleed).

Each CVE is further mapped to specific systems, software, and application packages which are known to have this vulnerability. This is done by mapping CVEs to Common Platform Enumeration (CPE) identifiers. CPEs can be described for one of three different part types: applications (a), hardware (h), or operating systems (o). For example, cpe:/a:openssl:openssl:1.0.1a describes the “application” (a) known as OpenSSL with version number 1.0.1a. The CVE entry for CVE-2014-0160 will tell you that this version of OpenSSL is affected by it.

Reporting vulnerabilities

An important point to stress is how official, known vulnerabilities (i.e., CVEs) come into being. They exist only if a security researcher or the software/system vendor themself takes the positive step of registering the vulnerability with a CVE Numbering Authority (CNA). Further, each new CVE is typically only associated with the systems (i.e., CPEs) that were specifically tested and validated by the researcher or vendor.

A given vulnerability might impact other devices, but if those CPEs are not explicitly associated with the CVE, this will not be documented.

An example medical device

With that background in place, let us move to a more concrete example. I have researched a particular medical device in common use today—let us call it Device Alpha—and found that it has just three CVEs associated with it. This means that a vulnerability was discovered; defined and reported (i.e., a CVE was created); and explicitly associated with Device Alpha (i.e., the CVE is mapped to Device Alpha’s CPE identifier).

So, there are only three known vulnerabilities and, moreover, none of them is terribly concerning. Should a security team, therefore, be able to rest easy as it pertains to this device?  Put simply: No.

First, how much confidence can we have that the manufacturer is performing security assessments and self-reporting vulnerabilities? Historically speaking, in the realm of medical devices, not much. Traditionally, they have not operated like a long-time under-the-microscope vendor such as Microsoft, who steadily releases countless batches of vulnerability disclosures and patches at least once every month. Market pressures have yet to force medical device manufacturers to be so forthcoming, and they, admittedly, have additional difficulties in releasing timely software updates due to the regulatory environment.

So can healthcare organizations perform their own vulnerability assessments of the medical devices that they acquire? Unfortunately, over time, many factors have prevented this from systematically occurring. Many medical devices have been found to be hypersensitive to port and vulnerability scanning to the point that they can reboot, crash, or even brick. Given the expense and criticality of these devices and their direct impact on patient care and safety, most HDOs have chosen to exclude them from their regular scanning programs.

In addition, even with a successful vulnerability scan of a device, one may only be scratching the surface of the kinds of vulnerabilities that could be lurking within.

Opening the black box

Under the hood, medical devices are running software. Due to the complexities of the supply chain and of software development in general, it is highly likely that there will be both proprietary software and many off-the-shelf software components borrowed from other places. Knowing the complete software bill-of-materials (SBOM) for a given device would go a long way towards providing insights into the vulnerabilities inherent within it.

A supplementary black-box vulnerability scan may discover some of the installed components and their vulnerabilities if those components have listening services that respond to queries, but it is rarely sufficient. The only real solution to this problem is to directly examine the firmware itself.

At Finite State we uploaded Device Alpha’s firmware into our Iotasphere platform, which quickly analyzed it and provided detailed feedback about its true makeup. All of its installed components were automatically cataloged into a complete SBOM. Each application in the SBOM was automatically associated with specific CPEs. And each CPE was automatically associated with the CVEs that affect it.

Device Alpha was found to be running on a Linux 2.6.24 kernel operating system from 2008. Among many other software components, it was found to be using BusyBox 1.12.1 from 2013 including a telnet server; the vsftpd FTP server; and OpenSSL 0.9.7 from 2002.

Given an SBOM with components this old, it should be no surprise that there are associated vulnerabilities. Just how many, however, may be shocking. There were, in fact, 1164 known CVEs found to be associated with all of the software components embedded in Device Alpha’s firmware:

• 37 Critical
• 310 High severity
• 604 Medium severity
• 213 Low severity

Of the 37 critical vulnerabilities, 19 of them had a perfect 10 (the highest) CVSS score for severity. This medical device, running firmware known to be in common use in hospitals today, has potential vulnerabilities that have been known about since 2006.

To be clear, not all 1164 of these CVEs are exploitable as implemented in Device Alpha. However, many absolutely are. More to the point, they are indicative of a software development lifecycle from this manufacturer that does not put enough emphasis on security.

The Unknown Knowns

To begin this blog, I placed vulnerabilities into three groups, and I indicated a belief that there are vulnerabilities that actually do fall into the fourth unknown known category. How could we describe those?

• The unknown knowns. Vulnerabilities that are known to exist, but that have not been associated with all the systems they actually affect.

Embedded systems manufacturers certainly need to do better. The use of components this outdated and insecure within a medical device is indefensible. However, as risk managers and defenders, we can also improve.

We need to take ownership of the security of the devices on our networks, especially when those devices can impact public health and safety. We need to make better acquisition decisions and use our buying power to positively influence the security readiness of the products that we purchase and deploy. We need to make the effort to fully understand what is in these black-box devices before they arrive on our networks. And we need to put appropriate controls in place to protect them in production.

All of these goals are best served by fully understanding the makeup of and the risks inherent in the firmware running on our devices. There are practical steps you can start taking now.  Please get in touch with us through the form below to discuss how we can help you better understand your risks.