OpenSSL vulnerability CVE-2022-3602: 3 steps to patching
A new vulnerability (CVE-2022-3602) has been disclosed in OpenSSL, an open-source cryptography library that provides cryptographic APIs used to generate cryptographic keys, provide encryption, hashing functions and other security and privacy capabilities in a variety of commercial and internal applications.
OpenSSL is used in applications that are deployed on-premises, in the cloud, in SaaS apps, on endpoints, servers, in IoT or OT environments, and many other places.
This new OpenSSL vulnerability is far from being as severe as the Heartbleed Bug, the only other critical vulnerability in OpenSSL since 2014, that allowed the system operating a web server to receive ‘Heartbeat’ requests from remote machines that were utilizing it and ultimately lead to a remote code execution (RCE) flaw.
Here’s why :
· The severity rating is lower. The “Heartbleed” vulnerability was classified as “critical” since it ultimately allowed for a remote code execution (RCE), similar to the Log4J vulnerability. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors have led this to be downgraded to HIGH, since there are no RCE flaws exploitable that have been confirmed to this day for this vulnerability.
· The surface of attack is much smaller. The current vulnerability only concerns specific OpenSSL instances (running OpenSSL version 3.0.0 to 3.0.6) parsing malicious X.509 certificates crafted with special unicode characters in the email field and signed by a valid certificate authority (CA). In fact, sites like Wiz are reporting that this vulnerability will affect only 1.5% of OpenSSL instances in most environments.
· Exploitability is quite complex. As cybersecurity firm Rapid7 pointed out, “exploitability is significantly limited,” as the flaws occur “after certificate verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.”
Nevertheless, this vulnerability could potentially lead to a Denial of Service (DoS) attack on affected resources and should thus be treated seriously and patched as soon as possible.
Patching recommendations:
1. Check your application instances and runtimes (such as node.js) that use Open SSL version 3.0.0 to 3.0.6 and patch it to version 3.0.7.
2. Run a scan in your company’s source code repositories to identify any repository using affected versions of OpenSSL.
3. Prepare to check 3rd party vendor status through a managed service solution such as SupplierShield™ services.
Many 3rd party applications use OpenSSL and you will want to query vendors for applications they use, whether on-premises or SaaS, in order to understand how they are affected and whether they’ve patched it.
More information:
CVSS Base score: 7.5 (High)
NIST reference page: https://nvd.nist.gov/vuln/detail/CVE-2022-3602