2

The testssl.sh tool stated that a server I tested is vulnerable to the Lucky13 (CVE-2013-0169) vulnerability. Below the testssl.sh output:

###########################################################
testssl.sh
###########################################################
Testing for LUCKY13 vulnerability 
LUCKY13 (CVE-2013-0169) VULNERABLE, uses cipher block chaining (CBC) ciphers

I'd say that upgrading OpenSSL would fix it. But, this is Windows Server 2012, so no OpenSSL there. What would be the proper fix in order to mitigate this?

I was thinking about:

  • Disabling TLS 1.0 entirely;
  • Removing all cipher block chaining (CBC) ciphers.

Are there other mitigations for Lucky13 and why did Microsoft not just fix this with a security patch?

Improve this question
11
  • You ran a bash shell script on a Windows server? It looks like only open source software is affected - PolarSSL, OpenSSL & OpenJDK.
    – DKNUCKLES
    Commented Jul 18, 2017 at 14:21
  • I would do as you suggest for LUCKY13 - You might find some issues with disabling TLS 1.0 though as I am sure you are aware of already. Have you reordered the cipher suites from the default as well?
    – ISMSDEV
    Commented Jul 18, 2017 at 14:22
  • @DKNUCKLES although that would technically be possible with cygwin, I did not. I ran a bash script from another machine (Linux) against a Windows server.
    – Bob Ortiz
    Commented Jul 18, 2017 at 14:23
  • 1
    @BobOrtiz A client gives the ones it supports, but the server picks the most suitable (secure) based on your cipher suite order (as long as its in the list from the client).
    – ISMSDEV
    Commented Jul 18, 2017 at 14:30
  • 2
    @DKNUCKLES: the RHUL researchers only looked at open-source, see the website; I don't think anyone but MS knows if Windows was or is vulnerable. (1) OpenSSL is available on Windows and so are servers using it; AFAIK only IIS, Exchange and RDS (and dotnet?) use schannl. (2) The actual vuln is suites using (HMAC-then-)CBC and a tiny timing effect in the code; I don't believe for a second a shell tool checks the second half. (3) Removing all CBC suites effectively removes TLS 1.0 and 1.1 because with RC4 broken much worse you are left with only GCM which requires 1.2.
    – dave_thompson_085
    Commented Jul 19, 2017 at 4:24

1 Answer 1

Reset to default
1

As suggested by @StackzOfZtuff, this was a false-positive of the testssl.sh tool.

Confirmed here: https://github.com/drwetter/testssl.sh/issues/789.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .