TLS Security 6: Examples of TLS Vulnerabilities and Attacks

The Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) cryptographic protocols have had their share of flaws like every other technology. The following are major vulnerabilities in TLS/SSL protocols. They all affect older versions of the protocol (TLSv1.2 and older). At the time of publication, only one major vulnerability was found that affects TLS 1.3. However, like many other attacks listed here, this vulnerability is also based on a forced downgrade attack.

POODLE

The Padding Oracle On Downgraded Legacy Encryption (POODLE) attack was published in October 2014 and takes advantage of two factors. The first factor is the fact that some servers/clients still support SSL 3.0 for interoperability and compatibility with legacy systems. The second factor is a vulnerability that exists in SSL 3.0, which is related to block padding. The POODLE vulnerability is registered in the NIST NVD database as CVE-2014-3566.

The client initiates the handshake and sends a list of 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 SSL 3.0.

The SSL 3.0 vulnerability is in the Cipher Block Chaining (CBC) mode. Block ciphers require blocks of fixed length. If data in the last block is not a multiple of the block size, extra space is filled by padding. The server ignores the content of padding. It only checks if padding length is correct and verifies the Message Authentication Code (MAC) of the plaintext. That means that the server cannot verify if anyone modified the padding content.

An attacker can decipher an encrypted block by modifying padding bytes and watching the server response. 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. 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 SSL 3.0 on the server (highly recommended unless you must support Internet Explorer 6.0).
• Upgrade the browser (client) to the latest version. If you must use an older version, disable SSLv2 and SSLv3. Most current browsers/servers use TLS_FALLBACK_SCSV. If a client requests a TLS protocol version that is lower than the highest supported by the server (and client), the server will treat it as an intentional downgrade and drop the connection.
• Some TLS 1.0/1.1 implementations are also vulnerable to POODLE because they accept an incorrect padding structure after decryption.

BEAST

The Browser Exploit Against SSL/TLS (BEAST) attack was disclosed in September 2011. It applies to SSL 3.0 and TLS 1.0 so it affects browsers that support TLS 1.0 or earlier protocols. 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. The BEAST vulnerability is registered in the NIST NVD database as CVE-2011-3389.

This is a client-side attack that uses the man-in-the-middle technique. The attacker uses MITM to inject packets into the TLS stream. This allows them to guess the Initialization Vector (IV) used with the injected message and then simply compare the results to the ones of the block that they want to decrypt.

For the BEAST attack to succeed, an attacker must have some control of the victim’s browser. Therefore, the attacker may choose easier attack vectors instead of this one.

Prevention

• Use TLS 1.1 or TLS 1.2

CRIME (CVE-2012-4929)

The Compression Ratio Info-leak Made Easy (CRIME) vulnerability affects TLS compression. The compression method is included in the Client Hello message and it is optional. You can establish a connection without compression. Compression was introduced to SSL/TLS to reduce bandwidth. DEFLATE is the most common compression algorithm used. The CRIME vulnerability is registered in the NIST NVD database as CVE-2012-4929.

This is a Wireshark capture of a Server Hello message (response to Client Hello). The server selects the NULL compression method which means that no compression will be used.

One of the main techniques used by compression algorithms is to replace repeated byte sequences with a pointer to the first instance of that sequence. The bigger the sequences that are repeated, the higher the compression ratio.

Let’s assume that the attacker wants to get a victim’s cookie. They know that the targeted website (examplebank.com) creates a cookie for the session named adm. The attacker knows that the DEFLATE compression method replaces repeated bytes. Therefore, the attacker injects Cookie:adm=0 into the victim’s cookie. The server will append only 0 to the compressed response because Cookie:adm= is already sent in the victim’s cookie, so it is repeated.

All that the attacker must do is to inject different characters and then monitor the size of the response. If the response is shorter than the initial one, the injected character is contained in the cookie value and so it was compressed. If the character is not in the cookie value, the response will be longer.

Using this method an attacker can reconstruct the cookie value using the feedback that they get from the server.

Prevention

• Upgrade your browser to the latest version

BREACH

The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) vulnerability is very similar to CRIME but BREACH targets HTTP compression, not TLS compression. This attack is possible even if TLS compression is turned off. An attacker forces the victim’s browser to connect to a TLS-enabled third-party website and monitors the traffic between the victim and the server using a man-in-the-middle attack. The BREACH vulnerability is registered in the NIST NVD database as CVE-2013-3587.

A vulnerable web application 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, such as cookies, are safe from this attack).

Prevention

• Disable HTTP compression
• Separate secrets from user input
• Randomize secrets per request
• Mask secrets (effectively randomize by XORing with a random secret per request)
• Protect pages against CSRF
• Hide the length (by adding random numbers of bytes to responses)
• Limit the rate of requests

Heartbleed

Heartbleed was a critical vulnerability that was found in the heartbeat extension of the popular OpenSSL library. This extension is used to keep a connection alive as long as both parties are still there. The Heartbleed vulnerability is registered in the NIST NVD database as CVE-2014-0160.

The client sends a heartbeat message to the server with a payload that contains data and the size of the data (and padding). The server must respond with the same heartbeat request, containing the data and the size of data that the client sent.

The Heartbleed vulnerability was based on the fact that if the client sent false data length, the server would respond with the data received by the client and random data from its memory to meet the length requirements specified by the sender.

Leaking unencrypted data from server memory can be disastrous. There have been proof-of-concept exploits of this vulnerability in which the attacker would get the private key of the server. This means that an attacker would be able to decrypt all the traffic to the server. Server memory may contain anything: credentials, sensitive documents, credit card numbers, emails, etc.

Prevention

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

Conclusion

SSL/TLS protocols are used to secure data transmission but badly configured servers may expose data instead of securing it. An easy way to test if your website or web application uses a vulnerable SSL/TLS configuration is to run an automated scan using the online Acunetix vulnerability scanner, which includes a network security scanner. At the same time, you can also test for web vulnerabilities. Request a demo to see how you can identify and report insecure setups.

In most cases, the best way to protect yourself against SSL/TLS-related attacks is to disable older protocol versions. This is even a standard requirement for some industries. For example, June 30, 2018, was the deadline for disabling support for SSL and early versions of TLS (up to and including TLS 1.0) according to the PCI Data Security Standard. The Internet Engineering Task Force (IETF) released advisories concerning the security of SSL: RFC 6176 and RFC 7568. Deprecation of TLS 1.0 and 1.1 by IETF is expected soon.

Frequently asked questions

THE AUTHOR

Agathoklis Prodromou
Web Systems Administrator/Developer

Akis has worked in the IT sphere for more than 13 years, developing his skills from a defensive perspective as a System Administrator and Web Developer but also from an offensive perspective as a penetration tester. He holds various professional certifications related to ethical hacking, digital forensics and incident response.