Understanding the OpenSSL Vulnerability Through Protecting IoT/OT Systems

Next week, OpenSSL is expected to announce a critical vulnerability in OpenSSL versions 3.0-3.0.6 that is most likely exploitable - to what degree we aren’t sure yet at Finite State. You’ll be able to read more on that vulnerability at https://www.openssl.org/news/vulnerabilities.html.

The implications of this vulnerability are potentially wide-ranging based on the extensive OpenSSL footprint in the TLS layer of just about every Linux, Unix and Windows system.  

As Director of Research & Development, my team is responsible for ensuring that we stay at the forefront of threats and understand the impact of these threats to our customers. We’ve performed some analysis and investigation that we hope is timely and beneficial to our customers and to the market at-large. 

Without knowing the details of the “Critical” security patch, it is difficult to understand the scope and/or estimate the impact this security issue presents. OpenSSL provides the following description to what they consider “Critical:”

“CRITICAL Severity. This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.”

Source: https://www.openssl.org/policies/general/security-policy.html

Even with all the details, it could be months or even years before this vulnerability is fully understood as we saw with CVE-2014-0160, aka Heartbleed. Although impossible to compare this new vulnerability to one like Heartbleed, organizations should be prepared for an impact that is equal in scope. 

Some key facts to consider in preparation include: (source: https://heartbleed.com/):

• OpenSSL Heartbleed existed for over 24 months in the wild
• OpenSSL v3.0.0 was released on 2021-SEP-07 (13ish months ago now)
• Linux/Unix -based systems were heavily impacted and included Debian, Ubuntu, CentOS, Fedora, OpenBSD, FreeBSD, NetBSD, and OpenSUSE.
• OpenSSL exists on embedded and real-time systems

At Finite State, we align our research and technical resources to help our customers protect their IoT and OT environments with a specialization in automating connected device security across the software supply chain. We enable customers to protect the devices relied on every day through market-leading software, threat intelligence, vulnerability detection, and risk management capabilities.

Using our Finite State platform, our customers have the ability to easily gain a deep understanding and pinpoint where they are most affected by all vulnerabilities, not just this OpenSSL vulnerability.

Customers can quickly determine if OpenSSL exists in their firmware when using our SaaS platform.  Our algorithms match against package-based ground-truth using 14 different matching features. Our system also detects statically-compiled OpenSSL with intelligent, fuzzy matching of binary contents against source-based ground-truth. 

In addition, we can automatically parse SBOM manifest information from package managers found in the uploaded contents (such as debian package manifests, etc). These techniques allow us to generate industry- leading SBOMs, which leads to intelligent and fast vulnerability correlation and, finally, user search capabilities.

Our Unique Analysis

Our team took a few different paths to deliver insights based on what we can observe and correlate against our extensive database. 

In the first example, we can search a generated SBOM for the presence of OpenSSL, in this case we see 3.0.5 is present, which falls in the vulnerable version range:

In the next example, Finite State successfully detected a version that is within the vulnerable range and present in an arbitrary third-party binary stunnel. Analysis via their website yields confirmation that stunnel does contain OpenSSL.

In addition to having the capability to search across an individual firmware, customers have the ability to search across their portfolio of products. This feature allows customer teams to quickly identify and prioritize impacted products in minutes vs months.

Finally, product security teams have the ability to monitor their dashboard for “Newly Detected Issues” along with a summary breakdown of all their CVEs by Criticality:

Conclusion/Guidance

​​On November 1st, OpenSSL will be releasing version 3.0.7. This release will fix the “Critical” CVE that will be announced the same day. Although there are more than a handful of “Critical” CVEs reported against OpenSSL in the National Vulnerability Database, this is only the second to receive a “Critical” rating from The OpenSSL Project. 

Product teams should be prepared to apply this patch as soon as possible if they are affected. If your product security team is unsure of whether or not this vulnerability affects you, contact us today! 

Editor's Note: Angel Jimenez, Alex Beigel, Nathan Voss, and Ben Demick also contributed to the research and writing of this report. 

November 1, 2022 Update: Today, OpenSSL released additional information about this vulnerability, which can be accessed at this link.