[Zeek] Work-in-progress package to detect CVE-2020-0601

Johanna Amann johanna at icir.org
Tue Jan 14 18:42:19 PST 2020


Hi,

I assume most of you heard of CVE-2020-0601. If not - see the advisory 
at 
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0601 
and the descriptio nat 
https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF.

I have a small work-in-progress Zeek package that should be able to 
detect if someone is trying to exploit this in TLS communication, e.g. 
when impersonating a server.

The package is available at https://github.com/0xxon/cve-2020-0601; the 
script itself is very short and available at 
https://github.com/0xxon/cve-2020-0601/blob/master/scripts/cve-2020-0601.bro.

How does it work
================

 From the description above, the attack seems to require curves that are 
explicitly-defined to be present in certificates; furthermore the curve 
needs to be a non-standard curve. Having an explicitly defined curve in 
a certificate is quite unusual - RFC 5480 actually forbids this 
specifically.

The script linked above checks if a certificate is an elliptic curve 
certificate - and then checks if the curve field was set by Zeek - which 
it should always be for named curves. If the curve is not set, a notice 
is raised.

Limitations & False positives
=============================

Short version: there may be false positives - it should not be many.

If I understand CVE-2020-0601 correctly, this script should always alert 
when a suspicious certificate is found in traffic. However, there are a 
few cases where it may alert when a certificate is benign.

Specifically, it is possible for a certificate to explicitly define a 
well-known curve, instead of just putting the ID of the curve in the 
certificate. When this happens, the alert behavior of the script 
currently depends on the locally installed version of OpenSSL. Some 
versions of OpenSSL convert the curve back to its name - in which case 
no alert is raised (which is correct). However, other versions do not do 
this - and lead to Zeek leaving the field empty. This will lead to a 
notice being raised.

I am not sure why the behavior differs - this seems to depend on 
configuration choices of different Linux distributions - and sadly this 
seems to not work in a lot of linux distributions. I could not map it to 
specific versions of OpenSSL.

The package contains several tests - if the explicit.bro test fails, 
your OpenSSL installation does not perform the conversion - which 
theoretically lead to false positives.

That being said - in theory, explicit curves should not be used for TLS 
communication. Which brings me to…

Feedback
========

If you use this and see it raising a lot of notices, or have other 
feedback - please write either here or to me directly.

I am currently working on trying to get the detection better - this will 
require making this a binary module that directly calls into OpenSSL to 
examine the certificate datastructures.

Johanna



More information about the Zeek mailing list