2020 opened with a vulnerability that affected the Windows cryptographic mechanism. The United States National Security Agency (NSA) reported a critical vulnerability (CVE-2020-0601) in Window’s Elliptic Curve Cryptography (ECC) certificate validation mechanism. This vulnerability, known as Curveball, allows an attacker to bypass the normal certificate validation mechanism and create their own cryptographic certificates which appear legitimate.
In this blog, by Stefan Nicula of Avira’s Vulnerability Detection team, we will take look at the vulnerability.
In the Vulnerability Detection team’s May 2020 update, we described CVE-2020-0601 as one of the most critical vulnerabilities of the year, and here we will have a look at the activity around it, samples identified and the patches applied.
The CRYPT32.DLL library is a part of the Windows CryptoAPI system. It is one of the core cryptographic libraries that Windows uses to verify the validity of cryptographic certificates. The vulnerability CVE-2020-0601 known as ‘CurveBall‘ enables an attacker to bypass the normal certificate validation mechanism. This allows them to create their own cryptographic certificates that appear legitimate and can be trusted by Windows.
This vulnerability exposes Windows hosts to a broad range of exploitation vectors. A few examples where the cryptographic validation may be compromised include:
- Files and email signature verification,
- Potential update service traffic,
- HTTPS connections and Man in the Middle attacks
With regard to the last bullet point, it is worth considering the way browsers validate certificates for HTTPS connections: The Mozilla Firefox browser uses libnss instead of crypt32 while Chromium-based browsers such as Edge and Chrome, deployed a patch to mitigate the Curveball vulnerability.
Note that the Windows Update uses RSA certificates rather than ECC. The RSA certificate chain is pinned in the Windows update binary leaving no room for exploitation in this scenario. However, other Windows services could potentially be at risk.
Key bytes and key parameters
Certificates using ECC keys have two parts, key bytes and key parameters, and these must match when certificates are compared. The vulnerability makes it possible to generate an ECC key that matches in key bytes but not in key parameters. When the CryptoAPI code fails to make a complete check and compare both, ECC keys with the same key bytes but with different key parameters can be considered to be the same public key – and an exploit exists.
Microsoft has added a CVE Event for EventLogger to be notified each time a corrupted ECC implementation is being used “[CVE-2020-0601] cert validation” identifier.
To explore the patch we compare two versions of the crypt32.dll files.
- Version 10.0.17134.1130 updated on November 2019, the unpatched version
- Version 10.0.17134.1246 updated on January 2020, the patched version
To observe the behavioral difference between versions, we run a BinDiff on both the files.
Figure 1 – Using BinDiff on both the patched and unpatched versions of the crypt32.dll
we see function CveEventWrite() called by ChainLogMSRC54294Error(), two new functions added in the patch.
Figure 2 – The CveEventWrite function call from ChainLogMSRC54294
The function ChainLogMSRC54294() is the new logging function that Microsoft uses to index potential exploits. The [CVE-2020-0601] cert validation string is passed as an argument to call the function that informs EventLogger of the potential exploit.
Figure 3 – Cross-reference to ChainLogMSRC54294() links to ChainGetSubjectStatus()
Tracing the function, we see that the call was made by ChainGetSubjectStatus(). Looking at Figure 1, it can be seen that most of the changes between the DLL versions have been made on this function, and ChainComparePublicKeyParametersAndBytes() is called by ChainGetSubjectStatus(). As seen in the figure below:
Figure 4 – Surrounding context view of the ChainLogMSRC54294()call
A cross-reference to ChainGetSubjectStatus() shows a new call to ChainComparePublicKeyParametersAndBytes() before the signature is verified.
To see these changes on a decompiler, we use the Ghidra’s Version Tracking functionality and compare the two DLL versions.
Figure 5 – Ghidra’s Version Tracking for ChainGetSubjectStatus()
Analyzing the difference between DLL versions, we see Microsoft’s patch implemented and the vulnerable function. An event log is assigned to identify potential abuses.
Analysis shows that samples found in the wild were not exploiting the Curveball vulnerability. Many samples following the initial public disclosure of the vulnerability were using some form of PoC testing by researchers.
However, we have seen some interesting samples such as versions of mimikatz, a popular post-exploitation tool. These were signed with a malformed signature designed to exploit the faulty ECC check implementation. We also see rogue client installations targeting common software like 7zip and antivirus solutions. As expected, this vulnerability received lot of attention considering the potential impact that it had. Employing a strong detection will prevent potential use of the CryptoAPI vulnerability.
Avira is continuously looking for ways to assist its partners with detection and protection against vulnerabilities and exploits. We want to reiterate the recommendation and importance of applying official Microsoft patches as soon possible.
Avira detected the exploits as: