[Zeek] Updated package to detect CVE-2020-0601

Johanna Amann johanna at icir.org
Wed Jan 15 15:48:42 PST 2020


Hello everyone,

I just wanted to announce that there now is an updated package to detect 
CVE-2020-0601.

The package is available at 
https://github.com/0xxon/cve-2020-0601-plugin

But - before you run and install it - please read this email for more 
details on the package and the advantages/disadvantages over the old 
one.

Due to the fact that not everyone will be able to use the new package, 
the old package will also stays available at 
https://github.com/0xxon/cve-2020-0601

Description of new package
==========================

As described in the last email, the attack requires a non-standard 
explicitly-defined curves to be present in the certificate. The new 
package uses OpenSSL to directly examine if the curve used in a 
certificate is a standard curve or a non-standard curve.

This means that this new package should give a very high confidence 
signal once it finds a suspicious certificate. The notices of the new 
package are also more detailed, giving a return-code that shows why this 
package thinks a certificate might be suspicious.

If you are interested in looking at the code - the main test code is 
contained in 
https://github.com/0xxon/cve-2020-0601-plugin/blob/master/src/openssl_curves.c 
(which is mostly from the OpenSSL source tree - with small 
modifications). This code is called from 
https://github.com/0xxon/cve-2020-0601-plugin/blob/master/src/mscve.bif, 
which extracts the necessary data from certificates.

Disadvantages of the new package
================================

The new package requires OpenSSL 1.1.x. I am currently not planning to 
backport this to older versions of OpenSSL. The new package also uses 
C++-code - as always in binary plugins there is a higher chance that 
errors are introduced. Like, e.g., memory leaks, or potentially even 
crashes.

Furthermore, the old package already gives a pretty high-quality signal. 
While there is a chance for false positives, I know of several sites 
that currently have the old version of the package installed - so far 
without any false positives.

Short version: if you have OpenSSL 1.1.x, want a high-confidence signal 
and do not mind loading binary plugins: use this new version.

In all other cases, stay with the old version - which remains unchanged.

Feedback
========

If you run this package, and encounter problems, or if you run it and it 
works - please share your experiences :). Optimally on this mailing list 
so that the community can profit from it - and if that is not possible 
feel free to just drop me an email.

Johanna


On 14 Jan 2020, at 18:42, Johanna Amann wrote:

> 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
>
> _______________________________________________
> Zeek mailing list
> zeek at zeek.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek



More information about the Zeek mailing list