A spoofing vulnerability has been discovered in the way the Windows cryptographic library (crypt32.dll) validates certificates composed of elliptical curves (ECC).
Successful exploitation of this flaw could lead to “man-in-the-middle” (MitM) attacks or decrypt confidential data. Only Windows 10, Windows Server 16 and 19 are affected by this vulnerability.

Execution of a Trojan horse signed with an exploit of the CVE-2020-0601

Security bulletin by TEHTRIS

One way an attacker could exploit this vulnerability is by signing malicious code and making it appear to come from a legitimate source. The user would then have no way of knowing that the file was in fact malicious because the digital signature would appear to come from a recognized certification authority.

Any software depending on the CertGetCertificateChain() function of this library to ensure that the certificate is of recognized authority could then be unable to do so correctly and thus be misled in determining the authenticity of this certification chain.

The library concerned by this flaw (crypt32.dll) was introduced by Microsoft about twenty years ago (under Windows NT 4.0). However, older versions of Windows are not affected because they natively reject elliptic curves with parameters.

Affected Systems

  • Windows 10
  • Windows Server 2016 and 2019

Remédiations / Mises à jour

In order to fix CVE-2020-0601, it is necessary to update your operating system with the latest security patches available on the Microsoft website.

To do this, it is advisable to force the update by writing “update” in the search bar and selecting “search for new updates“. The system will then automatically search for the latest updates and perform them if necessary.


Attack Detection with TEHTRIS EDR

TEHTRIS EDR includes a new capability to detect exploitation attempts against the CVE-2020-0601 vulnerability through extensive analysis of software signatures and sophisticated cryptographic validations, in order to understand when a binary has been built to abuse the related flaw.

At the time of this writing, this is the very first EDR (Endpoint Detection and Response) in the world with such an option since it offers the possibility to also find the attack on un unpatched Windows systems too (!) with no recent update and with the old vulnerable version of CRYPT32.DLL.

This feature offers several possibilities to TEHTRIS EDR users worldwide:

  • They have flexibility for their own Windows update schedule, especially on infrastructures with specific constraints (production level, etc)
  • They have the ability to detect intrusion attempts through the included centralization of logs to the unified console of TEHTRIS XDR Platform
  • They have the ability to perform powerful hunting and forensics sessions using the included tools from the TEHTRIS XDR Platform. A security manager might want to run a forensic against a Windows that surprisingly tried a CVE-2020-0601 attack as this is a kind of direct evidence that an intruder managed to gain a first level of access (Figure 0).
Figure 0

Identificiation of Vulnerable Devices

The TEHTRIS EDR product has a vulnerability research module. It can thus identify the vulnerable Windows (Figure 1). Cybersecurity teams can easily monitor the deployment of updates and identify risk areas in terms of Patch Management policy.

Figure 1

Windows Event Log Generation and Recovery

Given the importance of the impact of the CVE-2020-0601 flaw, Microsoft has developed a patch that can generate an entry in the event log in order to offer the possibility to detect an exploitation of this vulnerability. These new Windows event logs are part of a new entry called Microsoft-Windows-Audit-CVE or Audit-CVE.

Unfortunately, on unpatched Windows, the attack will not be detected by Windows (TEHTRIS EDR can do it for you).

As soon as the announcements were released by Microsoft, TEHTRIS took quick action to retrieve these Windows event logs and to integrate them into the tactical SIEM module of the TEHTRIS EDR, for servers and workstations. (Figure 2)

Figure 2

The TEHTRIS Research and Development team analyzed the new version of the crypt32.dll library to understand how new error messages were generated. The idea was to understand how this works in order to quickly generate a log of this type.

Debug and Reverse on the new DLL

As part of our compatibility research, the decompilation of the DLL allowed us to follow the execution flow step by step thanks to tools such as WinDbg or a reverse engineering tool (in this case Ghidra) accompanied by debug symbols (i.e. crypt32.pdb).

