Skip to content
Analyst Insight: Download your copy of the Gartner® Hype Cycle™ for Security Operations, 2024 Report today! | Get Report
Blogs

Critical Vulnerability in OpenSSL!

Quick Links

**Updates**

2022-11-01


Details of two high-severity vulnerabilities patched in OpenSSL version 3.0.7 are now available (CVE-2022-3786, CVE-2022-3602). Both are buffer overflows in the X.509 certificate verification process, “specifically in name constraint checking.” 

The first, CVE-2022-3786, allows a threat actor to “craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.` character.”  The second, CVE-2022-3602, is similar, but in this case, a threat actor could “craft a malicious email to overflow four attacker-controlled bytes on the stack.” These could result in a denial of service or remote code execution.

While both OpenSSL servers and clients are vulnerable to this attack, it is more likely that an attacker will exploit a client than a client exploiting a server. But in servers configured with bi-directional authentication where both sides of the connection exchange and verify certificates, it is possible that a client could exploit a server by sending a malicious or malformed certificate.

And while this type of setup is rare, it’s not out of the question. But even with a successful attack, many other variables, such as anti-buffer-overflow systems like stack canaries and ASLR (Address Space Layout Randomization), come into the picture to thwart exploitation.

Because of this complexity and system safeguards, OpenSSL developers reduced the criticality of the CVE from CRITICAL to HIGH.

If you’re running OpenSSL versions 3.0.0-3.0.6, we recommend upgrading to the newest release of OpenSSL (currently 3.0.7) to protect you from potential attacks.


Introduction

OpenSSL is a software library that allows applications to communicate securely with other networked applications using a wide variety of cryptographic features. This library is widely deployed on the Internet and is a critical part of many organizations’ infrastructure. With that in mind, the OpenSSL team warned all users that a critical vulnerability had been identified in the OpenSSL codebase last Tuesday. This is quite a big deal, as the last time we had a bug of this criticality was back in 2014 with the now infamous Heartbleed vulnerability (CVE-2014-0160), which still haunts us today.

While we don’t have specific details about this vulnerability, multiple sources have claimed that the vulnerability only affects OpenSSL version 3.0.0 and above (software that uses OpenSSL 1.0.2 or 1.1.1 are not affected). The 3.x tree is a relatively new addition to the OpenSSL lineup,  which was released in September 2021. Given that this version has only been out for a short time, widespread adoption seems to have been minimal. But, once this vulnerability has been publicly disclosed and new releases go live, administrators running version 3.0.0 or above should immediately upgrade to the fixed version of 3.0.7.

Identifying Vulnerable Versions of OpenSSL

Determining whether a host is vulnerable to this unreleased bug is still hazy as we do not have all the details. But, we can look at services on the Internet that advertise what specific version of OpenSSL they are running to get a general idea of what will be vulnerable. We are currently unaware of any technique outside of checking HTTP headers to determine the exact version of OpenSSL being used, but we are still investigating alternatives. This means that while we can see many potentially vulnerable servers, we do not have insight into them all, and the statistics in this post are the lower bounds of what exists.

Luckily, some Internet servers, such as Apache, will offer information that gives us insight into what specific versions of OpenSSL are being used. For example, in the following output, we see that Apache has added all of its loaded modules into the output of the “Server” header. One is the version of OpenSSL that the mod_ssl module was compiled against:

$ curl -vvv https://127.0.0.1/ 
*   Trying 127.0.0.1:443...
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.81.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 31 Oct 2022 21:27:29 GMT
< Server: Apache/2.4.53 (Win64) OpenSSL/1.1.1n PHP/8.0.18
< Content-Length: 1436
< Content-Type: text/html;charset=UTF-8

The number of hosts running a 3.0 version of OpenSSL has been slowly growing over the past few months. In the line graph below, we see that starting in August, only around 3,000 hosts were running this new version, but by October 30th, 2022, that number more than doubled to over 7,000 hosts.

As of October 30th, 2022, 1,793,111 unique hosts have one or more services broadcasting that they use OpenSSL. Of those, only 7,062 (0.4%) hosts run a version greater than or equal to version 3.0.0. The most deployed version of OpenSSL within the vulnerable range is 3.0.1, with 3,567 unique IP hosts, and version 3.0.5, with 2,759 hosts.

One thing we should note before going much further is that a few servers on the Internet advertise versions of OpenSSL that do not exist in the real world.

 

Two hosts claim the version of OpenSSL they are running with is 3.2.0-dev, a version that does not exist.
And three hosts display a banner claiming OpenSSL version 3.1.0-dev is running, which also does not exist.

This is often done to mask the actual version of the running software for privacy and security reasons. But along with these invalid version numbers, one host caught our eye, running version 3.0.5 for several weeks, then suddenly started advertising version 3.0.7-dev on October 18th. What’s interesting about 3.0.7 is that this version number is the first version that will include the patch for this upcoming vulnerability.

We don’t know whether this one host is telling the truth about its OpenSSL version, but the general timeline does seem to match up with when this vulnerability may have been patched and deployed to a public server. Could this be an OpenSSL development server? Could it be owned by an organization that was given access to the fixed version of OpenSSL before the general public? Or is it just a server pretending to be something it is not?

Below is a table that includes every version of OpenSSL that we could identify that is greater than or equal to version 3.0.0 and the top twenty countries with those versions installed.

Version Breakdown Top 20 Countries with Openssl >=3.0.0
OpenSSL Version Host Count
3.0.1 3,567
3.0.5 2,759
3.0.2 413
3.0.3 167
3.0.0 73
3.0.6 24
3.0.4 24
3.0.0-alpha9-dev 13
3.0.0-dev 11
3.1.0-dev 3
3.2.0-dev 2
3.0.0-alpha7-dev 2
3.0.0-alpha3-dev 2
3.0.0-alpha6 1
3.0.0-alpha17-dev 1
3.0.7-dev 1
Country Host Count
United States 2,321
Germany 693
Japan 552
China 424
Czechia 353
United Kingdom 287
France 204
Russia 188
Canada 177
Netherlands 167
Italy 114
Poland 111
Australia 105
Singapore 104
India 80
Finland 79
Hong Kong 78
Brazil 62
Taiwan 57

Identifying OpenSSL 3.x hosts using Censys can be done by using the CPE identifier: “services.software.uniform_resource_identifier=’cpe:2.3:a:*:openssl:3.*’”. Censys ASM customers can use the inventory search term: “host.services.software.uniform_resource_identifier=”cpe:2.3:a:*:openssl:3.*”

Additionally, we have created an interactive dashboard for reporting on servers identified as running a version of OpenSSL greater than or equal to 3.0.0. As more information becomes available about the vulnerability in question, we will update this post along with any new features that need to be added to the dashboard.

Attack Surface Management Solutions
Learn more