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

[Johanna Amann]

Hello everyone,

in more news on this, I was just pointed to a POC for this - which is 
available at https://github.com/ollypwn/cve-2020-0601.

Using this, I verified that both versions of the package successfully 
detect the exploit; I also added a test-case with a real exploit 
certificate to both packages (no other changes).

As previously mentioned - if you run this and see any exploit activity, 
I would be really interested in hearing about it.

Johanna

On 15 Jan 2020, at 15:48, Johanna Amann wrote:

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