Chain of Fools: What We Know So Far on Windows CryptoAPI Spoofing Vulnerability

On Monday this week, Brian Krebs broke a story that the NSA had discovered a critical flaw in Microsoft Windows software responsible for core security functions including, among other responsibilities, verifying the identity of other computers on local networks and the internet as well as assuring the authenticity and provenance of code being installed on a machine. When Microsoft was alerted by the NSA of this vulnerability, the potential security impact was apparently so high that as soon as patches were ready, they were made available ahead of the public notification to military and "other high-value customers/targets that manage key Internet infrastructure" under strict non-disclosure agreement. While this in itself is not uncommon, it did underscore the urgency in mitigating a serious widespread security bug.

TL;DR: patch.

This morning around 10 a.m. ET, the Washington Post's Ellen Nakashima published a report with sources confirming the disclosure, initially with an emphasis on code signing and then later in the day updating the story to clarify that the real threat was "an error in the software code that fails to properly check the authenticity [of network communications]", in other words cryptographic certificate spoofing; a failure in the trust chain that ensures your computer is talking to who it thinks it's talking to (or is about to install software that was actually written by those who you believe wrote it).

This post is a quick day one recap of what we know so far about CVE-2020-0601, what Microsoft has dubbed the Windows CryptoAPI Spoofing Vulnerability . I haven't heard a catchy name yet, so I vote for Chain of Fools with a dutiful nod to the queen of soul, Aretha Franklin. The analyses presented (my own included) are only as good as the information we have on hand, which so far is still fairly thin on technical details. This is by no means intended to be exhaustive or authoritative, just a curated selection of information sources from people who are technically credible or experts in the field.

First, the official advisory itself: The Windows CryptoAPI Spoofing Vulnerability

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider. A successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software.

• Microsoft rates this as Severity: Important, with CVSS scores of 8.1/7.3
• Affected systems: Windows 10, Windows Server 2016 & 2019
• Some early reporting (including Krebs) had suggested that "all versions" of Windows going back 20 years was impacted. That seems not to be the case. According to NSA, the bug was introduced in July 2015.
• Part of the confusion is that this particular software library, crypt32.dll has in fact been a core component of Windows going back all the way to NT . Why Windows 7, 8, and 8.1 and earlier server versions are unaffected isn't completely clear, though there have been some interesting theories. More on that in a bit.

Around noon Eastern today, by plan, NSA held a briefing with members of the media, and immediately thereafter Microsoft released the official advisory, followed up shortly by NSA's own advisory:

National Security Agency Cybersecurity Advisory: Patch Critical Cryptographic Vulnerability in Microsoft Windows

NSA assesses the vulnerability to be severe and that sophisticated cyber actors will understand the underlying flaw very quickly... Consequences of not patching the vulnerability are severe and widespread.

Shortly thereafter, CERT published their alert: Vulnerability Note VU#849224 : Microsoft Windows CryptoAPI fails to properly validate ECC certificate chains, emphasizing that this directly affects X.509 certificate chains - the cornerstone of trust in any networked computer.

Today, DHS published an emergency directive, 20-02 advising federal agencies to patch within 10 days. And in an unexpected twist included mandates on remote desktop access (RDP) vulnerabilities as well. DHS cited other CVEs announced by Microsoft today, including CVE-2020-0609, CVE-2020-0610, and CVE-2020-0611 as no-auth-required remote code execution. So full RCE plus certificate chain validation. What a way to start the day.  

You may be asking yourself, "What the heck is a certificate chain validation?" Glad you asked. I illustrated this on twitter today thusly:

