SSL/TLS Vulnerabilities: LuckyThirteen & BEAST

Summary

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols designed to secure communications over a network, vital for protecting sensitive information exchanged online, ensuring confidentiality, authentication, and integrity. However, if vulnerabilities exist in the implementation of these protocols or their cryptographic mechanism, the can be susceptible to attacks like **BEAST** and **LuckyThirteen**, two attacks that take advantage of such vulnerabilities.

BEAST Attack

The BEAST (Browser Exploit Against SSL/TLS) attack, discovered in 2011, targets a weakness in the Cipher Block Chaining (CBC) mode encryption used in SSL 3.0 and TLS 1.0. It is a type of blockwise chosen plaintext attack.

Attack Mechanism

BEAST exploits the fact that in TLS 1.0, the Initialisation Vector (IV) for each block of plaintext is the last ciphertext block of the previous message. This makes the IV predictable, a vulnerability in CBC mode where each plaintext block is XORed with the previous ciphertext block before encryption. An attacker can intercept the connection between a client and a server and inject specially crafted data into the victim's connection. By controlling this injected plaintext, the attacker forces the encryption of predictable blocks. Analysing these blocks and applying a known-plaintext attack, the attacker can progressively recover parts of the ciphertext, ultimately decrypting sensitive data like authentication cookies.

The attack requires the attacker to:

• Have access to the encrypted communication
• Be able to inject data into the victim's connection
• Downgrade the connection to force the use of TLS 1.0

Impact

BEAST was successfully demonstrated against browsers using vulnerable TLS versions, proving its practicality in real-world scenarios. This attack highlighted the risks of predictable IVs in CBC mode. It pushed for the adoption of newer TLS versions that address this vulnerability.

Countermeasures

• Upgrading to TLS 1.1 or newer: TLS 1.1 and later versions, such as TLS 1.2 and TLS 1.3, use randomly generated, explicit IVs for each record transmitted, eliminating the predictable IV weakness that BEAST exploits. TLS 1.2 also introduces AEAD algorithms, like AES-GCM.
• Using RC4 stream cipher: Although RC4 mitigates BEAST by avoiding CBC mode, it is no longer recommended due to its own security flaws.
• Client-side mitigations: One such technique is 1/n-1 record splitting, which involves splitting encrypted data into small records, typically one byte long. This fragmentation prevents the attacker from conducting a full blockwise-chosen plaintext attack. However, record splitting introduces inefficiencies and can degrade performance. Additionally, this method only protects the client and does not address server-side vulnerabilities in TLS 1.0.
• Secure HTTP headers: Implementing HTTP Strict Transport Security (HSTS) enforces HTTPS communication, preventing downgrade attacks that could force the use of vulnerable protocols. Secure Cookies ensure that cookies are transmitted only over HTTPS, protecting sensitive information.

LuckyThirteen Attack

Lucky 13 is a timing attack on TLS/DTLS protocol discovered in 2012 by Nadhem AlFardan and Kenny Paterson (University of London). It was named as CVE-2013-0169 and is based on the Padding Oracle Attack. In 2013, they published their findings and released their white paper. The LuckyThirteen attack targets how TLS handles CBC-mode encryption with the MAC-then-Encrypt approach in versions up to TLS 1.2.

Attack Mechanism

This attack is a type of padding oracle attack. It exploits timing variations that occur during the decryption process in TLS versions prior to 1.2. Specifically, it targets the order of operations where the server checks the padding before verifying the MAC. This can lead to time discrepancies depending on whether the padding or the MAC causes a decryption failure.

The attacker:

• Intercepts TLS-encrypted traffic
• Submits modified ciphertext blocks repeatedly
• Measures timing differences to distinguish between valid and invalid padding

By carefully manipulating the ciphertext, the attacker can induce predictable padding bytes in the final block, allowing them to deduce the plaintext through repeated trials. The timing variations exploited can be as small as a few hundred clock cycles.

The attack is more likely to be successful:

• In low-latency environments such as internal networks
• When the attacker can directly access the target's network
• On HTTPS connections where sensitive data is at a predictable location in the message

Impact

Although technically challenging and requiring a high number of requests and precise timing measurements, LuckyThirteen demonstrated the feasibility of side-channel attacks targeting timing differences. It highlighted the importance of constant-time cryptographic operations in TLS.

