Effectively Preparing for the OpenSSL 3.x Vulnerability
Update (November 1, 2022): Akamai content delivery over HTTP and HTTPS is not impacted by this vulnerability as the servers are using a nonimpacted version of OpenSSL. In addition, Akamai systems utilize industry-standard stack protection mechanisms that would mitigate the described attack vector. Akamai is patching any potentially affected internal systems but we do not anticipate that these efforts will lead to downtime for our customers.
On October 25, the OpenSSL project team announced a security fix for a critical vulnerability in OpenSSL version 3.x. The patch is scheduled to be released on November 1, 2022, between 13:00–17:00 UTC.
This announcement has made a lot of noise because of the extensive use of OpenSSL. With this article, we are hoping to cut through the noise and provide background and tips for how to detect and mitigate the threat without speculation. The first part of the post will outline OpenSSL and the scope of the vulnerability. The second part will describe how OpenSSL is used in applications and will provide tools to detect vulnerable assets. Feel free to jump straight to these utilities, if you prefer.
Note: This blog post covers an evolving incident and will be updated as more information is gathered and the fix is released.
What is the scope of this vulnerability?
This vulnerability caused concern in the security community because it is unusual for the OpenSSL team to rate a vulnerability as critical, which was later downgraded to "High." Since the introduction of these vulnerability labels after Heartbleed, (a vulnerability leading to a memory leak and possible key disclosure) there has only been one other, CVE-2016-6309 which was categorized as "Critical."
According to the OpenSSL team requirements, in order to be rated as critical, a vulnerability affects common configurations and is likely to be exploitable. An example of such vulnerabilities might 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.”
Considering how common the OpenSSL library is, a vulnerability in it can be harmful. However, although awareness is necessary, there is no reason for panic just yet. OpenSSL is very common, but its most widespread version is 1.X.X, and the vulnerability affects only OpenSSL versions 3.0.0 and above (released only in September 2021). Therefore, the vulnerability will probably be less common than the distribution of the OpenSSL library itself.
We have executed our detection tools on some of our managed networks, and learned the following:
Approximately 50% of monitored environments had at least one machine with at least one process that depends on a vulnerable version of OpenSSL.
Of those networks, the percentage of machines in the network that had some dependence on a vulnerable OpenSSL version ranged from 0.2% to 33%.
The median coverage was 6.1% and the mean was 11.3% with a standard deviation of 11.6%.
Those statistics don’t take into account nonvulnerable OpenSSL usage. The only metric is machines with at least one process that depends on a vulnerable version of OpenSSL (3.0–3.6). Nor other processes running on the same machine were taken into account.
What is OpenSSL?
OpenSSL is an open source software toolkit, and as such, OpenSSL releases are basically source code releases. What it means for detection, though, is that there are a plethora of ways in which an application can load or rely on OpenSSL, hence the criticality of the vulnerability.
First, we need to define the three components of OpenSSL.
libcrypto — a cryptographic library with implementation of many protocols (e.g., AES, RSA, ChaCha, etc.)
libssl — a library implementing all TLS protocols up to TLSv1.3
openssl — a command line utility for various operations (e.g., generating certificates)
For an application to rely on OpenSSL, it has to call some code logic of either libcrypto or libssl (openssl itself is an application that relies on those two).
Mitigating the OpenSSL vulnerability
The first step of mitigating the OpenSSL threat is to detect vulnerable assets. Although this advice is common, it is rarely accompanied by practical methods. We provide a list of known vulnerable applications (below), as well as a general method to find vulnerable applications in your network.
Segmentation — a pre- and post-patch mitigation
Although patching might not be possible immediately, as most dependence on OpenSSL comes from vendors’ software (who need to apply the fix themselves), we can still leverage the visibility we can get from detection. We can use segmentation and routing to reduce the spread that an attacker might have by abusing the vulnerability.
We can impose further restrictions on internet-facing assets, in the form of a (stricter) DMZ.
We can create more segmentation across the domain, so that a breached internal machine can’t be used to propagate to the entire network. This can also be used to reduce the attack surface of a vulnerable machine to only the part of the network with which it actually needs to communicate.
Furthermore, we can leverage this visibility and detection to create a patching action plan, and to ensure that nothing is skipped. After patches are released and the patching process is completed, we can rerun the detection logic and compare the results. Ideally, we won’t have any vulnerable machines left.
What known applications are vulnerable?
BoringSSL (which is used in Google Chrome) and LibreSSL are two libraries that are based on the OpenSSL code and are not yet affected by the upcoming vulnerability.
Different Linux distributions often ship with the OpenSSL library. If you run a Linux environment, you may want to check if you are using one of the following versions, which are shipped with the vulnerable OpenSSL.
Red Hat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
If you’re using a Linux distribution that is not on the list, you are not guaranteed safety from vulnerabilities. If you have actively updated the library (as part of a package manager’s upgrade command, for instance), you will be vulnerable, too. You can type “openssl version” in your terminal to output the library’s version.
Docker has also published their advisory for the upcoming release, in which they estimate that about 1,000 image repositories could be impacted across various Docker Official Images and Docker Verified Publisher images. This includes images that are based on variations of the Linux distributions mentioned above.
There are also some frameworks that might be affected. Node.js v18.x and v19.x are using OpenSSL 3 and, therefore, are assumed to be affected by the vulnerability. They will announce any new updates in this blog post.
Another programming language that made developers skip a heartbeat is Golang. Libraries in Go binaries are statically linked, which might have required Go developers to recompile their software. When the Golang team announced new minor releases that included security fixes on the same date as the upcoming OpenSSL patch, people linked the two and assumed they were related. Don’t worry: This was a false alarm. Golang’s releases are unrelated to the upcoming vulnerability.
The list of vulnerable applications is likely to grow during the next few days, and we will update this post accordingly. The next sections will provide detection methods and tools to help you figure out which applications in your environment use OpenSSL 3 and are thus vulnerable as well. If you prefer, you may jump straight to the detection mechanisms.
A general method for detecting applications using OpenSSL 3
Note: This section presents the internal details of how an application uses OpenSSL. If you’re simply interested in detection, you can jump directly to our YARA rules or OSQuery queries.
OpenSSL can be linked to an application both statically and dynamically. With static linking, OpenSSL’s source code is included as part of the application code, and both are compiled together into the same binary. With dynamic linking, OpenSSL is compiled separately into a shared library (libssl.dll and libcrypto.dll on Windows; libssl.so and libcrypto.so on Linux). The application code then has references into the shared library, and those are resolved by the operating system when it loads the application.
How does this translate into detection? Practically, a method to detect statically compiled binaries will suffice. Why? Because if a running application dynamically loads OpenSSL, or even if it dynamically loads a library that in turn dynamically loads OpenSSL (and so on and so on), eventually some statically compiled OpenSSL library will be loaded. Since all dynamic loading occurs in the context of the same process, we just have to go over the list of libraries loaded into each process, and find the statically compiled one.
So, we need to figure out what a statically compiled OpenSSL looks like. Luckily, it is fairly straightforward. All static compilations of OpenSSL contain a version string, that looks like this: OpenSSL 3.0.6 11 Oct 2022, where 3.0.6 is the version number. Detecting this string is pretty simple, and can be done with either Regex or YARA.
This, however, might not be a perfect match. Since OpenSSL is an open source code, users can easily change the versioning logic to suit their needs (and thus cause our detection to miss). We’ve only seen this happen once (with Cisco, who used the string CiscoSSL 1.1.1k.7.2.225 instead), but it might happen with other vendors as well.
What do I do now?
Although we won’t know much until the fix is released, there are some things defenders can do preemptively to be prepared for the patch. Our team has built some utilities that you can run in your environment for visibility and ease of mitigation. Akamai Guardicore Segmentation customers with the Insight feature enabled can easily run this logic in their environment.
YARA
The main rule we can write is for the string we mentioned above. For brevity, we’ll limit our detection to only the actual versions of OpenSSL that are impacted by the release, but we can easily modify our criteria.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
In case we don’t want to rely on the string, we can also look for the main application that relies on OpenSSL, but parse the executable’s imports. This is a less foolproof method, though, and should be treated as such.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
Using the above queries, we can also leverage osquery’s YARA table, to run those rules on all running processes.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
Of course, you can also put in the other YARA rules we mentioned, or add more or fewer filters to narrow or broaden the number of files checked.
Summary
The OpenSSL team has adopted an interesting approach by informing security teams of the upcoming fix release. This announcement has given defenders time to prepare and map critical assets that are queued for patching. In this blog post, we attempted to assist in doing exactly that — locating the applications and assets that will require addressing on the day of the patch.
This is an evolving story and we will update this blog post as new information is released, so be sure to check back here for updates. You can also follow us on Twitter for more real-time updates.
