Certificate spoofing attacks cause havoc for CryptoAPI applications
My favourite thing about Microsoft’s Patch Tuesday is that in the weeks afterwards, we get loads of juicy details about the issues that were patched. This month has been no different, with the Akamai Security Research team focusing on CVE-2022-34689 – a Critical Spoofing Vulnerability in Windows CryptoAPI.
First of all, this has nothing to do with cryptocurrency. Let’s just get that out of the way. But this issue has apparently caused real issues for some individuals. We’re going to explore what CryptoAPI is, how it was vulnerable, and how you can exploit it.
What is CryptoAPI?
If you’ve ever needed to secure something cryptographically on Windows-based applications, you’ve probably used the Windows Cryptographic Application Programming Interface (usually referred to as CryptoAPI or MS-CAPI). Since 1996, it has been the main way for Windows users to encrypt and decrypt data as well as authenticate with digital certificates. Now, that last point is where it gets problematic for the Microsoft Security Team.
What is CVE-2022-34689?
Identified as a Spoofing Vulnerability in the Windows CryptoAPI service, Microsoft described the vulnerability as a network-focused issue with low attack complexity. Using an existing public x.509 certificate (that is, a public key certificate), the adversary could spoof their identity and perform authentication and code signing as if they had the targeted certificate.
Since the Windows CryptoAPI is relatively easy to use, this vulnerability was a pretty big danger to a lot of people. Despite its rather unintimidating CVSS of 7.5 (downgraded to 6.5 after remediation), the simple vulnerability could lead to sophisticated exploitation. And that’s precisely what Israeli security company Akamai did after being handed the vulnerability by the NSA and the NCSC.
How does this vulnerability work?
So, we have a rough idea of the vulnerability. It’s based in CryptoAPI and it can be exploited by spoofing an identity when the system tries to authenticate a certificate. But let’s dig into the meat of this problem and find out how it works at a mechanical level.
Akamai’s formal report noted that “the root cause of the bug is the assumption that the certificate cache index key, which is MD5 (message-digest algorithm, a widely used hash function)-based, is collision-free. Since 2009, MD5’s collision resistance is known to be broken”. Knowing that the hash function has been broken for almost a decade and a half should really have prompted some action from a company as large as Microsoft!
From that point, the adversary needs to do two things:
- Identifying a spoofable and legitimate certificate, modifying it, and sending it onto the victim.
- Creating a second certificate to cause an MD5 collision, creating a situation where the second certificate assumes the identity of the first.
How was CVE-2022-34689 exploited?
Let’s just get the horror story out on the table: in researching how easy it would be to roll out this exploit on mass, the Akamai team found that only 1% of visible devices were patched against this issue. And, by their own admission, they didn’t do an exhaustive search for all the applications that use CryptoAPI. Just how exposed are these systems?
First things first, the key to exploiting the vulnerability comes in finding the patched code – this was the CreateChainContextFromPathGraph in crypt32.dll. As you might expect, there is a certificate comparison at this stage, allowing for the adversary to exploit the weakness. You can see the issue in the code form here:
The Akamai team identified that the patch for CreateChainContextFromPathGraph actually changed how the function worked. Instead of verifying whether the certificate was in the cache, the memcmp addition makes it necessary for two certificates to be present and to match.
This, of course, leads to the malicious agent installing a malicious certificate in order to bypass checks.
Here’s where the function kicks in with some interesting parameters (which the adversary can navigate around):
Let’s walk through some of the interesting parameters here:
hChainEngine – this controls how certificates are validated.
pCertContext – this captures the context of the “secondary” certificate for comparison.
dwFlags – flags for specification.
ppChainContext – whether the output is trustworthy or not.
Without bogging ourselves down with the details, these separate functions allow the adversary to bypass checks as long as they can trick the process through the pCertContext parameter. When the incoming certificate’s MD5 thumbprint is verified (and remember, MD5 can be simple to get around with the proper set-up, causing collisions), the whole system stops working!
In order to show the vulnerability in all its glory, the Akamai put an exploit together to test it out. Here’s how it looks in action:
Here we can see that the custom malicious certificate was trusted by the system. Bad news for people who haven’t updated their systems!
If you want to test it out for yourself, check out this Github repository for the Akamai Security Research team: CVE-2022-34689 – CryptoAPI spoofing vulnerability. As always, these exploits should only be used for educational or penetration testing purposes.
