After warnings were issued, a critical vulnerability discovered in current versions of OpenSSL affecting almost every organisation, will have a patch released today – so patch as soon its available experts say!
If you are unaware, OpenSSL is a widely used software library by companies to enable secure network connections and is available for Linux, Windows, macOS, and BSD systems. OpenSSL lets users perform various SSL-related tasks, including Certificate Signing Request (CSR) and private keys generation, and SSL certificate installation.
The Open SSL Project defines a critical vulnerability as affecting:
‘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’
Remember, if you’re using HTTPS, chances are you’re using OpenSSL and need to patch this vulnerability.
How not to perform an incident response – OpenSSL CVE-2022-3602
Over the past several days, there has been both anticipation and concern over a new vulnerability in OpenSSL. Some details of this vulnerability were leaked on Oct 28th, and there was an expectation that this vulnerability would have a “Critical” rating. Along with the leak was a statement that a patch would be available on Nov 1st. We now know that this isn’t a critical vulnerability, but rather a “high” one. We also know that there are two vulnerabilities in the patch.
What happened?
Not surprisingly, a vulnerability in OpenSSL is going to gather industry and perhaps even media attention. With the initial rating of Critical, we saw media attention ramp up. This media attention realistically served two purposes. First, it focused attention within both the technical and non-technical ranks of organizations who might be using OpenSSL. Second, it alerted the cyber-attacker community that there is something for them to focus their R&D efforts on – and that there might be a large target audience for such an attack.
Much of this chaos and increased software supply chain risk stems from the reality that publication of the existence of a vulnerability occurred before any patches were available. That then led to speculation, and in all likelihood some poor decision making by those attempting to protect their systems from an unknown attack as part of their response to what they believed to be a major incident.
What should have happened?
It’s important not to downplay vulnerability management efforts, but perspective and pre-defined processes are key elements in incident response management. In the early phases of the media and community reaction to what we now know as CVE-2022-3602, I was recommending that organizations perform a proactive scan of all of their software using tooling called Software Composition Analysis (SCA). SCA tooling scans the source code of an application and creates a Bill of Materials (BOM) for that application. If you don’t have access to the source code, major SCA vendors all have an option to scan binaries to create that BOM.
From an incident response perspective, you want to scan all the software your organization uses, regardless of its source or role. That includes commercial software, stuff that was freely downloaded, mobile applications and software like firmware that is included with hardware. Having a current, accurate and complete BOM for all software is a key to responding quickly to an incident like what we were expected from CVE-2022-3602.
How does a BOM benefit incident response?
Assuming you have a BOM for all software, you then can query each BOM and find out if the vulnerable version of the software is referenced by or linked into an application. If it isn’t then there is nothing else to do. If it is, then there is some triage work to be done. To make things simple, for the pre-disclosed OpenSSL vulnerability, you could simply include in the list of applications to triage anything that references any version of OpenSSL. We now know that the impacted versions of CVE-2022-3602 are 3.0.0 to 3.0.6 which means that the triage list could be further filtered to only those versions of OpenSSL.
With a list of applications to triage in hand, the next step is to identify where the patch for CVE-2022-3602 should come from. While SCA tooling can help solve this problem to a degree, knowing what is being triaged is far more useful. For example, if you know you are triaging a web application running on a Linux VM, then the OpenSSL patch should come from the distro that created that Linux version. This paradigm holds true whether you’re dealing with VMs, containers, firmware, mobile applications, serverless functions, or any other deployment context.
Decreasing time to identification and remediation
Obviously not all potential providers of a patch will issue their patch at the same time, but when the disclosure of a vulnerability is held under embargo until patches are ready from a majority patch sources, everyone is playing on a level playing field. Tooling like SCA can greatly assist in reducing the time to identify impacted applications and deployments. If you’ve heard about the concept of an SBOM, it provides exactly the same value as a BOM from an SCA tool. But as with SCA tooling you need to know how to use it for impact identification.
Time to remediation will of course be subject to how long it takes to validate patches and then roll them out. By shortening the time to identification and focusing triage efforts to only systems and applications directly impacted by a vulnerability, remediation becomes quicker and more efficient.
Through the usage of SCA tooling, no longer are you sending emails to suppliers asking “Tell me if your company is vulnerable to OpenSSL”, but instead you’re a proactive part of the solution and asking “I see that Awesome Acme Software may have exposure to CVE-2022-3602. Can you provide a timeline for patches and interim mitigation steps we can take?”
On a scale of 1 to 10 the Heartbleed vulnerability was an 11; Heartbleed was exposed by default on any software that used a vulnerable version of OpenSSL, and it was very easily exploitable by attackers to see cryptographic keys and passwords stored in server memory.
The two vulnerabilities just reported in OpenSSL are serious but not of the same magnitude. Vulnerable servers would need to be requesting client certificate authentication, which is not the norm, and vulnerable clients would need to connect to a malicious server, which is a commonplace attack vector anyhow.
Nobody’s hair should be on fire about these two vulnerabilities, but they are serious and should be handled with appropriate speed and diligence.
If you don’t already know what open source components are in your software, consider implementing Software Composition Analysis (SCA) posthaste. Once you know which software has a vulnerable version of OpenSSL, you can make a plan to update your software in priority order. Simultaneously, work with your vendors to get updates to the software you acquire.
For organizations that are already managing software supply chain risk, this update of OpenSSL should be business as usual. Less prepared organizations should see this as an opportunity to start building software supply chain risk management into their processes.
This OpenSSL vulnerability disclosures (and fixes) are, thankfully, not nearly as bad as all the speculation would have led us to believe. Vendors and operators should update their dependencies on OpenSSL to 3.0.7 when it’s practical to do so, respecting normal change control procedures and taking into account the specific risk profile for those organizations. For most people, this is not actually the emergency situation we were all expecting.
Specifically, implementations that are configured for mutual authentication, where both the client and the server are providing OpenSSL-provided certificates for authentication, should definitely be fast-tracking this update. But, this is an unusual use case, so if you don’t know if you are supporting that or not, you’re probably not. For most installations, it’s okay to take your time with this one.
When OpenSSL first announced this patch was coming, I immediately thought back to major vulnerabilities of the past, such as Heartbleed and Log4j. However, this vulnerability has been downgraded from critical to high severity by OpenSSL, mainly because it doesn’t cause data leakage and the attack vector is relatively small. But this doesn’t mean we’re off the hook as the risk of DDoS attacks is still high if servers request client authentication, and a malicious server connects.
Servers that are on OpenSSL 3.0 and are using Client Authentication in a non-trusted environment – such as public facing servers – should patch immediately to ensure they don’t fall victim to DDoS attacks. Servers running in trusted environments should still be patched, but the urgency here is reduced as attacks won’t be effective unless a threat actor manages to infiltrate your network.
With the release of details related to the OpenSSL Email Address Buffer Overflow vulnerabilities CVE-2022-3786 and CVE-2022-3602, the severity was downgraded too High from Critical. While we see no evidence of this being exploited in the wild and is significantly less widespread than the pre-announcement expectations, there is a lot of attention on OpenSSL and this is a complicated issue to remediate. These types of vulnerabilities can evolve and still should be patched with urgency to eliminate the potential holes it creates, especially considering the public facing nature of many implementations. There are many proofs of concept code examples being published today and you can expect some changes to emerge in what is currently known about the vulnerability even if it never reaches the Critical level that was originally stated.