Update: On November 1st the OpenSSL project maintainers released their fix for the vulnerabilities. There were two vulnerabilities discovered. After engagement with experts from the industry, it was decided to reduce the severity classification to HIGH instead. The reason for the severity update lies behind the probability of gaining remote code execution in modern operating systems. However, the OpenSSL project is integrated into many operating systems including some with less advanced security mitigations that may allow attackers to gain remote code execution. Hence, in spite of the severity degradation, it’s still very important to update the OpenSSL library to the latest version.
OpenSSL has angekündigt a critical fix in version 3.0.7 to be released Nov 1, 2022. It means that on Tuesday Nov 1 the race will start between those who patch and those who exploit. In this blog post, we’ll summarize all the necessary information required to make sure you can win this race and keep your software supply chain risk-free.
OpenSSL – The Popular TLS Implementation Library
OpenSSL is an open-source implementation of the SSL and TLS protocols, built for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used by internet servers, HTTPS websites, and a vast number of services that need cryptographic functionality – operating systems (e.g., Windows, Linux. macOS), client-side software, web and email server software (e.g., Apache, Nginx), network appliances (e.g., Cisco, Juniper), industrial control systems, etc.
The immanent dependency of software security on OpenSSL became most evident in 2014 when the critical Heartbleed bug (CVE-2014-0160) was published and wreaked havoc among the entire internet industry, as attackers could covertly eavesdrop on internet communications, steal data from services and users, or impersonate services. Half a million widely trusted websites were found vulnerable.
Critical Security Fix Pre-Announcement
No details have been shared with the public about the vulnerability yet. The OpenSSL project decided to give the heads-up about the upcoming patch – 5 days in advance – to give organizations enough time to inventory their software and be prepared to fix all instances as soon as the patch is released. The release will be available on Tuesday, 1st November 2022, between 1300-1700 UTC. Once released, malicious actors will quickly learn how to exploit the weakness, and users will have to act ASAP to upgrade their systems, especially if the exploit won’t require significant effort. OpenSSL defines a critical flaw as one that enables significant disclosure of the contents of server memory and potential user details, vulnerabilities that can be exploited easily and remotely to compromise server private keys.
SBOM To The Rescue
Until a patch is released, all you need to do is scan and detect usages of the vulnerable library anywhere in your tech stack and prepare to upgrade. The vulnerability exists in version 3.0 and above. So if you found a product using an older version, that product is not affected.
But wait, is your organization in a position to discover usage of vulnerable libraries quickly and efficiently? Unfortunately, as we learned with recent Log4J vulnerabilities, for the majority of organizations that answer is “no”. Thus the importance of a Software Bill of Material or SBOM. You can read an introduction to SBOMs here and better understand its role in broader software supply chain security solutions.
Anything that communicates with the Internet securely could potentially have OpenSSL built into it. It’s recommended to create a patch plan for two types of software:
#1 – Your Production Pipeline
Inventory all software artifacts that go to production and contain OpenSSL v3.0+. This can be achieved by generating an SBOM for each artifact, scanning the output and looking for the vulnerable library. Once you complete the scan, you’ll have the full list of all artifacts that require patching when the fix is released.
Note: there may also be scenarios where OpenSSL isn’t used inside your artifact, but it exists on the machine on which your software is running, such as an EC2 server running Nginx. In these cases, to be on the safe side, we recommend connecting to the server and running a filesystem search to look for the openssl library. If found, check if its version is 3.0 or above.
#2 – 3rd Party Vendors
Inspect all technologies and services you use in your different environments. It’s important to monitor software products vendors’ advisories, and follow their guidelines to keep your environments safe. Once the OpenSSL releases the patch, vendors are likely to update their customers whether they’re vulnerable and their planned fix timeline.
Legit Security Is Here To Help
Software supply chain attacks have been on the rise and attackers keep looking for weaknesses in CI/CD pipelines to wreak havoc over organizations. The OpenSSL vulnerability could turn out to be similar to the Log4J vulnerability from last year, and it’s important to keep guards in place.
Legit Security is ready to help with guidance and visibility through our SBOM capabilities so that you can navigate this upcoming storm successfully. Contact us at Legit Security. We’ll help anyone – free of charge and with no commitments.
https://www.legitsecurity.com/blog/a-critical-openssl-vulnerability-the-race-between-attackers-and-defenders?utm_source=cyfluencer&utm_medium=influencer_library
