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

Johanna Amann johanna at icir.org
Thu Jan 16 10:21:24 PST 2020


Hi,

in even more news - after a suggestion of Justin, I updated the script 
in a way that lets you log suspicious certificates - in case you will 
want to dig into exploit attempts afterwards.

Both versions of the plugin now have a setting (disabled by default) 
that will log all suspicious certificates encoded as base64.

To enable this, update your package and redef CVE_2020_0601::log_certs 
to true.

Johanna

On 16 Jan 2020, at 9:30, Johanna Amann wrote:

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



More information about the Zeek mailing list