Share with Your Network
UPDATE 2020-01-17: Updated to clarify that Windows 7 is NOT affected.
Breaking down CVE-2020-0601, Microsofts’ cryptoAPI vulnerability
This week’s announcement of a major vulnerability in the Windows CryptoAPI (crypt32.dll) (CVE-2020-0601) component has generated a lot of buzz in security circles and has brought a variety of questions to our Research team. This post summarizes some of the information we’ve shared with customers over the last 72 hours.
This still an actively evolving situation, and while a great deal of information is already available, Kenna Security continues to monitor the situation in the way we do with all highly public, highly severe vulnerabilities.
What is the CVE-2020-0601 vulnerability?
The original Microsoft release is a good source of information, as are the technical breakdowns which have been shared by independent researchers since the announcement. The vulnerability description provided by Microsoft is included here for posterity’s sake.
This vulnerability affects all machines running 32- or 64-bit Windows 10 operating systems, including Windows Server versions 2016 and 2019. This vulnerability allows Elliptic Curve Cryptography (ECC) certificate validation to bypass the trust store, enabling unwanted or malicious software to masquerade as authentically signed by a trusted or trustworthy organization.
The Microsoft Security Advisory for CVE-2020-0601 addresses this vulnerability by ensuring that Windows CryptoAPI completely validates ECC certificates.
Essentially, you can bypass certificate verification if you’re able to craft a certificate abusing the flaw. The flaw makes the certificate appears valid and the system accepts (with some caveats[1]). As an attacker, if you can get yourself in a position to serve a certificate (via web, or binary, or email etc), this is going to let you spoof identity and trust. It’s bad.
A big part of the reason it’s bad is that it affects all modern, supported versions of Windows:
- Windows 10 (x86, x64)
- Windows 2016 (x86, x64)
- Windows 2019 (x86, x64)
Given this, the prevalence of this makes it attractive to attackers. This is presumably why we’ve seen so much effort to figure it out over the last 72 hours.
So how does this play out with the browsers? In the case where a certificate is provided when connecting (TLS), Internet Explorer and Chrome have both been confirmed affected. They both use CryptoAPI under the hood. The Kudelski Security team put together a PoC here. Firefox has been confirmed as not affected due to a difference in how the certificate verification is performed.
Let’s get specific about CVE-2020-0601. Attack scenarios?
Given that this is not a traditional software flaw (ex: sql injection or memory corruption, etc) – it’s in the underlying crypto implementation, the scenarios enabled by the vulnerability require a bit more thought, and it should be noted that this vulnerability is only a part of a complete attack chain. That said, it can make several already-bad scenarios much worse.
Scenario 1: A rogue user controls DNS. They then craft a certificate exploiting the flaw which bypasses the normal verification process. Allowing software, websites or users to trick the browser into executing code in the context of that site. This can be useful for stealing passwords, or generally executing javascript in the context of a user to deliver malware or steal secrets.
As mentioned above, this’ll be accepted by the browser, but at least in the case of Chrome, you won’t see the normal TLS padlock as before (see below). It’s probably not worth training users on this difference, it’s so slight as to not be noticeable.
Scenario 2: A rogue user crafts a certificate that exploits the flaw. They then use this certificate to sign a binary as a trusted entity, say for instance, Microsoft or the target organization itself, enabling code to execute in scenarios where it would otherwise need to be whitelisted or blacklisted and thus would fail. This may trick some antivirus solutions.
Scenario 3: A rogue user crafts a certificate exploiting the flaw which is used to sign a file sent via email or the email itself, thus allowing a user to appear as someone else and to propagate the malware with less suspicion. This one is particularly pernicious, as there seems to be no obvious way to know that a user is no longer who they appear to be. If you don’t already, now’s a good time to push to get DMARC, DKIM and SPF in place for your email domains. No one should be able to reliably masquerade emails to your organization if these controls are in place.
Scenario 4: A rogue user crafts a certificate which is accepted by the system as an authentication token when visiting a website or logging into a system. This one is the least understood at this point, and it’s unclear if this would affect Windows authentication mechanisms that use a certificate.
CERT recently provided this guidance which makes it clear that this component can and probably is – called by third parties to verify certificates. This means that non-Microsoft products are affected, and while they might not receive their own CVE, they are currently vulnerable if this underlying component is not fixed.
CERT: 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.
Should I panic?
No. The NSA has not been hacked. This is not a “scannable” vulnerability, but it is useful to malware, drive-by downloads, and phishing. We do expect it to be integrated into attacker toolkits quickly. As a multiplier to existing attack scenarios, it should be taken seriously, as it allows users to subvert trust in a number of powerful ways.
What’s the score?
Kenna’s risk scoring is dynamic, based on the environment and even as we write this post, continues to evolve based on new information. Our sensor network has started to integrate signatures and is now detecting instances of this being tested on the wire. A quick break down of how this has played out in Kenna:
- Initially, the vulnerability was scored higher because of chatter ahead of the vuln hitting NVD rising to a score of 35 out of 100.
- The score then dropped back down because of the CVSS initially ranking this at 5.8, taking the Kenna score to a 27/100, as well as a pre-NVD model boost going away [2]
- A PoC exploit was detected, driving another increase in the Kenna Risk Score.
- Almost immediately we started seeing tests of exploitation in the wild. While no malicious use has yet been detected, this activity is automatically and further increasing the score.
Given that both the PoC and exploitation were detected at the same time, the score was brought up to 68.5909/100, where it currently resides.
How should I prioritize this vuln?
Exploits and exploitation-in-the-wild have appeared more quickly than initially expected. Signatures are still rolling out for IPS/IDS systems, so we expect our detection number increase rapidly over next few days.
We are currently scoring this at a 68 out of 100 in the Kenna Security Platform, which is lower than actively exploited RCE’s, but higher than most vulnerabilities with only a PoC (and no detection in the wild). Take the attack scenarios detailed above into account when prioritizing, and as always, consider the business context as you operationalize a fix for this.
The mitigation information can be found on Microsoft’s site, per usual.
We’ll continue to monitor the situation and please reach out to research@kennasecurity.com if we can provide any clarification.
