By Securonix Threat Labs, Threat Research: D. Iuzvyk, T. Peck, O. Kolesnikov
Introduction
In early November, OpenSSL released a security advisory detailing two new critical OpenSSL CVEs (CVE−2022-3602 and CVE-2022-3786). Our initial analysis at the time the security advisory was released (see details below) indicated that the impact of the vulnerabilities was likely limited and that remote code execution (RCE) appeared to be non-trivial to accomplish for these.
The updated analysis we performed today further confirms our initial assessment. To the best of our knowledge, there still appear to be no publicly available working exploits outside of the POCs published. Furthermore, our analysis indicates that, due to the nature of the vulnerabilities, the ability to detect all attack vectors reliably outside of checking for vulnerable components can be limited as well.
We will provide updates once we have more information.
Vulnerability overview
A patch released on October 25th referenced fixes for two buffer overflow vulnerabilities in a punycode decoding function which is used when certificates are validated. The new OpenSSL patch v3.0.7 mitigates the buffer overflow issue, however affected versions range from v3.0.0 to v3.0.6. We highly recommend upgrading to the latest version as soon as possible.
A buffer overrun condition can be triggered by the way X.509 certificates are validated. During this validation process, the certificate’s GeneralName values are checked using Name Constraints. Some of these values contain fields such as DNS name, IP address, directory name, and SRVname. In theory, a malformed email address could be included into the “email” field which could cause the buffer overrun condition.
For this vulnerability, successful exploitation requires the usage of punycode present in either the email or DNS name constraint fields. We will dive into punycode a bit more later on.
OpenSSL is fully equipped to handle punycode. When punycode is detected in the proper name constraint, it leverages a separate parsing function which is where the vulnerability exists.
What is punycode?
Simply put, punycode is an encoding standard used strictly for internationalized domain names. Since the use of standard English ASCII characters in domain names became the norm during the days of the early internet, technology that could support additional characters from other languages was never really introduced. Thus, not all Unicode characters available today are able to be used in domain names.
This is where punycode steps in. For example, if you had a domain name comprised of all Chinese characters (菠萝.com), the punycode equivalent would be xn--6p1awe.com. Punycode is easy to identify and will always begin with the “xn--“ prefix.
Proceeding the prefix, the non-ASCII character is rendered using a somewhat complex base36 calculation process to determine the latter portion of the punycode string.
From PUNY to buffer overflow
The vulnerability in OpenSSL is classified as a buffer overrun or buffer overflow, where more data is fed into a pre-allocated memory buffer than it was designed to handle. Typically, this would cause an arbitrary error in the application. There is a good chance that the overflowed data was written into some other memory segment, overwriting what was stored there previously. This could cause unpredictable behavior in the application or even cause it to crash.
If an attacker is familiar enough with the application and its source code, they could craft a unique request, which could not only overwrite data outside the normal memory constraints, but cause the application to execute shellcode, thus introducing an RCE vulnerability.
Fortunately, OpenSSL leverages some protections which mitigate the risk of RCE from buffer overflow attacks. The “likely” scenario upon successful exploitation of this new vulnerability would be an application crash, or DoS event.
In our case, CVE-2022-3602 is a classic case of the off-by-one type of error in the parsing function which processes punycode in OpenSSL (ossl_punycode_decode).
Overall, the change was quite simple as it involved adding a simple character to an if statement as seen in figure 1 below.
Figure 1: Change to punycode.c ossl_punycode_decode function v3.0.6 – 3.0.7
As seen in the figure above, it’s possible to expand input past its normal expected length. The function (ossl_punycode_decode) accepts an argument which is instantiated as an unsigned integer in C (pout_length) which we can overrun (figure 2 below). A string passed from a punycode name constraint field from the cert that is exactly one additional character more than the 32-bit maximum allowed length, then when fed into (pout_length) will cause a buffer overflow scenario once it’s decoded.
Figure 2: Unsigned in *pout_length
Attack scope
For the attack to be carried out successfully, the threat actor would need to create a malicious X.509 certificate that is digitally signed. The typical certificate validation process would not occur with self-signed certificates.
The need for a digitally signed certificate reduces the overall risk due to the fact that a CA would be involved with the signing process. The most at-risk environments would be those with their own custom-generated root TLS certificates.
It is likely that Stock Overflow Protection such as stack canaries or ASLR/PIE would prevent this exploit from ever becoming a full on RCE vulnerability. Buffer overflows are much more serious due to the fact that they could provide advanced attacks such as reverse shells.
Conclusion
While the severity of CVE−2022-3602 and CVE-2022-3786 are marked as critical, the practicality of pulling off a successful attack would be quite low. Given that RCE is likely not feasible with this particular vulnerability, the overall usage of these vulnerabilities by threat actors and APT groups will likely be very minimal, provided nothing changes.
However, we recommend that all organizations implement checks to identify running vulnerable versions of OpenSSL and upgrade to the latest version immediately to mitigate further risk.
Securonix recommendations and mitigation
- Ensure that all hosts running OpenSSL are patched to the latest version (3.0.7)
- Monitor the usage of CA and root certificates installed on endpoints
- Deploy security controls that can monitor certificate name constraints
- Consider implementing yara/osquery checks (see example below from Akamai [9]) to identify and log the vulnerable components’ usage as well as possibly leverage the results as a basis for your detections:
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains “libcrypto-3” or pe.import_details[i].library_name contains “libssl-3“
)
)
}
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = ‘rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
‘
AND yara.count > 0
Examples of relevant Spotter queries
Securonix customers can leverage the threat hunt spotter queries listed below.
OpenSSL Exploitation Using Punycode in x509 Certificate
rg_functionality = “Network Traffic Analytics” AND (^str_devicecustomstring4_san.email CONTAINS “xn--” OR ^str_devicecustomstring4_san.dns CONTAINS “xn--OR ^str_devicecustomstring4_san.uri CONTAINS “xn– OR ^str_devicecustomstring4_san.other_fields CONTAINS “xn--“)
Root CA AuthRoot or Root Certificate Installed
rg_functionality = “Endpoint Management Systems” AND (deviceaction = “registry_set” OR deviceaction = “Registry value set”) AND transactionstring5 = “Setvalue” AND (customstring47 CONTAINS “\Microsoft\SystemCertificates\Root\Certificates\” OR customstring47 CONTAINS “\Microsoft\SystemCertificates\CA\Certificates\” OR customstring47 CONTAINS “\Microsoft\SystemCertificates\AuthRoot\Certificates\” OR customstring47 CONTAINS “\Microsoft\EnterpriseCertificates\Root\Certificates\” OR customstring47 CONTAINS “\Microsoft\EnterpriseCertificates\CA\Certificates\” OR customstring47 CONTAINS “\Microsoft\EnterpriseCertificates\AuthRoot\Certificates\”)
Execution of Vulnerable OpenSSL Version
rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create” OR deviceaction = “ProcessCreate” OR deviceaction = “Process Create (rule: ProcessCreate)” OR deviceaction = “ProcessRollup2” OR deviceaction = “SyntheticProcessRollUp2” OR deviceaction = “WmiCreateProcess” OR deviceaction = “Trace Executed Process” OR deviceaction = “Process” OR deviceaction = “Childproc” OR deviceaction = “Procstart” OR deviceaction = “Process Activity: Launched”) AND (destinationprocessname = “openssl.exe” OR filename = “openssl”) AND customstring51 STARTS WITH “3.0.” AND customstring51 != “3.0.7”
Examples of relevant Securonix detection policies
Securonix customers can leverage the detection policies listed below.
- EDR-ALL-81-ER
- EDR-ALL-902-ERR
- EDR-ALL-1089-ERR
MITRE ATT&CK
Tactic |
Technique |
Initial Access |
T1190: Exploit Public-Facing Application |
Defense Evasion |
T1553.004: Subvert Trust Controls: Install Root Certificate |
References
- NIST – CVE-2022-3602 Detail
https://nvd.nist.gov/vuln/detail/CVE-2022-3602
- NIST – CVE-2022-3786 Detail
https://nvd.nist.gov/vuln/detail/CVE-2022-3786
- OpenSSL Security Advisory [01 November 2022]
https://www.openssl.org/news/secadv/20221101.txt
- Wikipedia – Punycode
https://en.wikipedia.org/wiki/Punycode
- Stack Canaries – Gingerly Sidestepping the Cage
https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/
- Nightmare – aslr/pie intro
https://guyinatuxedo.github.io/5.1-mitigation_aslr_pie/index.html
- Imperva – Buffer Overflow Attack
https://www.imperva.com/learn/application-security/buffer-overflow/
- Yale – C/IntegerTypes
https://www.cs.yale.edu/homes/aspnes/pinewiki/C(2f)IntegerTypes.html
- Akamai Security Research – Effectively Preparing for the OpenSSL 3.x Vulnerability https://www.akamai.com/blog/security-research/openssl-vulnerability-how-to-effectively-prepare