[Zeek] Work-in-progress package to detect CVE-2020-0601
asharma at lbl.gov
Tue Jan 14 21:13:49 PST 2020
Thanks Johanna - I must say quite timely package.
On Tue, Jan 14, 2020 at 06:42:19PM -0800, Johanna Amann wrote:
> I assume most of you heard of CVE-2020-0601. If not - see the advisory
> and the descriptio nat
> 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
> 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
> 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…
> 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.
> Zeek mailing list
> zeek at zeek.org
More information about the Zeek