Countermeasures

• Random time delays: This countermeasure aims to obscure timing differences but is largely ineffective.
• Using RC4: Switching from CBC-mode encryption to the RC4 stream cipher eliminates padding-related vulnerabilities. However, RC4 has been deprecated due to its own security weaknesses.
• Using Authenticated Encryption: AEAD algorithms like AES-GCM, introduced in TLS 1.2, offer a more secure alternative by combining encryption and integrity protection in a single step, eliminating the need for separate MAC computation and padding checks. This directly addresses the vulnerabilities in the MAC-then-Encrypt construction used in earlier TLS versions with CBC mode.
• Careful implementation of CBC decryption: Implementing CBC-mode decryption to operate in constant time, irrespective of the input data, would eliminate timing discrepancies. This ensures that decryption and MAC verification processes always take the same amount of time. This solution, while effective, is challenging to implement correctly.

Mechanisms used in the attacks

The Padding Oracle Attack

The Padding Oracle Attack is a TLS vulnerability which allows an attacker to retrieve the original plaintext from the ciphertext. There are 4 main things needed for the attack:

• XOR Operation
• Block Cipher (CBC Mode)
• Padding Standard
• Oracle

XOR Operation

The XOR operation (short for "exclusive OR") is a logical operation that takes two input values and returns an output value of true (1) if and only if exactly one of the input values is true (1). If both input values are true or both input values are false, the output value is false (0). The truth table for the XOR operation is shown below:

The XOR operation is done byte-by-byte, bit-by-bit and it is important that if there are two known values it is possible to get the remaining:

• A ⨁ B = C
• A ⨁ C = B
• B ⨁ C = A

Basics

Cipher Block Chaining (CBC) and MAC-then-encrypt are being used in the DTLS record protocol.

Cipher Block Chaining (CBC)

CBC is a method of encrypting plaintext. The Plaintext is encrypted with the Initialization Vector and the key through XOR Operation. It takes a block of clear text and adds it (bit-by-bit) to the previous encryption.

IV = Initialization Vector is a (pseudo)random sequence of characters added to an encryption key. The IV should be different for any two messages encrypted with the same cryptography key. First step is to divide the pain text into block size (size depends on underlying symmetric encryption algorithm). Plain text (<math>P_i</math>) and previous ciphertext (<math>\C_{i-1}</math>) are combined with an XOR operation. Then it gets encrypted with the key. Repeat. In the first step we do not have any ciphertext (<math>C_i</math>) so we use the IV (initialization vector) for this one. <math>E</math> stands for the encryption process.

This leaves us with this formula:

<math>C_i = E(P_i \oplus C_{i-1})</math>

Encryption

Decryption

Padding Standard

With CBC-Mode the Ciphertext is split into Blocks. All Blocks have the same length of 8 bits. So, it could be necessary to fil up the last bits with padding.

A common system of padding is Public Key Cryptography Standard #7, or PKCS #7.

Oracle

The Oracle is the server who answers to the question if the padding is valid.

MAC-then-encrypt

MAC provides message authentication. Sender and receiver share a symmetric key.

• The sender uses some publicly known MAC algorithm, inputs the message and the secret key K and produces a MAC value.
• Send it.
• On receipt of the message and the MAC, the receiver feeds the received message and the shared secret key K into the MAC algorithm and re-computes the MAC value.
• The receiver now checks equality of freshly computed MAC with the MAC received from the sender. If they match, then the receiver accepts the message and assures themself that the message has been sent by the intended sender.

DTLS Record Protocol

Encryption

<math></math>

<math>R</math> = individual record (payload)

MAC calculation:

<math>T = \mathtt{SQN}||\mathtt{HDR}||R</math> SQN and HDR are prepended and are 13 bytes long:

• SQN = 8-byte
• HDR = 5-byte
  • version field = 2-byte
  • type = 1-byte
  • length = 2-byte

<math>T</math> is the resulting MAC.

Next, the plaintext (<math>P</math>) is created to encrypt with the following formula:

<math>P = R||T||\mathtt{pad}</math>

