The OpenSSL project has announced two security vulnerabilities tracked as CVE-2022-3602 and CVE-2022-3786. The good news is that these vulnerabilities are unlikely to facilitate remote code execution as originally anticipated, and only OpenSSL version 3.0.0 and later are impacted. The bad news, however, is that even though the remote control is unlikely, it’s still possible.
To learn how to protect your ecosystem and your third-party vendors from falling victim to a data breach or a ransomware attack from these OpenSSL vulnerabilities, read on.
What are the OpenSSL Vulnerabilities?
The OpenSSL project has announced two vulnerabilities affecting OpenSSL version 3.0.0 through to version 3.0.6, with version 3.0.7 containing the critical security fixes for these vulnerabilities.
- CVE-2022-3602 - This is an arbitrary 4-byte stack buffer overflow. Exploitation may lead to system crashes and remote code injection (RCE).
- CVE-2022-3786 - This vulnerability can also be exploited to impact buffer overflow, triggering a denial of service.
Learn more about security vulnerabilities >
How can these Vulnerabilities be Exploited?
Both vulnerabilities can be exploited if the following requirements are met:
- An X.509 certificate is trusted and accepted by the server or client
- An email address stored in the certificate that passed is modified to deliver the exploit.
Both scenarios can potentially result in a denial of service attack (DoS attack) at best and remote code injection (RCE) at worst.
Despite being downgraded from a critical rating, these OpenSSL vulnerabilities still present a significant security risk. UpGuard cybersecurity analysts have discovered over 10,000 websites running vulnerable versions of OpenSSL.
The Open SSL vulnerabilities could facilitate malware injections, meaning that every website running a vulnerable version could potentially suffer a data breach or ransomware attack.
Every website running a vulnerable version of OpenSSL risks suffering a data breach or ransomware attack.
Who is Impacted by the OpenSSL Vulnerabilities?
The two OpenSSL vulnerabilities (CVE-2022-3602 and CVE-2022-3786) impact versions 3.0.0 through to version 3.0.6, with OpenSSL 3.0.7 containing the security fixes for these vulnerabilities.
OpenSSL versions prior to 3.0.0 are not impacted.
If an immediate upgrade to the patched version of OpenSSL isn’t possible, the impact could be mitigated by disabling TLS client authentication (if you have TLS servers) until security fixes can be applied.
How to Detect Vulnerable OpenSSL Versions in your Ecosystem
A vulnerable version of OpenSSL could impact your IT ecosystem in three primary ways:
1. At a system level
System-level instances are the easiest to detect. To do this, run the following command and check if your system is running a version within the vulnerable range (3.0.0 - 3.0.6)
% openssl version
2. Used by Software via Dynamic Linking
In this scenario, your system could be impacted by vulnerable third-party software. You can detect if a solution is running a vulnerable version of OpenSSL by scanning its OpenSSL library (a DLL file on Windows and an SO file on Linux).
The following scanners from Github can be used for each operating system.
The OpenSSL version command above could also work for this scenario.
3. At a Statically Linked level
This level of impact is the most difficult to detect. Statically linked software compiles all Open SSL libraries in the main executable software. The are two methods of confirming whether your business is impacted at this level:
- Compare your vendor list against a list of unaffected software solutions - see this example from GitHub
- Contact all of your software vendors to confirm their susceptibility to this vulnerability type (see below for recommendations on how to address OpenSSL security risks with third-party vendors collaboratively)
How to Protect Your Third-Party Vendors From these OpenSSL Vulnerabilities
Detecting and remediating emerging vulnerabilities like these is most frustrating for the third-party attack surface. The following process will help simplify this effort.
1. Identify all Potentially Impacted Vendors
Vendors could be impacted by domains running vulnerable versions of OpenSSL or with software running vulnerable OpenSSL libraries. The first risk is much easier to detect. This can be done with UpGuard’s vulnerability scanner.
UpGuard can rapidly confirm whether your business is impacted by domains running vulnerable versions of OpenSSL.
See UpGuard’s OpenSSL vulnerability scanner in action >
Vulnerable third-party software is harder to confirm, especially if you work with a high volume of vendors. To expedite the scanning methods outlined above, send a security questionnaire to all your vendors to request that they assess their own software for these OpenSSL vulnerabilities.
A questionnaire tailored to these new OpenSSL risks can be easily created with UpGuard’s custom questionnaire builder.
Learn about UpGuard’s custom questionnaire builder >
2. Assign Owners for all Impacted Assets
The combination of results from security scans and questionnaire responses will allow you to map the impact of these vulnerabilities on your organization. For each impacted asset, assign an owner who will take ownership of remediation efforts.
3. Prioritize Most Vulnerable Assets
The remediation of critical assets - internet-facing assets and assets mapping to sensitive resources - should be prioritized. A vendor tiering strategy makes the prioritization of critical third-party vendors much easier.
Learn more about vendor tiering >
UpGuard Can Help You Secure Your Environment Against OpenSSL’s Vulnerabilities
UpGuard offers a host of features to help you manage the complete cybersecurity lifecycle of OpenSSL’s two new vulnerabilities:
- A vulnerability scanner - Rapidly confirm whether your business is impacted by domains running vulnerable versions of OpenSSL.
- Custom questionnaire builder - Build custom questionnaire specifically tailored to these new OpenSSL security risks to assess third-party impact.
- Remediation planner - Prioritize the remediation of all critical assets and immediately track the impact of these efforts on each vendor’s security ratings.
