Last week a CRITICAL vulnerability in OpenSSL was pre-announced to give organizations a head start in coming up with a playbook for how to address the highest severity OpenSSL vulnerability since Heartbleed in 2016. A lot of effort was put in by vendors and organizations alike to come up with a proper response, while eagerly awaiting the announcement on November 1. When the information was released, the vulnerability was downgraded in severity and split into two (2) CVEs (CVE-2022-37786 and CVE-2022-3602), decreasing the impact on products that leverage OpenSSL 3.x. These two (2) OpenSSL vulnerabilities have been addressed in OpenSSL 3.0.7.
Knowing more about the vulnerability allows us to dissect why it is not as industry-changing as Heartbleed was 8 years ago.
First, we need to understand how the vulnerabilities work. These two (2) vulnerabilities are within the X.509 certificate verification, specifically with name constraint checking. A specifically crafted email address can trigger the exploit but requires a certificate authority (CA) to have signed the malicious certificate or the application to continue the certificate verification despite it failing to construct a path to a trusted issuer. In other words, the CA must either trust the malicious certificate already or the application, or the end user needs to bypass security best practices to trust it themselves. While rare, this can be seen in some instances when private certificates are in use. As of this writing, no working exploits are available for these vulnerabilities. There are working proof of concepts (PoC) that cause OpenSSL to crash; however, they do not lead to remote code execution (RCE).
The second leading factor in the reduced impact of these vulnerabilities is the limited adoption of OpenSSL 3.0 in the wild. OpenSSL 3.0 was released on September 7, 2021, and has been in the market for roughly 14 months. Upgrading from the previous version (1.1.1) is significant and likely not to be completed quickly by the majority of products in the market. Planning for a major upgrade such as this requires considerable testing to ensure quality and security are maintained.
Qualys pulled anonymized data from our global customer base and found that 15K organizations had varying versions of OpenSSL in their environments. Of those, only 10%, or 1.5K organizations, were running a vulnerable version of OpenSSL (between 3.0.0 to 3.0.6). From an asset-level view, less than 0.1% of servers use a vulnerable version of OpenSSL. Of the 14M assets with OpenSSL, only 13K were found to be running version 3.x. Even if this was comparable to the next Heartbleed, limited adoption of OpenSSL 3.x significantly reduces the overall risk posed across the industry.
What is more concerning for organizations is the amount of end-of-life OpenSSL versions. Within the data analyzed by Qualys, 82% of OpenSSL instances were found to be end-of-life (EOL) or end-of-support (EOS).In the various OpenSSL project versions, there are over 200 vulnerabilities. Seven (7) of these have a publicly available weaponized exploit but none since Heartbleed and POODLE in 2014. Although only seven (7) vulnerabilities have working exploits, there are 32 additional which have proof of concept (PoC) exploit code available but are not yet reliably working as an exploit. The theory is some are being privately exploited or researched actively to determine how to successfully execute exploitation.
Given the wide adoption of OpenSSL and its criticality in protecting the privacy of the digital world, it is of utmost importance to reduce the attack surface that bad actors interact with when attempting to get inside an organization’s environment. The Qualys Cloud Platform allows organizations to understand the full scope of their exposure to OpenSSL-related risk. We hope you leverage our insights as an actionable playbook for understanding your unique attack surface and how to prepare for events like this in the future.
The OpenSSL project released OpenSSL version 3.0.7, which patches vulnerabilities in current versions of OpenSSL. What does this mean for you, and how can Qualys help?
Join us on Thursday, November 3rd at 10:00am PST, as Director, Security and Threat Research Bharat Jogi and Director of Product Management, Eran Livne, answer questions from attendees and covers how customers can leverage the Qualys Cloud Platform to manage and patch two critical vulnerabilities (CVE-2022-37786 and CVE-2022-3602) in versions of OpenSSL 3.0.0 – 3.0.6. Subsequent on-demand sessions are also available on Friday, November 4th at 10:00am for European and Asia-Pacific regions.
From this web event, you will come away with the following:
- The latest minute-to-minute information on the OpenSSL 3.0.7 announcement,
- What the OpenSSL 3.0.7 means for your environment, now and into the future,
- How Qualys VMDR, Patch Management, and CyberSecurity Asset Management are equipped to help you identify and deploy the OpenSSL version 3.0.7 solutions.