pad stands for "padding" which is appended to the plaintext. The size of the padding is to fit the block size of the selected block cipher (3DSE = 8 bytes/ AES = 16 bytes). Padding may span over several blocks. Padding added in TLS and DTLS must consist of <math>p+1</math> copies of the same byte value <math>p</math>. The Range for <math>p</math> is <math>0 \le p \le 255</math>. For example, 1 times “0x00” or 3 times “0x02”.

Now the plaintext is being encrypted with CBC-mode:

<math>C_j=E_{K_e}(P_j \oplus C_{j-1})</math>

<math>P_j</math> is the information we want to encrypt. <math>_j</math> identifies the different blocks we want to encrypt. <math>C_0</math> is our starting point (IV). <math>K_e</math> is for the block cipher <math>E</math>.

Put together the data encrypted and being transmitted is:

<math>\mathtt{HDR}||C</math>

<math>C</math> being the cipher text and HDR including version, type and length field. No sequence number (SQN) being transmitted.

Decryption

<math>P_j=D_{K_e}(C_j) \oplus C_{j-1}</math>

<math>D</math> = Decryption algorithm of the block cipher. <math>P_j</math> is the Plaintext we receive. The decryption is performed block by block. When finished, the padding is removed and the MAC is being checked. Finally, the sequence number can be checked.

HMAC

TLS and DTLS exclusively use the HMAC algorithm. HMAC-MD5, HMAC-SHA-1, and HMAC-SHA-256 are supported in TLS 1.2.

Fomula:

<math>T = H((K_a \oplus \mathtt{opad})||H((K_a \oplus \mathtt{ipad})||M))</math>

<math>T</math> = MAC tag <math>M</math> = Message <math>K_a</math> = Key <math>H</math> = Algorithm

HMAC applies the specified hash algorithem twice in an iterated fashion.

opad and ipad are specific 64-byte values (padding) that combined with the Key are exaclty 64 bytes. The hash function uses an encoding step called Merkle-Damg ̊ard strengthening.

HMAC is computed of 64 byte blocks. This block takes 8 bytes for the header and at least 1 byte of padding. 55 bytes of data is the maximum a single block can take. A Message of the length up to 55 bytes need 4 comparison function evaluations to complete: 2 in the hash operation, 2 in the outer hash operation. Messages from 55 up to (64+55=) 119 bytes give us two 64-byte block. This means that the we have 3 inner hash operations and 2 outer hash operations. For more blocks (3 and more) we can assume you add 1 operation per block. Remember that every operation takes some amount of time to be computed. Operations are in the sub-μ seconds spectrum.

Important points of an attack (Oracle)

There are some important points for the attack:

• A “yes” from the Oracle helps narrow down things further than a “no“
• The attacker knows the ciphertext (and therefore the ciphertext blocks)
• The attacker can control which ciphertext is input into the Padding Oracle
• By changing the ciphertext input, the attacker also changes the decrypted plaintext that the Padding Oracle sees
• Force the decrypted plaintext to have valid padding by manipulating the input ciphertext

The attacker changes the last bit of the ciphertext t1 and waits for the server to answer if the padding is valid or invalid. If the padding is valid the attacker knows the last bit of C1 (t1) and the last bit of P2 (01). So X1 = t1 ⨁ 01. With this the attacker can guess the plaintext.

References

Seminar paper

• File:Lucky Thirteen.pdf

References

• Kenny Paterson. Lucky 13, beast, crime, ... is tls dead, or just resting?, 2022.
• Pratik Guha Sarkar and Shawn Fitzgerald. Attacks on ssl a comprehensive study of beast, crime, time, breach, lucky 13 & rc4 biases. August 2013.
• Nadhem J. AlFardan and Kenneth G. Paterson. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. February 2013.

Links

• https://en.wikipedia.org/wiki/Exclusive_or
• https://www.elektronik-kompendium.de/sites/dig/0205186.htm#:~:text=Das%20XOR%20ist%20ein%20zusammengeschaltetes,A%20und%20B%20ungleich%20sind
• https://web.engr.oregonstate.edu/~rosulekm/crypto/padding.html#attack
• https://samsclass.info/141/proj/p14pad.htm
• https://medium.com/@c0D3M/lucky-13-attack-explained-dd9a9fd42fa6
• https://www.youtube.com/watch?v=4EgD4PEatA8

• http://web.archive.org/web/20190414143311/http://www.isg.rhul.ac.uk/tls/TLStiming.pdf