Beware spoofed x.509 Certificates

Researchers from Akamai have released a technical write-up and PoC exploit for CVE-2022-34689, a critical vulnerability in the Windows CryptoAPI library that could enable attackers to spoof legitimate x.509 Certificates, in order to perform authentication or code signing as the spoofed certificate.

This could be abused by attackers to deliver malicious executables that appear to be signed by a legitimate code-signing certificate, or to perform MiTM attacks on encrypted network traffic.

Technical Details

The vulnerability stems from the CreateChainContextFromPathGraph function call in the crypt32.dll module, which validates cached certificates solely based on the value of the certificate’s MD5 thumbprint.

Therefore, if an attacker could serve a malicious certificate whose MD5 thumbprint collides (has the same value) with one that is already in the victim’s certificate cache, they would be able to bypass this check and have their malicious certificate trusted by the victim system.

MD5 Hash Collisions

For those thinking “isn’t it still technically impossible for us to create two different files that have matching MD5 values?” – you’d be right! That’s called a preimage attack, and while it can be done for more simple hash types like SHA1, it isn’t yet feasible for MD5.

The methodology used here is called a prefix collision, where two certificates that share the same prefixes are created, enabling them to have the same MD5 thumbprint.

The specifics of how the attack works isn’t something that can be summarised without getting overly technical, but the key points are that:

1. There’s a part of the x.509 certificate called the tbsCertificate (to-be-signed) or TBS – this contains all the identity-related values, such as the subject, extensions, Public Key, and more. This is what the Certificate Signature validates;
2. The attacker must modify the contents of the TBS – in particular replacing the Public Key value with an attacker-controlled Public Key value – which is what allows the attacker to sign as the malicious certificate;
3. The Certificate Signature is left untouched, which means the Certificate is incorrectly signed. This doesn’t matter for the purpose of this exploit though, as the vulnerable CryptoAPI library only compares the Certificate Thumbprint;
4. The other steps of the prefix collision attack are performed – manipulating the contents of the original and malicious certificates and copying the result of the MD5 prefix collision computation (i.e. the colliding MD5 thumbprint values) into both of the certificates.

Attack Flow

Based on the above, there are now three certificates to be aware of:

1. The original, unmodified Target Certificate;
2. The Modified Target Certificate which has the colliding MD5 thumbprint value inserted into it; and
3. The Malicious Certificate, which – in addition to having the colliding MD5 thumbprint – also contains the modified Public Key value in the TBS segment.

Akamai’s research team found that Google Chrome v48 and Chromium applications from that time were vulnerable to this flaw, and illustrated the attack flow using the modified certificates to perform a MiTM attack:

Real-World Impact

While Akamai’s research team have thusfar only identified Chrome v48 and associated Chromium applications as being vulnerable, they have indicated there are likely more vulnerable targets in-the-wild that have simply not yet been discovered.

Moreover, they noted that they “found that fewer than 1% of visible devices in data centers are patched, rendering the rest unprotected from exploitation of this vulnerability.”

Akamai have recommended using their supplied OSQuery search to identify and patch all impacted versions of the CryptoAPI library – including unsupported versions such as Windows 7/Server 2008. Developers can also use additional WinAPI functions such as CertVerifyCertificateChainPolicy to further validate the legitimacy of a certificate before trusting and using it.