5 ways to limit your exposure to the new critical OpenSSL vulnerability

About OpenSSL

Everyone depends on OpenSSL. OpenSSL makes it possible to use secure Transport Layer Security (TLS) on Linux, Unix, Windows, and most other operating systems. It's also what is used to lock down almost every secure communication and networking application and device on the market today. Because of its ease of use and, most importantly, because it's open-source (so, free), over time it has become the industry standard.

What is the OpenSSL Vulnerability

On October 25, 2022, the OpenSSL Project disclosed a new "critical" vulnerability in the library affecting OpenSSL versions 3.0.0 and above. They also announced the release of OpenSSL version 3.0.7 on November 1, 2022, which is intended to fix this vulnerability, as well as any application with an embedded, impacted OpenSSL library. Other than it being "critical", no additional information was provided.\

There's Good News & Bad News

The bad news

The OpenSSL project has dubbed this a "critical" vulnerability. What does "critical" mean? 

According to OpenSSL, a "critical" vulnerability affects common configurations and is also likely to be exploited. 

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.

In other words, a critical vulnerability may be abused to disclose server memory contents, and potentially reveal user details, and could be easily exploited remotely to compromise server private keys or execute code remotely. 

Historically, OpenSSL vulnerabilities have had a widespread impact. Heartbleed (CVE-2014-0160), another critical severity OpenSSL vulnerability, may be the most famous and infamous software vulnerability ever. The bug was published in 2014. At the time of its discovery in 2014, experts from Netcraft estimated that the flaw affected 17% of SSL web servers or "half a million widely trusted websites" that took months to be secured.

The good news

OpenSSL v 3.0 is only a year old and is still significantly less mainstream than OpenSSL v1, which is not impacted by this vulnerability. 

Why you should be concerned

Usually, when an open source releases a fix to a critical vulnerability it is very easy to locate the piece of code that is vulnerable and try to build an exploit. It is usually done by looking at the last commits done in the version that is fixing the vulnerability and narrowing the relevant code blocks to a low number of potential cases.    

Five things you can do to limit your exposure to the OpenSSL vulnerability

Here is what we expect to learn from the announcement on Tuesday:

• The severity of the problem ( remote code execution, data leakage DDOS or more)
• The probability of the exploit.
• Is the vulnerability in a code that is on by default or is it used in specific cases/flags?
• Is it only scoped to the selected version?

However, patching work cannot begin until this information is made available. Here are five protective measures you can take right now to reduce exposure:

Map all of your assets using versions of OpenSSL 3.0.x 

1. Map in-house developed applications using versions of OpenSSL 3.0.x  by parsing their dependencies list stored in their source repositories (GitHub, GitLab).
2. Map all third-party applications using versions of OpenSSL 3.0.x  by reading their SBOM.

Prepare a patch or block program for each one of these applications

1. If you have direct dependencies in your code, prepare the engineering team to release a fix on November 1st with version 3.07 .
2. If you have dependencies in the middleware (and operating system, e.g. Apache or Linux version) try using an older OpenSSL version below version 3.0.0 until version 3.0.7 is released this Tuesday. 
3. If you have vulnerabilities that cannot be patched, adding NGINX or other proxies that do not use open SSL 3.X will reduce the attack until all of the applications are fully patched.

As there is no understanding of what the network footprint is going to be, use IPS/WAF to block signatures once released. Please note that those protections are usually easy to bypass with simple and known tricks  

Three ways OX can help you

Use Ox Security's free version to quickly scan your system:

• Confirm that every artifact in production is mapped to a known and trusted build.
• Pinpoint all relevant places in your code that will require a version upgrade.
• Pinpoint vulnerable infrastructure that will not have a patch in the short term. Understand the exposure and alternatives to patching, like version rollback or proxy deployment recommendations.