1. Support Center
  2. SSL / TLS Vulnerabilities
  3. Vulnerabilities requiring reconfiguration

What Is LUCKY13 and How To Prevent It

The SSL LUCKY13 is a cryptographic timing attack that can be used against implementations of the TLS and DTLS protocols using the Cipher Block Chaining mode of operation. This can also be considered a type of man-in-the-middle attack.

LUCKY13 Security Assessment

Security_Assessment_PreventSSLLUCKY13

CVSS Vector: AV:N/AC:H/AU:N/C:P/I:N/A:N

Vulnerability Information

The vulnerability that allows the SSL LUCKY 13 to be made is due to a flaw in the SSL/TLS specification, rather than due to issues in specific implementations. 

The attack can be considered a more advanced type of padding oracle attack that exploits different calculation times depending on the plaintext being padded with one or two bytes or containing incorrect padding.

Under OpenSSL, the attack allows a full plaintext recovery, whereas for GnuTLS a partial plaintext recovery attack can be conducted. In the latter case, an attack can recover up to 4 bits of the last byte of blocks of plaintext.  

As a result of a successful attack, an attacker exploiting this vulnerability is able to read the plaintext of a TLS encrypted session. This can result in the loss of sensitive information.

Occurrence Of The LUCKY13 Attack

In a nutshell, this attack relies on a difference in processing times between TLS messages with at least two bytes of correct padding and TLS messages with one byte of correct padding (or incorrectly formatted padding). Transport Layer Security messages with two bytes of padding are processed somewhat faster, and this difference can be detected when the arrival of TLS error messages is timed.

Attacker-generated ciphertexts are sent to the same place in the plaintext stream during several TLS sessions to establish this difference. This generates an error message in the network as a response.

By repeatedly launching an attack and carefully analyzing the responses, these different padding conditions can be distinguished from each other. Then, using the packet’s timing data, an attacker can execute a plaintext-recovery attack on the MAC check while processing a malformed CBC padding.

SSL LUCKY13

Timing Attack results in long (red) and short (blue) fake padding (AlFardan & Paterson, 2013).

In its most basic version, a LUCKY 13 attack requires about 223 TLS sessions to collect a whole block of TLS-encrypted plaintext. This can be reduced several times and under the best circumstances, an attacker needs 2¹³ TLS sessions to recover one plaintext byte. This is premised on the condition that the attacker is close to the target (i.e., in the same network as the webserver) to reduce any noise and perform the timing attack. To generate the necessary TLS sessions, attackers have several options. As a result of the attacks, a TLS session that is running may be terminated. Applications that use this protocol may then attempt to reconnect and will also send cookies or authentication credentials.

Another way of generating sessions is through the use of malware on the client side. This is akin to a BEAST attack though it does not need to circumvent the same-origin policy because it is not a form of injection attack.
In DTLS sessions, attacks can even be executed within a single session with the help of amplification techniques that make the timing signals more pronounced and easier to spot.

How to Protect against SSL LUCKY 13?

Apart from patches, a number of mitigation techniques exist that will allow you to protect yourself from this type of attack. These mitigation techniques were put forward by AlFardan & Paterson who made this vulnerability known. They include:

  • Adding random time delays to the CBC-mode decryption process to frustrate statistical analysis is a possible countermeasure you can take. However, it is not particularly effective if implemented solely since it can be overcome by attackers by simply increasing the number of samples that they take. 
  • Switching from a block cipher to an RC4 stream cipher in order to avoid the need for plaintext padding (i.e. CBC-mode encryption) altogether. This cannot be implemented under Datagram Transport Layer Security (DTLS). Switching a stream cipher will entirely eliminate the possibility of attacks as described above. RC4 ciphersuites are widely supported in TLS implementations and are also a successful strategy against BEAST attacks. However, RC4 has certain cryptographic weaknesses when used in TLS that must be accounted for. RC4, when used in TLS, contains single-byte biases which are not discarded before the encryption. This allows for remote attacks to be conducted, such as the Bar-mitzvah attack. For this reason, switching to RC4 is also only a temporary fix of the LUCKY 13 vulnerability.
  • Switching from MEE-TLS-CBC to AEAD ciphersuites, i.e. dedicated encryption algorithms, such as AES-GCM is also a possibility for entirely eliminating the possibility for a LUCKY 13 attack. This does not rule out the possibility for errors during implementation, nor the potential for the use of side-channels. Support for these ciphersuites was added in TLS 1.2 client and server implementations.
  • Modifying the CBC-mode decryption procedure is the final mitigation strategy proposed by AlFardan & Paterson. Its intended purpose is to remove the timing side-channel by ensuring a uniform processing time for all ciphertexts under this mode. In other words, the processing time must only be related to the size of the ciphertext, and not to the plaintext (and its padding). This is achieved by ensuring that the MAC processing amount does not differ regardless of what the underlying plaintext indicates as the message length. This approach requires great care and attention and is likely to present a challenge. For this reason, the most viable long-term mitigation strategy for avoiding SSL LUCKY 13 attacks is to avoid using TLS in CBC-mode and also implement the use of AEAD ciphersuites.

How To Prevent LUCKY13 Attacks

In addition to the above countermeasures, you can prevent the LUCKY13 attack by using the following Transport Layer Security configuration in Apache and Nginx.

Apache

With apache, the SSL/TLS configuration is stored in /etc/apache2/mods-enabled/ssl.conf. If you use Let's Encrypt, the configuration may reside in /etc/letsencrypt/options-ssl-apache.conf. To enable only ciphers with high encryption and recent protocols set:

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off

Then reload the Apache server configuration.

Note, that this limits the cipher suites and protocol version to recent SSL/TLS versions which might exclude users with older browsers.

Nginx

For Nginx, update the configuration file which is usually located at /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/yoursite.com (Ubuntu / Debian) or /etc/nginx/conf.d/nginx.conf (RHEL / CentOS). Add the following directive to the server section:

ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;

Then restart the Nginx server.

Note, that this limits the cipher suites and protocol version to recent SSL/TLS versions which might exclude users with older browsers.

For more information about Crashtest Security visit crashtest-security.com