Maybe the school kid here has a sharp eyed teacher who actually bothered to check the signatures [verdict: not legit; how it's supposed to work]. Or maybe they have a substitute that day who was phoning it in [verdict: lgtm; how Windows apparently works].

Enough with the fun and games, Kenn. I want the DEETS plz.

Okay, fine. I'll stipulate that most of my readers are probably not here for the Muggle version. Here goes.

From Crowdstrike's co-founder:

Thomas Ptacek ( @tqbf ) has written what I think is the best technical analysis of the cryptography with the information at present. You should read it, or at least pass it along to your neighborhood crypto nerd security team person.

In short, it appears that an attacker can create a custom ECDSA certificate with an ellipic curve (ECC) signature that appears to match a known standard curve, like P-256 that includes a public key for an existing known trusted certificate authority, but which was in fact not signed by that certificate authority. Windows checks the public key and other curve parameters, but not the (bespoke attacker-supplied) base point generator ( G ) parameter constant which actually generated the curve. Low-level code within the foundation of the operating system is accepting the attacker's stated identity ( "Hi! I'm Google!" ) as genuine on the basis of incomplete checks. With a rogue ECDSA certificate, any number of network comms are at risk. And that is a problem.

Cem Paya has some interesting insights in this thread as to why earlier versions of Windows might have skated by unscathed:

Cas Cremers reminds us that what's old is new again, citing original work of Serge Vaudenay and Thomas Pornin in this thread:

At the end of Cas' thread above, he manages to fit the attack formula into a single tweet:

And Thai Duong (who brought us the BEAST, CRIME, and POODLE attacks on SSL) points out that RFC5480 requires that user-supplied custom curve parameters from a "known" curve must not be blindly trusted.

So, what do we know so far about the patch? This is a crucial detail in the analysis - examining the delta between the patch and previous machine code to understand exactly which parts of the codebase is affected. From the looks of it, this is a fairly circumscribed fix (which makes sense given how vital it is not to introduce any breaking changes).

Some interesting debate in the community around the practical risk to the Windows Update system ("WU") including former GCHQ signals specialist and ex-Google Project Zero member Matt ( @pwnallthethings ) Tait, Windows internals expert and Crowdstrike's head of EDR, Alex Ionescu, and DNS guru Dan Kaminski. There are some strong claims that Windows Update now includes additional security precautions, specifically checking the fingerprint of certain high-value system RSA certificates (in this case Microsoft) via "pinning", in which the precise hash of a known authority and of the endpoint or a binary package's certificate itself is doubly verified. Sort of the digital equivalent of checking biometric signatures against a database of known images that are baked in to the OS. Based on the threads below, I remain skeptical that there's a direct live path for WU exploits, but one could easily imagine indirect paths where the flaw allows arbitrary software to be installed outside Windows Update which could replace or remove the checking functions themselves. It might not be as elegant, but it gets the job done.

There are already detection signatures available from security vendors and even through the Windows Event Manager:

And some good news. For those who rely on Microsoft's own anti-virus and malware protections via Windows Defender, malicious files signed with bogus certs that have tell-tale characteristics of the 2020-0601 curve exploits are now detected and inoculated in real time.

As far as working Proofs of Concept (PoCs), famed UK hardware hacker Saleem Rashid and many others are on the case, and my guess is we'll see working code in circulation within the next 24 hours. Saleem is already well on the way.

I shared some thoughts with Wired on the story today:

Windows 10 Has a Security Flaw So Severe the NSA Disclosed It

In a shift toward transparency, the National Security Agency announced a bug that could have left over 900 million PCs vulnerable to attack.

Lily Hay Newman WIRED

"This is a core, low-level piece of the Windows operating system and one that establishes trust between administrators, regular users, and other computers on both the local network and the internet. If the technology that ensures that trust is vulnerable, there could be catastrophic consequences. But precisely what scenarios and preconditions are required—we're still analyzing. It will be a long day for a lot of Windows administrators around the world."

As for the long-term lessons here, I think Matt Green summed it up best:

Be safe out there folks. (And patch, patch, patch!)

Post-publication update: Remember that "other" bug I mentioned, the nasty no-auth Remote Desktop Protocol Gateway remote code execution ? Yeah, about that...

I thought you were my man

But I found out

I'm just a link in your chain

You got me where you want me

I ain't nothin' but your fool

Ya treated me mean

Oh you treated me cruel

Chain, chain, chain

(Chain, chain, chain)

Chain of fools

— Ms. Aretha Franklin