CVE-2020-0601

What is Windows CryptoAPI?

Crypt32.dll is the core cryptographic library built into every supported version of Windows. It underpins certificate validation for code signing, TLS/SSL connections, and any application that calls into the Windows certificate trust chain — including Internet Explorer, Edge, Outlook, and countless third-party programs that rely on the OS rather than rolling their own crypto. Because so much software trusts CryptoAPI's judgment about whether a certificate is legitimate, a flaw here undermines the trust model of the entire platform, not just one application.

Overview

CVE-2020-0601, nicknamed "CurveBall," is a spoofing vulnerability in how CryptoAPI validates Elliptic Curve Cryptography (ECC) certificates. The bug allowed an attacker to craft a malicious ECC certificate that CryptoAPI would accept as if it were issued by a trusted root Certificate Authority — even though it wasn't. This let attackers forge code-signing certificates so malware would appear to be signed by a legitimate, trusted publisher, and forge TLS certificates to conduct man-in-the-middle interception of HTTPS traffic, all without triggering the usual certificate warnings.

The vulnerability drew unusual attention because it was reported to Microsoft by the U.S. National Security Agency — the first time the NSA had been publicly credited for a Microsoft vulnerability disclosure. The NSA and CISA both issued public advisories urging rapid patching given the severity of a trust-chain bypass at the operating-system level, and CISA took the rare step of issuing Emergency Directive 20-02 requiring federal civilian agencies to patch within 10 business days.

Technical Details

The flaw (CWE-295, Improper Certificate Validation) stemmed from how CryptoAPI validates ECC public keys. Standard X.509 certificate validation checks that a certificate chains up to a trusted root CA. For ECC certificates, CryptoAPI's validation logic did not fully verify the curve parameters against the parameters registered for the trusted root — only the public key point itself. This meant an attacker could take a legitimate, trusted ECC root certificate's public key and pair it with attacker-chosen curve parameters, producing a new "certificate" that CryptoAPI would still treat as chaining to that trusted root, even though the underlying elliptic curve was entirely attacker-controlled and the private key was known only to the attacker.

Because the attack requires no user privileges and can be delivered via a malicious file or crafted TLS connection (though it does typically require some user interaction, such as running a signed binary or visiting a site), it scored 8.1 on CVSS 3.1 — network attack vector, low complexity, but requiring user interaction and yielding no availability impact, just confidentiality and integrity compromise of the trust decision itself.

Discovery

Reported to Microsoft by the National Security Agency, which also published its own Cybersecurity Advisory recommending immediate patching. This marked a notable shift in NSA vulnerability disclosure practice — being named as the reporting party for a widely deployed consumer/enterprise OS component rather than staying silent per its historical posture on offensive tooling.

Exploitation Context

Within days of the January 2020 patch, independent researchers published working proof-of-concept exploits demonstrating both TLS certificate spoofing and Authenticode signature forgery, confirming the practical severity Microsoft and the NSA had warned about. CISA's KEV catalog entry (added 2021) confirms the vulnerability has been used in the wild. Because a successful forged signature defeats a foundational Windows trust mechanism, this CVE remains attractive for signing malware to evade both user suspicion and some signature-based endpoint defenses on any unpatched host.

Remediation

1. Apply the January 2020 Windows security update (or later cumulative update) on all Windows 10, Server 2016, and Server 2019 systems — earlier Windows versions did not use the affected ECC validation path.
2. Prioritize systems that perform code-signing validation or TLS termination, since those are the highest-value targets for certificate spoofing.
3. Audit certificate stores and code-signing verification logs for anomalous or unexpected trust chains predating the patch.
4. Ensure endpoint protection products have updated signatures capable of detecting CurveBall-based forged certificates, since signature validation alone can no longer be trusted on unpatched hosts.
5. Treat any unpatched, internet-facing Windows host handling TLS or code execution as a standing incident-response priority given confirmed KEV exploitation.