In Jan 2020’s Patch Tuesday, Microsoft patched a vulnerability reported by the US National Security Agency (NSA) in a Windows Crypto API impacting Windows 10, Windows Server 2016 & Windows Server 2019. CVE-2020-0601 is a Windows Crypto API Spoofing Vulnerability. As a result of this vulnerability, an adversary can masquerade as a trusted CA, either as the root of trust or as an intermediary, with a fake digital certificate which uses Elliptic Curve Cryptography (ECC), to issue fake digital certificates. These fake certificates can then be used to sign code leading to Windows potentially installing malicious code, e.g. kernel-mode rootkits. In addition, such certificates can even be used in SSL traffic allowing a Man-in-the-Middle (MitM) attack on web traffic.
NSA:
“Exploitation of the vulnerability allows attackers to defeat trusted network connections and deliver executable code while appearing as legitimately trusted entities.”
Elliptic Curve Digital Signature Algorithm (ECDSA) digital certificates contain a public key and key parameters which are mostly standard over defined curves. This vulnerability lies in the way Windows verifies digital certificates based on ECDSA. Once public key bytes are verified, it does not verify key parameters. Microsoft has patched crypt32.dll in the affected systems to ensure proper verification of these certificates.
For a better understanding of the vulnerability and its impact, let’s take a deeper dive to understand what ECDSA actually is.
ECDSA
To define it in a single line, ECDSA refers to Digital Signature Algorithm (DSA) based on Elliptic Curve (EC).
In modern day cryptography, asymmetric cryptography or public key cryptosystems have key pairs, a public key (known to everyone) and a private key (secret; known only to the owner). A combination of these keys allows us to provide data security (encryption) and digital signatures. Most of these cryptosystems are based on mathematical problems which are easy to compute in one direction but hard to solve in the reverse direction. RSA, one of the most used cryptosystems, is based on the problem of factoring large integers.
Elliptic Curve Cryptography (ECC), on the other hand, is based on Elliptic Curve, comprising points that satisfy the following equation over a finite field:
In ECC, public key Kpub is a point on the curve and private key Kpriv is a large integer. G is said to be the Generator of the group such that G can generate a set of all elements that belong to the group that satisfies the following condition:
ECC works on the principle that with G and Kpub available in the public domain, it is hard to find Kpriv which satisfies the above-mentioned equation. This is called the Elliptic Curve Discrete Logarithm Problem (ECDLP).
For the same level of security, ECC needs a smaller key size when compared to RSA.
DSA is a digital replacement of signatures in the real world. It uses public key cryptosystems, where a signer can sign a message with his private key and a verifier can use the sender’s public key to verify the authenticity and integrity of the message.
We use DSA for
- Certificates in browsers – HTTPS certificates for secure (encrypted) connection to websites
- Certificates on the operating system – Signed drivers and apps (on Windows, etc.)
Working of digital signatures can be summarised by the image below.
- A hash is calculated for the plain text message that is to be signed. Hashing algorithms such as SHA256, SHA512 can be used.
- This hash is signed (encrypted) by the signer’s private key using Signature Algorithm.
- For verification, both the message and signature are needed.
- On the recipient’s end, again the hash of the message is calculated, and passed to Validation Algorithm along with the signature and public key.
Please refer the workings and abuse of digital signatures for more details.
Analysis
In ECDSA, ECC is used for digital signatures. Public key Kpub and Generator G for any root CA issuing ECDSA based certificates are known in the public domain and included within signature certificates. Private key Kpriv is a secret known only to the CA.
As we are aware, it is meant to be impossible to calculate Kpriv, knowing Kpub and G, because that would mean solving ECDLP. But over the same curve, we can choose Kpriv` and G` such that:
Which means, for some curves, we can choose a private key Kpriv` over a different group generator G` corresponding to the same public key.
This already sounds scary, and it is. What this means is that over a known curve, for a known public key, if we are able to generate a pair of parameters Kpriv` and G`, then we can claim ownership of the public key Kpub. This can be done mathematically so it’s not an issue with ECC per se.
Security researchers have been able to generate matching keys for the ECC curve ECDSA_P384, as we will see in the case study below.
The vulnerability actually lies in Windows Crypto APIs which only verify public key Kpub in an ECDSA digital signature certificate and not the related parameters such as generator G`. Due to this an adversary can sign a digital signature certificate masquerading as a trusted Root CA, thus compromising the chain of trust on Windows resulting from trusting an invalid certificate in the certificate store, given that its public key is associated with the said trusted CA.
We analysed crypt32.dll post installation of the security update (KB4528760 for Windows 10 1903/1909). To fix the issue, Microsoft has added a new function ChainComparePublicKeyParametersAndBytes(). When digital signature verification is done, CertGetCertificateChain() now calls the new function for verification of public key parameters as well. This ensures that in the case of ECDSA, public key parameters including curve and generator are verified along with the public key for trust to be established.
We used a certificate verification utility to verify the digital signature of a Windows device driver pre and post the update. As can be observed by the call trace on the stack in the image below, WinVerifyTrust() is calling ChainComparePublicKeyParametersAndBytes() during the verification process.
Case Study
Since the patching of the vulnerability, a number of PoCs have been shared online by various security researchers.
On Jan 16th, 2020, a sample was uploaded to VirusTotal which had a digital signature that appeared to be signed by Microsoft’s Root ECC CA. The security researcher seems to have simply created the PoC by setting G` = 1 to generate Kpub = Kpriv` over the ECDSA_P384 standard curve. A write up has been published by the researcher.
Recommendations
Install security updates for Windows 10, Windows Server 2016 and Windows Server 2019 immediately, if not done already.
Conclusion
The majority of digital certificates that are being used today use RSA rather than ECC, however, this is expected to change over the next few years. A point to be noted is that, so far, there have been no reports of CVE-2020-0601 being actively exploited in the wild. However, it would not take much time for adversaries to come up with ways to trick users into installing malicious applications as they can make easy reference to several online resources hosting PoC applications and websites. For this vulnerability to be exploited a user’s interaction would be typically needed to download and install the malware, which would then eventually compromise the system, although it can also be taken advantage of in more complex multi-stage targeted attacks, etc. As a basic precaution users are advised to be wary and only download applications from trusted sources. The best way to stay protected is to keep your OS patched with the latest security updates, and to keep your security product updated.
