How CVE-2020-0601 the Chain of Fools / Curveball / NSACrypt Attack Affects You
by Sage Driskell
CVE-2020-0601 was announced to the public on January 14, 2020, as a warning about the Cryptographic API in Windows 10 and Server 2019 (there are rumors of Server 2016, but we have not explicitly verified this) and with a patch to resolve the issue on affected machines. As of reporting, there were no known attacks using this attack vector in the wild. Since then, the vulnerability has gotten a name (actually a few names), and some researchers have released proofs of concept.
If you want to validate a system and whether it’s susceptible or not, go to: this test.
What Is It?
CVE-2020-0601 is known by several names now. There’s Curveball and NSACrypt, as well as Chain of Fools. There are several names in circulation, but they all point to the same flaw. Let’s go over what the exploit is first.
Per Microsoft:
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.
The security update addresses the vulnerability by ensuring that Windows CryptoAPI completely validates ECC certificates.
If we dig a little deeper with newer information, we find the following from cert.org:
The Microsoft Windows CryptoAPI, which is provided by Crypt32.dll, fails to validate ECC certificates in a way that properly leverages the protections that ECC cryptography should provide. As a result, an attacker may be able to craft a certificate that appears to have the ability to be traced to a trusted root certificate authority.
Any software, including third-party non-Microsoft software, that relies on the Windows CertGetCertificateChain() function to determine if an X.509 certificate can be traced to a trusted root CA may incorrectly determine the trustworthiness of a certificate chain.
Microsoft Windows versions that support certificates with ECC keys that specify parameters are affected. This includes Windows 10 as well as Windows Server 2016 and 2019. Windows 8.1 and prior, as well as the Server 2012 R2 and prior counterparts, do not support ECC keys with parameters. For this reason, such certificates that attempt to exploit this vulnerability are inherently untrusted by older Windows versions.
So, a core function in Windows 10 based OSes for determining the key of an ECC cert which has been generated can’t be trusted until this patch is applied. This does not affect older Windows OSes though.
What Is Elliptic-Curve Cryptography (ECC)?
Elliptic-Curve Cryptography (ECC), or ECC is a form of cryptography using a mathematically generated curve algorithm instead of the traditional key method. In short, we’re passing some variables to build a key to an algorithm rather than just passing a big key to do our encryption and decryption (obviously, this is a gross simplification). This means that we use less complexity for stronger encryption (theoretically).
The basis of ECC is the following equation: y2 = x3 + ax + b
If we graph an arbitrary example of this, say: y2 = x3 – 5x + 10, we get:
A diagram of an ECC curve for: y^2 = x^3 – 5x +10
The way the ECC algorithm works is we draw a line through parts of the curve and let it “bounce” per a known algorithm. We know it will “ricochet” a certain way and with some other conditions we can get a starting and an ending spot where it crosses the curve and bounces across. These numbers will be meaningful with a little data, but almost useless otherwise. There are a lot of equations which will get you the same algorithmic result for a few points, but if you don’t know the parameters, you don’t know the underlying pieces that make up our “key”. This means a smaller key for a harder problem for all intents and purposes.
We won’t really get any further into the math, but basically, as long as we verify all of our points and all of the variables, we’re safe.
Throwing a Curveball
The problem is, for whatever reason, Crypt32.dll doesn’t verify this correctly on certain Windows 10 and Server 2019 builds. One theory is that it’s failing to verify the base point in the equation and is assuming everything is kosher on the math checking out otherwise. Hopefully there is a bit more to this vulnerability, but either way, arbitrary ECC certificates are vulnerable without this patch on certain versions of Windows.
The issue is we’re (almost definitely) doing the math correctly, just Microsoft has decided to take a few shortcuts which compromise the validation of arbitrary ECC algorithms. See the following for a PoC.
How Bad Is It?
It’s a bit scary that something this fundamental is broken on modern Windows, but there’s some good news, it’s really not that bad with a little common sense. You won’t see this issue with Firefox since it doesn’t rely on Cryp32.dll, and other browsers like Chrome have issued patches. Most AV solutions already block the generated certificates, including Windows Defender. A good firewall which inspects SSL certificates can block this as well. Ultimately, this threat has been blocked by most end-user products, the OS, and even theoretically at the network level (transport level in TCP/IP for those of you getting your certs). This also does not impact Windows Update as those are signed using RSA.
The threat has been sold as a huge deal, and it is when used. Fortunately, the attack is non-trivial (at the time of writing) so it requires a significant degree of effort to execute, plus there is requisite setup to pull off the attack. It’s a big deal, but so is a car crash. Drive safely and you probably won’t have an issue and you prevent what you can. At present, this threat is an implementation exploit and not a cryptographic exploit.
CVE-2020-0601: Reacting to the Threat
If you have an advanced firewall which can inspect certificate chains, apply those settings if possible (some apps require certs which are superficially suspicious looking) to stop all of the man-in-the-middle attacks related to this on the internet. Your AV should update itself to stop the other attacks in most scenarios, and if not, be sure to apply the patch for this vulnerability.
This is a good time to apply more secure firewall policies at a site and agent level if possible. This is a vulnerability with the specific implementation of the cryptography and not the math behind it. As long as the cryptography itself is sound, you are too as long as you can prevent the specific implementations from being vulnerable. When you throw on an advanced firewall setting to check this, you add a different way of interpreting the math into the equation and effectively check twice using the same thing implemented differently.
If this had affected Windows 7 or Server 2008 (R2), what would happen? There’s no support and this exploit (despite being relatively harmless with some preparation) would be a much bigger deal for a company and for administrators. Windows 10 has active support, but what if your AV vendor stopped caring as well as the primary OS vendor? This is a great chance to spearhead a forced move away from legacy OSes where possible.