Fingerprinting OpenSSL libraries on IoT devices

Summary. We show a method of identifying OpenSSL library versions on IoT devices based on network fingerprinting. We find many popular IoT devices may likely have used outdated OpenSSL library versions with known vulnerabilities.

Overview. Internet-of-Things (IoT) devices could be transmitting sensitive information about their users, including voice, sound, and even medical conditions. It’s important that IoT devices properly encrypt their traffic. Past research shows, however, that many IoT devices do not encrypt their traffic (e.g., sending data over plain-text HTTP), or they improperly encrypt the traffic (e.g., using outdated SSL 3.0).

In this post, we focus on IoT devices that appear to encrypt their traffic with TLS, but which may be using misconfigured settings or outdated libraries. We ask the following question: How do these devices encrypt their traffic? Using third-party libraries? What libraries (like OpenSSL)? Are these libraries up-to-date?

Which encryption library does an IoT device use?

Extract firmware. To answer this question, one approach is to extract the firmware from an IoT device. This method could be difficult, as many devices could be DRM protected.

Network fingerprinting. Another approach is to fingerprint a device’s network traffic and infer the library version. Many modern TLS libraries come with unique configurations, such as the cipher suites and their order of presentation in establishing TLS handshakes (i.e., ClientHello), along with the extensions and their order of presentation. We can observe such configurations when we sniff the network packets of IoT devices. In fact, past research has shown that it is possible to infer the browser version based on ClientHello fingerprints, as shown in this NDSS ’17 paper and NDSS ’19 paper.

Key idea of our approach. What about using a similar technique on IoT devices? Here’s the intuition:

1. Gather TLS ClientHello fingerprints from IoT devices.
2. Gather TLS ClientHello fingerprints from known TLS libraries, such as OpenSSL, wolfSSL, and MbedT LS.
3. Match fingerprints from the two steps above. In other words, if an IoT device’s fingerprint is X and OpenSSL version v also has fingerprint X in its default client, we say that the device likely has OpenSSL version v.

How to fingerprint IoT devices at scale?

Challenges. Fingerprinting browsers’ TLS library is a relatively tractable problem, as the number of browser versions is limited. Basically, you run a browser, capture its TLS traffic, and analyze its ClientHello packet.

In contrast, IoT devices come in different models, types, and manufactures. We could buy a large number of IoT devices in the lab, interact with each device, capture its traffic, and analyze its ClientHello packets. The number of devices we buy in the lab — hence, the scale of our study — is limited by our physical space and budget.

Crowdsourcing fingerprints. If we cannot buy all the IoT devices in the world, we can ask volunteers to donate network traffic data from their IoT devices — a technique called crowdsourcing.

Through the IoT Inspector project, we have asked more than 5,000 users (at the time of writing) to share the anonymized network traffic from their 50,000+ devices. From many of these devices, IoT Inspector captured the ClientHello packets. For each ClientHello, we extract key parameters such as the version, cipher suites and extension types, preserve their order, and hash them — thereby constructing the fingerprint for this ClientHello. Note that an IoT device may have multiple ClientHello fingerprints, presumably because the device may have used different TLS libraries for different internal functionalities.

Fingerprinting known TLS libraries. Getting the device fingerprints is not enough. At this point, we don’t know which device fingeprint corresponds to which TLS library yet.

To identify the fingerprints of known TLS libraries, here’s what we do. Let’s take OpenSSL as an example.

1. Take an OpenSSL version — say, 1.0.0m.
2. We compile this version.
3. OpenSSL comes with a sample TLS client, which establishes TLS connections using the default TLS parameters. We use this client to connect to some HTTPS server, while we capture the ClientHello packet.
4. We label the ClientHello fingerprint as 1.0.0m.
5. We repeat Steps 1 through 4 for different versions of OpenSSL.

Mapping fingerprints from IoT devices to known libraries. At this point, we have two sets of ClientHello fingerprints:

