Vulnerabilities that (mostly) aren’t: LUCKY13

TL;DR

• LUCKY13 is more an attack than a vulnerability
• LUCKY13 was patched over a decade ago … so it’s really unlikely that your server is vulnerable now
• It’s an implementation issue
• Disabling CBC ciphers is still a good idea … but not because of susceptibility to LUCKY13
• There is no material risk in this issue
• Accurate remote detection is rarely possible

Introduction

It’s been a while since I wrote a “Vulnerabilities that (mostly) aren’t” post, but a recent discussion in our pen testing teams brought about a change in how we’re reporting LUCKY13 (and potentially other TLS vulnerabilities), leading me to revisit this vulnerability.

What is it?

The LUCKY13 attack was a vulnerability and tied attack identified in February 2013 by AlFardan and Paterson of the Royal Holloway, University of London and given CVE-2013-0169. It’s an attack on CBC cipher suites within versions of SSL / TLS from 3.0 to 1.2 and DTLS (TLS over UDP) 1.0 and 1.2.

The attack uses mistakes in implementations in the protocol’s MAC which can cause timing differences and lead to the decryption of data which has some known plaintext.

Let me rephrase that: if you can intercept and inject traffic into a TLS / DTLS data stream that you know some plaintext (e.g. a Cookie: HTTP header) you can inject errors. This can cause a time difference between the various sizes of blocks due to the way that the Message Authentication Code (MAC) is calculated. This could lead to the decryption of important fragments of data (although these fragments can be chosen, so could be cookies).

In the original paper a block of base64 data could be recovered in around 500 000 sessions; which sounds like a lot but isn’t much compared to the size of a video file, or the average JavaScript libraries on a modern website.

Why is it not a vulnerability

The original paper did indeed show a viable attack technique against a number of viable implementations of TLS; which included most of big names, such as OpenSSL, GnuTLS, BouncyCastle, Oracle’s Java, NSS; but not SChannel (Microsoft’s implementation).

The technique was responsibly disclosed and patched by all vendors in the first quarter of 2013. Source code for the attack was not released, although it would not be difficult to write your own code to exploit this from the original paper.

To rephrase this: if the implementation of TLS your software uses was vulnerable in the first place, then it is most likely it was patched in 2013 and there is no impact from LUCKY13.

Many of the patched implementations have themselves been deprecated and have been replaced by versions which have timing protection included.

I originally went through the source code of OpenSSL 1.0.1c (vulnerable) and 1.0.1e (fixed) to try and highlight the changes; but there’s quite a chunk of changed code, which would be hard to show in a concise manner.

Why is it reported?

Most security consultants and software report this vulnerability by the usage of CBC ciphers, such as TLS_RSA_WITH_3DES_EDE_CBC_SHA or TLS_RSA_WITH_AES_128_CBC_SHA, being able to be negotiated on the server.

This is an easy report – there are few disadvantages to disabling CBC cipher suites … and perhaps the advantages are not primarily mitigation of LUCKY13 but instead prioritisation of more modern, stronger cipher suites. Now Internet Explorer is end of life there are no major browsers that do not support viable replacements at TLS 1.2 / 1.3; and thus, there is little impact to implementing the fix.

The problem is that allowing CBC ciphers does not actually mean that you are vulnerable to the LUCKY13 attack – remember, if your implementation was vulnerable in the first place it is highly likely that it was fixed over a decade ago.

(Caveat: roll your own, or legacy versions may be vulnerable. This is why you don’t roll your own and why you shouldn’t use versions of libraries over 10 years out-of-date.)

What’s wrong with disabling CBC ciphers?

Nothing and it’s something I would strongly recommend that you do, along with other legacy ciphers. I’d go further and say that these should be disabled by default in the implementation of the software you use.

So why am I writing this?

Ultimately the Information / Cyber security field is about highlighting and managing risk. It is expected that a security consultant uses their expertise to score a finding with the appropriate level of risk.

LUCKY13 no longer has significant risk, assuming that an environment has patched in the past 10 years and doesn’t use legacy implementations.

Conclusion

So why does this blog exist? I wanted to document our logic over why we’re breaking the chain of just reporting this attack as a vulnerability and to get it documented so time is not wasted fixing things that add no risk to the environment and to provide information to raise to tools or other vendors to ensure that the risk is appropriately reported.

Other TLS vulnerabilities exist and will be dealt with separately.