The results obtained using WinDbg (Figure 3) identify the function responsible for generating these error messages: “ChainLogMSRC54294Error”.

Figure 3

The next step leads us to identify how certificate tests redirect to this function.

In the Reverse Engineering tool (Ghidra), we can see that the output of CryptVerifyCertificateSignatureEx is based on a JNZ (Jump Not Zero) test (Figure 4).

Figure 4

We then wish to avoid this uncontrolled jump to go directly to the block of the required function. We have two solutions:

Modify the JNZ instruction (which is on 2 bytes) in JMP (jump) to the following address and thus make a jmp of 0 or,

Transform the JNZ instruction into two NOP operations (instruction that indicates to do nothing on 1 byte) which allows us to arrive at the following address.

TEHTRIS R&D then decided to experiment the first solution. Realized with a hexadecimal editor (ex: HxD) at the right address, it returns the following result: Figure5.

Figure 5

To conclude, this modification allows a quick identification of error events generated if the modified DLL is loaded by Windows or if the modification is made on the fly in a debugger.

Cyberthreat Intelligence & EDR

In order to be able to simulate the attacks, first attempts were made to use the flaw (signing a binary maliciously). The question is what would happen if such a binary was seen on a park protected by TEHTRIS EDR .

Let’s take the example of a ransomware signed with a Windows certificate: d6ab910259c9bc68196aeec3e9ff4864bada22738c02ecf5ada7912ced292d28.

The signature is considered valid by an unpatched Windows machine. (Figure 6)

Figure 6

The TEHTRIS analysis tools analyze this binary in the same way as an unsigned binary.

In this case, the result of the scan indicates that it is ransomware, 100% detection for the SandBox score (figure 7) and by 21 antivirus programs on the basis of VirusTotal. (The VirusTotal score is much lower than the current score of the same unsigned binary).

Figure 7

TEHTRIS EDR does not rely solely on signatures to make decisions. So the remediation applied on the results of TEHTRIS CTI (Cyber Threat Intelligence) will remain the same even with a binary that abuses the CVE-2020-0601 vulnerability.

Snort & Yara Rules

The idea is to detect what seems suspicious in the certificate data by identifying malicious patterns. For this, there are at least two possibilities either at the level of network flows with SNORT rules or at the level of binaries with YARA rules.

The TEHTRIS R&D team focused on creating YARA rules using data from the CTI database.

The vulnerability exploits the fact that one can define one’s own parameters for elliptic curves. The goal of the TEHTRIS R&D team is to search for certificates that use them ($ecc), but that do not explicitly indicate the type of elliptic curves used ($p256, $p384, p$521).

To do this, we will search in particular for OIDs (object identifiers) of objects present in the certificates (in ASN1 format, DER encoding).

– For example, the following OID indicates that a certificate uses elliptic curves :

– Another example, this time indicating that the certificate uses the generic parameters of the P-384 curve:

Depending on the method used to create the certificate, it will be identified as follows:

– If the certificate uses ECC and the curve type is explicitly named (P-384…) then it is marked as SAFE

– If the certificate uses ECC, but the curve type is NOT named (i.e. customs parameters are used), then it is marked as UNSAFE.

The TEHTRIS R&D team then translated these characteristics into the following YARA rule shared just for information:

Be careful, the YARA rules can lead to a number of detections that do not prove to be accurate. All detections related to YARA rules must be analyzed, especially because of the distance aspects between previous strings.

WARNING: Some SNORT detection rules are available on the Internet. They do not work in all situations. Hackers could easily circumvent them, as they only focus on specific cryptographic stuffs and they only handle one main manufacturer (Microsoft). At the time of writing this article, there is no reliable generic detection seen on the Internet with NIDS, and we do recommend the use of system sensors (EDR) rather than network sensors (NIDS).


We have briefly presented several technical elements and we would like to leave in conclusion a comparative table of the detection of CVE-2020-0601.