• One set collected from thousands of real-world IoT devices throughthe IoT Inspector project
• Another set collected from various versions of known TLS libraries

If an IoT device’s fingerprint matches that of a known TLS library, we say that the IoT device likely uses the library. We say likely because we don’t have the ground truth; for what it’s worth, the IoT device may not be using the matching library, as the fingerprints happen to match. Even though we are not 100% certain, this result will help us narrow down to cases where an IoT device could have been using a particular vulnerable library. We or other researchers can confirm through reverse engineering, which is a more laborious process.

IoT devices have the same fingerprints as which TLS libraries?

Distribution of library versions. Using the method as described above, we first show how many devices in our IoT Inspector dataset have ClientHello fingerprints that match known OpenSSL libraries.

Figure 1: Number of IoT devices in our dataset that match the fingerprints of a particular OpenSSL version.

We restricted our analysis based on devices seen by IoT Inspector between 2019 and 2020. Effectively, the table shows a snapshot of all the OpenSSL library versions on IoT devices as of 2019 and 2020.

Here’s how to interpret the table above. Take the last row as an exmaple. In our dataset of devices seen 2019–2020, there are 64 IoT devices whose ClientHello fingerprints matched those of OpenSSL 1.0.2m, which was released on Nov 2, 2017.

OpenSSL 1.0.2m is potentially a security risk, as it is associated with a number of CVEs, and it is outdated.

How outdated? Why weren’t the devices updated to the latest OpenSSL versions?

Measuring outdated-ness. To measure how outdated the versions were and identify opportunities where devices could have updated, we plot the following chart.

Figure 2: How outdated OpenSSL library versions are on IoT devices in our dataset.

Here’s how to interpret the chart above:

• x axis: Time
• y axis: Unique IDs of devices
• Each vertical red line denotes the release time of an OpenSSL library version of a particular fingerprint. If library version i has fingerprint F and library version j has fingerprint F, where t(j) > t(i) and t(.) is the release time, then both versions i and j will be on the same vertical line at t(j). Effectively, the vertical line captures the last version of OpenSSL library with the same fingerprint. The vertical lines correspond to OpenSSL 1.0.0m (released on June 5, 2014) through OpenSSL 1.0.2m (released on November 2, 2017).
• Each horizontal line denotes, for a particular device, the time between the release of its OpenSSL library (red dot) and when we last saw that device in our dataset (blue dot).

Main takeaways:

• Many devices use outdated OpenSSL libraries.
• Vendors could have updated to newer versions, but they didn’t.

So what are these vendors?

Identifying vendors. To identify the vendors of these IoT devices, we leverage the device labels in the IoT Inspector dataset. Each user of IoT Inspector has the option to label their IoT devices with the names and vendors. This practice not only helps them identify devices of their interest, but it also helps our research. It would otherwise be difficult for us to infer these labels ourselves based on the network traffic alone; after all, device identification is a known hard problem. In our dataset, about 20% of the devices have been labeled by the user.

In the follow boxplot, we show the vendors and the distribution of the outdated-ness of the OpenSSL libraries.

Figure 3: Quantifying the outdated-ness of the OpenSSL libraries on each vendor

Each value in the parentheses refer to the number of IoT devices by that vendor; for example, we have 32 Amazon IoT devices (most of which are Echos). Each horizonal bar shows the distribution of outdated-ness in terms of the number of days.

Next steps. Our preliminary results show that many IoT devices use outdated OpenSSL versions, and that vendors had an opportunity to update to later versions but didn’t. In the coming days, we will write another blog post that examines more devices and more library versions. Stay tuned!

Written by:

• Hao Shu. Researcher at New York University.
• Hongying Dong. PhD researcher at University of Virginia.
• Yixin Sun. Assistant Professor at University of Virginia.
• Santiago Torres-Arias. Assistant Professor at Purdue University.
• Danny Y. Huang. Assistant Professor at New York University.

About All Things Inspected: We are a group of academic researchers who are passionate about security and privacy issues that affect daily lives. For more details, view this post.