The OpenSSL patch (v3.0.7) is now released (OpenSSL patch v3.0.7 for Vulnerability 2022), and you still have time to assess what are the potentially vulnerable products in your environment. Here’s the link to download the fix. OpenSSL security update is out, with fixes for CVE-2022-3786 and CVE-2022-3602. Vulnerabilities were also downgraded from Critical to High after last week’s hype turned out to be a wet fart. We covered some background about the upcoming vulnerability and attached some tools for detection.
The OpenSSL team has adopted an interesting approach by informing security teams of the upcoming fix release. This announcement has given defenders time to prepare and map critical assets that are queued for patching. In this blog post, we attempted to assist in doing exactly that – locating the applications and assets which will require addressing on the day of the patch. Developers and Security folks are advised to start patching this upcoming vulnerability as soon as it gets announced in order to avoid mass scanning attempts by malicious actors.
Download the fix: Here
OpenSSL is used by vast numbers of applications, operating systems, and devices throughout the internet. Therefore, this vulnerability is likely to be extremely wide-reaching. While the nature and details of the vulnerability are not clear at present, it is likely to rapidly become a target for exploits, resulting in significant risk. Please ensure the correct individuals within your organization are aware of this vulnerability.
OpenSSL released version 3.0.7 to patch CVE-2022-3602 and CVE-2022-3786, two HIGH risk vulnerabilities in the OpenSSL 3.0.x cryptographic library.:
############### Severity: High A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature 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. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
############### Severity: High A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
Don’t hesitate to share with me more details (vendors, software, etc.). Thanks to all the contributors and let me know if you have additional entries. Twitter: @c_glemot
OpenSSL can be linked to an application both statically and dynamically. With static linking, OpenSSL’s source code is included as part of the application code, and both are compiled together into the same binary. With dynamic linking, OpenSSL is compiled separately into a shared library (libssl.dll and libcrypto.dll on Windows, libssl.so and libcrypto.so on Linux). The application code then has references into the shared library, and those are resolved by the operating system when it loads the application.
OpenSSL scan commands:
Powershell – Get-ChildItem -Recurse -File -ErrorAction SilentlyContinue -Path “C:\” -Filter “libssl*”
System-wide – openssl version
Running processes – sudo lsof -n | grep http://libssl.so.3
About OpenSSL Vulnerability (October 25th):
Critical OpenSSL Vulnerability version 3.0 and above: OpenSSL has just announced a critical vulnerability in version 3.x. This access vulnerability requires access to private keys and/or risks remote machine access (RCE). Vulnerabilities that can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations. OpenSSL 3.0.7 update to fix Critical CVE out today 1300-1700UTC. Does not affect versions before 3.0.
Building a SOC: Blog Post
List of vendors and software affected by the OpenSSL vulnerability: Blog Post
Critical OpenSSL Vulnerability version 3.0: Blog Post
Veeam v12 Linux Without SSH And SUDO: Blog PostHardened Repository in Veeam v12: Blog Post
Wasabi Object Storage Usage with Veeam B&R v12: Blog Post
VeeaMover in v12: Blog Post
Ransomware & Cybersecurity with Veeam v12: Blog Post
Why backup directly to Object Storage? Blog Post
Veeam B&R v12 New Features Overview: Blog Post
[REPLAY] Webinar Veeam v12 and Wasabi: Replay
Protect your data with Veeam and Wasabi: Blog post
Wasabi – Object Lock feature spotlight: Blog post
Veeam and the S3-compatible object storage solutions: Blog Post
[PODCAST] VeeamUser Group France #1: Record
Conti initiates their attacks on Backup: Blog Post
Backup with Trusted Repository Storage: Blog Post.
Protect your Backup against Ransomware: Blog Post.