CVE-2022-3602 and CVE-2022-3768
On November 1st 2022, after teasing the main show the week before, OpenSSL released their advisory describing two risks to OpenSSL 3.0.0 – 3.0.6. This was originally teased as a Critical level alert, which would have been the first Critical since 2015, however this was downgraded to a High owing to what OpenSSL describe as “mitigating factors”.
The two vulnerabilities are based on buffer overflows on the Email Address field in an X509 certificate. By crafting the email address specifically, an attacker could overflow and control 4 bytes on the stack of the target system CVE-2022-3602, or by padding the email address with a specific character the attacker could overflow the buffer and crash the system CVE-2022-3768. These two vulnerabilities could, on their own, seem like they would break everything everywhere all at once, however those mitigating factors are quite important.
The first mitigating factor is that these two vulnerabilities require a level of interaction from the client, or from the server being targeted. In both vulnerabilities, a client who is running OpenSSL3.0 would have to visit a malicious server which is hosting a malicious x509 certificate. Whilst this is not outside the realms of possibility in everyday operations, there would still need to be a user who clicks on a link or opens a document in order to get compromised. Whilst this is quite common, there are easier ways that using an OpenSSL vulnerability to run a Remote Code Execution.
From the server side, the server being targeted would have to ask for a client authentication certificate from a malicious client. This is not normal configuration for internet facing servers and is more likely to be used in on premise devices. At which point you would need to have a malicious third party close enough to target a network.
Another large mitigating factor for these vulnerabilities is that the certificates being used would have to be signed by a trusted Certificate Authority (CA), or the application would need to continue without being able to establish a path to a trusted CA in order to trigger these overflows. This is a non-trivial task for most attackers, although there may be ways using more open signing authorities, there is a high likelihood that these providers are going to be auditing the certificate signing requests in order to find these email address fields which may be malicious.
There are also not a large number of systems running OpenSSL3.0. The number is definitely not zero, but to put it into perspective, two of the main non-Windows server operating systems, RHEL and Ubuntu, have only just incorporated OpenSSL3.0 into their platforms this year. RHEL 9 was released in May 2022, and Ubuntu 22.04 was released in August 2022. This means that a lot of system admins may not have had a chance to upgrade to these branches, and these are just the most recent LTS versions, so there may not be a need to upgrade. However, it should be noted that these versions may be being used to build Docker containers, and other containerised applications.
Finally, OpenSSL have not spotted these vulnerabilities being exploited in the wild, so this is not like an out of band patch where there is an active attack campaign. Despite this, it is still recommended to patch systems running OpenSSL3.0.0-3.0.6 up to 3.0.7.
Vectra does not have a specific detection, or saved search deployed to find potential uses of these specific vulnerabilities, however, as with all vulnerabilities targeting infrastructure or clients, the vulnerability is only the first infection vector in an ongoing compromise. If a client or server were to be compromised using the above techniques, then it is likely an implant or trojan would be deployed. In these cases, customers could expect to see the following detections:
- Hidden DNS Tunnel
- Hidden HTTP Tunnel
- Hidden HTTPS Tunnel
- External Remote Access
- Vectra Threat Intelligence Match
- Multi-home Fronted Tunnel
These would cover malicious tools and implants C2 behaviour regardless of the vulnerability used to deploy it.
As this would be part of an ongoing campaign there is an expectation that lateral movement would also occur, in which case Vectra provides coverage for the following techniques:
- Suspicious Remote Execution
- Privilege Anomaly: Unusual Service
- Privilege Anomaly: Unusual Account on Host
- Suspicious Remote Desktop
- Privilege Anomaly: Unusual Service – Insider
- Privilege Anomaly: Unusual Trio, Privilege Anomaly: Unusual Host
- Privilege Anomaly: Unusual Service from Host
- Suspicious Admin
Regardless of the tool being used, these detections are designed to provide coverage for the behaviours attackers use post-compromise to accomplish their ultimate objectives within your environment.