CVE-2020-0601 Followup

Published: 2020-01-15. Last Updated: 2020-01-16 18:55:46 UTC
by Johannes Ullrich (Version: 1)

Among the patches Microsoft released yesterday, the vulnerability in the CryptoAPI got by far the most attention. Here are some answers to questions we have received about this vulnerability. Many of these questions also came from our webcast audience (for a recording, see https://sans.org/cryptoapi-isc ) Thanks to Jake Williams for helping us with the webcast!

UPDATE: An Exploit has been made public!

We also made a simple PowerPoint presentation available to help you brief management on the issue: TalkingToYourBossAboutCryptoAPI.pptx

[I am still going over some of the questions from the webcast. This post will be updated later today with additional questions. Feel free to submit questions here: https://isc.sans.edu/contact.html ]

What is the name of the vulnerability?
There is no catchy name or logo for this vulnerability. It is referred to as "CVE-2020-0601", "CryptoAPI ECC Verification Vulnerability," or "crypt32.dll Vulnerability" and several other names. It is probably best to use the CVE number as an identifier.
Which operating systems are affected?
Only Windows 10 and Windows Server 2016 and 2019 are affected. Windows 7 is not affected. There was some confusion about this because Windows 7 is no longer officially supported after this patch release. But the January 14th patch Tuesday did cover Windows 7. The affected library, crypt32.dll (CryptoAPI), is present in older versions of Windows, including Windows 7. But not all versions of this library are affected. Out of support versions of Windows 10, like Windows 10 1709, are likely vulnerable, and you should upgrade to Windows 10 1809, the current "long term support" version.
Have there been any problems reported with this patch?
None so far that we are aware of.
I am only using RSA certificates. Am I still vulnerable?
Likely yes. First of all, even if you use RSA certificates exclusively internally, many external sites and software distributors will use elliptic curve (ECC) certificates. Also, the operating system will treat ECC and RSA certificates as equals. Think of it as a different certificate authority. Your system will trust certificates from any trusted certificate authority. Even if you retrieve your certificates exclusively from "Authority A," an attacker could still use "Authority B" to impersonate you as long as your systems trust "Authority B." Certificate pinning may help here (or pinning the certificate authority)
Is Windows Update itself vulnerable?
No. Windows Update added several protections to prevent attacks where an attacker would be able to obtain a fake Microsoft certificate. Microsoft uses Certificate pinning and other protection measures to make attacks very difficult and impossible via CVE-2020-0601.
Is SCCM Vulnerable (Microsoft System Center Configuration Manager)?
No. It applies the same checks to updates as does "Windows Update."
How do I know if I am patched?
There are now a few of proof of concept exploits available on GitHub. The simplest test is probably https://chainoffools.wouaib.ch/ [visit at your own risk]. The website uses a certificate that was "signed" using the PoC exploit . You may also download a sample binary submitted to Any.Run see: https://app.any.run/tasks/884f5b91-2f1c-40f9-9566-41ab83790f60/ [again: use at your own risk]
Is there an exploit available?
A working exploit has been released on Wednesday, Jan 15th evening (ET). https://github.com/ollypwn/cve-2020-0601
Is there some form of test certificate available (not a full exploit) to check my defenses?
visit https://curveballtest.com to test if you are vulnerable (use Internet Explorer or Edge. Chrome may show up as not vulnerable even if it is vulnerable)
Will I know if someone attacked me using this vulnerability?
If you patched, Windows will log an alert if it detects a suspect certificate. Endpoint protection vendors, including Microsoft, have added signatures to their solutions, checking for certificates that are likely exploits.
How will I be able to detect if a certificate is taking advantage of this vulnerability?
The certificate will use an elliptic curve with explicit parameters. Three parameters define elliptic curves. There are several standard ("named") curves with set parameters. But instead of using one of these named elliptic curves, you may also specify your parameters. Not all certificates with explicitly defined parameters are malicious. But the exploit requires the use of these explicit parameters.
Are Certificates Using Specific Elliptic Curves, like for example P-384, vulnerable?
An attacker would use a certificate with explicit parameters, not a named curve like P-384, to exploit this vulnerability. However, if your valid certificate uses a named curve like P-384, an attacker could still craft their own certificate with explicit parameters to exploit this issue.
If my VPN (or other TLS based authentication system like PEAP) uses certificates for authentication: Is it vulnerable?
This depends somewhat on the exact configuration. But in general, you are not vulnerable in these cases because you are likely only allowing very specific CAs and are always pinning certificates for specific users.