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

Thu Jan 16 09:56:36 PST 2020

You *could* also point a browser in your environment at hxxps://
cve20200601.dshield.org - they setup that site to test for vulnerable
browser, but I found in testing that it also triggered my NSM.

Excellent work on this plugin / script - very handy!

On Thu, Jan 16, 2020 at 12:45 PM Johanna Amann <johanna at icir.org> 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

-- 
Rick Chisholm
=========================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/zeek/attachments/20200116/07784893/attachment-0001.html 