Security researchers at Akamai say that they have managed – publishing a proof-of-concept – to exploit a vulnerability in the Windows CryptoAPI that was reported by the NSA and UK’s NCSC and disclosed in October.
They have also published an OSQuery to detect vulnerable versions of crypt32.dll, the vulnerable library.
The bug (CVE-2022-34689) was patched quietly by Microsoft in August 2022 and the known scope is somewhat limited (Chromium v48-based applications), but given that Akamai observes that “fewer than 1% of visible devices in data centers are patched” it deserves attention now that the POC is out there in the wild.
Windows CryptoAPI vulnerability: CVE-2022-34689 revisited.
The vulnerability in Microsoft’s now deprecated – but still ubiquitous – CryptoAPI was described by Redmond on October 11 as follows: “An attacker could manipulate an existing public x.509 certificate to spoof their identity and perform actions such as authentication or code signing as the targeted certificate.”
Microsoft gave the CryptoAPI vulnerability a CVSS score of 7.5 despite it requiring no privileges, no user interaction, only network access and marking it as “exploitation more likely”. (Perhaps amusingly to some, despite the report coming from the NSA, Redmond categorised exploit code maturity as “unproven”...)
(Nb: Do not confuse this bug with CVE-2022-41125, an elevation of privilege (EOP) in Microsoft’s cryptography API key store that can give SYSTEM privileges, which was disclosed by Microsoft’s own MSRC and MSTIC teams and patched in November’s Patch Tuesday cycle – Microsoft said the bug was being exploited in the wild.
CVE-2022-34689: Exploit code maturity: Proven
The CryptoAPI in Windows handles anything related to cryptography, says Akamai: “ In particular, it handles certificates — from reading and parsing them to validating them against verified certificate authorities (CAs).”
Detailing their exploitation of the CryptoAPI vulnerability CVE-2022-34689, Akamai researchers Tomer Peled and Yoni Rozenshein said that “the root cause of the bug is the assumption that the certificate cache index key, which is MD5-based, is collision-free. Since 2009, MD5’s collision resistance is known to be broken.”
They added: "The attack flow is twofold. The first phase requires taking a legitimate certificate, modifying it, and serving the modified version to the victim. The second phase involves creating a new certificate whose MD5 collides with the modified legitimate certificate, and using the new certificate to spoof the identity of the original certificate’s subject. We have searched for applications in the wild that use CryptoAPI in a way that is vulnerable to this spoofing attack. So far, we found that old versions of Chrome (v48 and earlier) and Chromium-based applications can be exploited. We believe there are more vulnerable targets in the wild…”
(“Certificate verification is not unique for browsers, and is used by other TLS clients as well, such as PowerShell web authentication, curl, wget, FTP managers, EDRs, and many other applications. In addition, code-signing certificates are verified on executables and libraries, and driver-signing certificates are verified when loading drivers. As one can imagine, a vulnerability in the verification process of certificates is very lucrative for attackers, as it allows them to mask their identity and bypass critical security protections…” they added.)
Their detailed technical walkthrough is here and the POC is here.
