TLS/SSL Explained: Examples of a TLS Vulnerability and Attack, Final Part

In part 1, 2, 3, and 4 of this series we looked at What is TLS/SSL?, TLS/SSL terminology and basics, TLS/SSL Certificates and Establishing a TLS/SSL Connection. In this, the final part in the series, we will be looking at examples of a TLS vulnerability and attacks.

As with any technology, SSL/TLS has its flaws. Successful attacks on a security protocol that is designed to protect you, defies its purpose and jeopardizes the integrity, confidentiality, and authenticity of information transmitted.

We’ll now review some of the most recent dangerous attacks on SSL/TLS. Due to the complexity of these attacks and the vulnerabilities they exploit, their description is simplified.

POODLE (CVE-2014-3566)

The Padding Oracle On Downgraded Legacy Encryption (POODLE) attack was published in October 2014 and takes advantage of two factors. The first is the fact that some servers/clients still support SSL 3.0 for interoperability and compatibility with legacy systems, and the second factor is a vulnerability that exists in SSL v3.0 which is related to Block Padding.

The Client initiates the Handshake and sends the list of the supported SSL/TLS versions. An attacker intercepts the traffic, performing a Man-in-The-Middle (MiTM) attack, and impersonates the Server until the Client agrees to downgrade the connection to the vulnerable SSL 3.0.

Now that the connection between Client and Server is established on a vulnerable SSL version, the attacker can perform the actual POODLE attack. The vulnerability exists in Cipher Block Chaining mode. Since Block Ciphers have a fixed length, if the data in the last block is not a multiple of its size, then padding is added to fill the extra space. One of the problems is that padding value is ignored by the server and checks only if padding length is correct as well as the Message Authentication Code (MAC) of the plaintext. That means the receiver (Server) cannot verify if padding value has been modified.

An attacker can decipher the plaintext value of an encrypted block by modifying the padding bytes and then seeing the corresponding response from the server. It takes a maximum of 256 SSL 3.0 requests to decrypt a single byte.

This means that once every 256 requests, the server will accept the modified value. The attacker does not need to know the encryption method or key to pull off this attack. Using automated tools, an attacker can retrieve the plaintext character by character. This could easily be a password, a cookie, a session, or other sensitive data.

Prevention

• Completely disable SSL3.0 on the server (Recommended).
• Upgrade browser (client) to the latest version or if for whatever reason you need to use an older version be sure to disable SSL 2.0 and SSL 3.0 Protocols. Most up to date browsers/servers use TLS_FALLBACK_SCSV. If a client requests a TLS protocol version which is lower than the highest supported by the server (and client), the server will identify intentional downgrade fallback and will drop the connection.
• Some TLS 1.0/1.1 implementations are also vulnerable to POODLE as they accept incorrect padding structure after the decryption.

BEAST (CVE-2011-3389)

The Browser Exploit Against SSL/TLS attack was published in September 2011 and affects SSL 3.0 and TLS 1.0. An attacker can “decrypt” data exchanged between two parties by taking advantage of a vulnerability in the implementation of the Cipher Block Chaining (CBC) mode in TLS 1.0 which allows them to perform chosen plaintext attacks.

As the name implies, this attack is performed client-side (browser) using the Man-in-The-Middle technique. Using MiTM, an attacker can inject packets into the TLS stream. This allows an attacker to guess the Initialization Vector used in XORing with the message they injected, and then simply compare the results to the ones of the block they want to “decrypt.”

It’s worth noting that for the BEAST attack to succeed, an attacker must have reasonable control of the victim’s browser, in which case it is more probable that an easier attack vector is chosen.

Prevention

• Use TLS 1.1 or TLS 1.2.

CRIME (CVE-2012-4929)

Compression Ratio Info-leak Made Easy is a vulnerability found in TLS compression. The compression method is included in the ClientHello message and it is optional, meaning that the connection can be established without any compression.

This is a Wireshark capture of a ServerHello message (response to ClientHello), selecting the NULL compression method which means that no compression will be used.

The main purpose of this feature (compression) is to reduce the bandwidth usage while preserving integrity (lossless data transfer) and security when exchanging large amounts of information. DEFLATE is the most common compression algorithm used.

One of the main techniques used by compression algorithms is to replace repeated bytes (characters) with a pointer to the first instance of that byte. The more the repetition, the higher the compression ratio.

Let’s assume that the attacker wants to get a victim’s cookie. They know that for the session, the targeted website (examplebank.com) creates a cookie named “adm.” Having established that DEFLATE compression method replaces repeated bytes, if the attacker injects Cookie:adm=0 into the victim’s cookie, the server will append only 0 to the compressed response since Cookie:adm= is already sent in the victim’s cookie, therefore repeated.

All the attacker must do is inject different characters and then monitor the size of the response. If the size of the response is lower than the initial it means that the character they injected is contained in the cookie value and thus got compressed, which equals to a match. If the character is not in the cookie value, the size of the response will be larger.

Using this method an attacker can essentially brute-force the cookie’s value using the feedback they get from the server.

Prevention

• Upgrade browser to the latest version.

BREACH (CVE-2013-3587)

Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext is a method of exploitation which is identical to CRIME, with the exception that BREACH targets HTTP compression whereas CRIME targets TLS compression. This means that TLS compression is not required for this attack to work.

The scenario is the same. An attacker forces the victim’s browser to connect to a TLS-enabled third-party website whilst monitoring the traffic between victim and server by performing a Man-in-The-Middle attack.

For a web application to be vulnerable it must satisfy the following conditions.

• Be served from a server that uses HTTP-level compression.
• Reflect user input in HTTP response bodies.
• Reflect a secret (such as a CSRF token) in HTTP response bodies (therefore values in HTTP headers, particularly the Cookie, is safe from this attack).

Prevention

• Disable HTTP compression.
• Separating secrets from user input.
• Randomizing secrets per request.
• Masking secrets (effectively randomizing by XORing with a random secret per request).
• Protecting vulnerable pages with CSRF.
• Length hiding (by adding a random number of bytes to the responses).
• Rate-limiting requests.

Heartbleed (CVE-2014-0160)

Heartbleed was a simple to exploit, critical vulnerability found in the heartbeat extension of the popular cryptography library OpenSSL. This attack takes advantage of the TLS heartbeat extension which is primarily used as a keep-alive method between two parties to ensure that the connection is not closed if they are both still there.

The heartbeat request work as follows. The client sends a “heartbeat” message to the server with a payload which contains data+size of the data (and padding). The server must respond with the same “heartbeat” request, containing the data+size of data that the Client sent.

The problem was that, if the client sent a false data length, the server would respond with the data received by the client + random data from its memory to meet the length requirements specified by the sender even though the data was smaller than the specified length.

Having the server leaking unencrypted data from its memory can be disastrous. There have been proof-of-concept exploits of this vulnerability in which the server’s private key leaked through the Heartbleed vulnerability. This means that an attacker was able to decrypt all the traffic of the server with anything this may imply. In the server’s memory, there could be anything sent to the server for encryption such as credentials, sensitive documents, and emails.

Prevention

• Update to the latest version of OpenSSL and if that is not possible, recompile the already installed version with -DOPENSSL_NO_HEARTBEATS.

Conclusion

As we have seen, implementing TLS is a must to keep our data secure over the network. However, badly configured servers may expose, instead of secure, our data.