0

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?

  • You ran a bash shell script on a Windows server? It looks like only open source software is affected - PolarSSL, OpenSSL & OpenJDK. – DKNUCKLES Jul 18 '17 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 Jul 18 '17 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 Jul 18 '17 at 14:23
  • 1
    @KevinMorssink 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 Jul 18 '17 at 14:30
  • 1
    @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 Jul 19 '17 at 4:24
0

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.