Findings Series: Deprecated TLS/SSL Protocol Versions Supported

Graham O'Donnell -

Contents

Description

Transport Layer Security (TLS) and Secure Socket Layer (SSL) Protocols are used to establish connections between a client and server. TLS/SSL protocols underlay a significant portion of the communcation conducted between computers. Vulnerabilites in TLS and SSL protocols arise from cryptographic failures often exploited throught an adversary-in-the-middle attack. These attacks allow for the decryption and monitoring of communciations between a client and server. Attacks such as BEAST, POODLE and FREAK are examples of this type of attack against 3 different versions of TLS.

Classification

Identifying a deprecated TLS/SSL version is trivial. Exploiting the vulnerability takes significant infrastructure and resources.


Probability

Impact

Low

High - Critical

Classification Criteria

Vulnerabilities in deprecated TLS/SSL protocols are cryptographic failures that require a man-in-the-middle architecture to be implemented by the attacker in order to successfully exploit. Attacks that require this level of resources are generally only carried out by APTs. This means the probability and impact vary greatly on the kind of enterprise being assessed. The discovery of a deprecated TLS/SSL protocol is often automated during a vulnerability assessment. Because the resource requirement of exploiting this vulnerability is so great, there would need to be significant reason to be targeted. Samller enterprises would need to worry less about facing an attack of this nature in the wild. However, because the vulnerability is so easy to patch, the exploit should be mitigated regardless.

Examples

Serious vulnerabilities exist in TLSv1.0, TLSv1.1, SSL 2.0 and SSL 3.0. SSL 1.0 was never published. The cryptographic failures discovered in each of these application layer protocols caused them to be completely deprecated. See References for the deprecation announcements. The most serious of these vulnerabilities allow for the plaintext decryption of communications between a client and server via decryption of the "secure" communication. The POODLE attack against SSL 3.0 was one such attack. Here is how it works:

Padding Oracle On Downgraded Legacy Encryption (POODLE)

The POODLE attack requires a number of elements from the attacker, but is made possible by a cryptographic failure present in SSL 3.0 and Cipher Block Chaining. The following must be true for POODLE to be successful:

  1. The attacker must have the ability to listen to requests between the target client and target server.
  2. The client and server must both support SSL 3.0 as a fall back protocol.
  3. The attacker must be able to intercept and modify SSL requests sent between the target client and the target server. This can be accomplished with a successful Cross-Site Scripting attack.

If these three conditions are satisfied, an attacker can modify the padding at the end of a given SSL request to try to force the first byte of the last block of an SSL request into the position of the last byte in the second to last block. Due to inherent failures in Block Chain cipher suites, this shift in the request body allows the attacker to decrypt the shifted byte. It takes an average of 256 illegtimate requests to reveal the shifted byte, at which point the attacker adds more padding, shifts the next byte and repeats the process of iterative decryption. The technical details are outlined in the whitepaper in the references section.

Let's look at this applied. Suppose we have 3 devices:

Device Address
Webserver 10.42.69.4
MitM Proxy 10.42.69.8
Client 10.42.69.11

On our proxy, we will set up an arp spoofing attack to intercept traffic between the client and the webserver:

Then, using this PoC script we can create a malicious proxy that will take the web traffic and attempt to decrypt it:

Finally, our malicious site is compromised (or deliberately trapped!) using the malicious JavaScript functions provided in the PoC repository.

When the client visits the site, the payload triggers and the data from the payload comes across our proxy. While the sniffed data is encrypted, with time it is eventually deciphered and delivered in clear text by the application.

As mentioned in the whitepaper, it will take approximately 256 requests to recover 1 byte of the victim's traffic in clear text, but with enough time the entirety of the client's traffic can be decrypted! The payload will continue to trigger thousands of requests as the HTTPS traffic is slowly shown to the attacker:

Remediation

To amend this vulnerability, disable support for the deprecated TLS versions. The exact steps to remediate this finding will vary depending on the application used.

Caveats

This misconfiguration is only permissible if there is an absolutely critical, irreplaceable piece of legacy network infrastructure that is incapable of supporting newer ciphers or TLS protocols. Such exceptions should be extremely rare.

References