SLOTH Downgrades TLS 1.2 Encrypted Channels

Early last month a new vulnerability was found in how TLS 1.2 was implemented. Researchers from the French Institute for Research in Computer Science and Automation (INRIA) called this new attack SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes). An attacker with man-in-the-middle capabilities could use SLOTH to attack encrypted traffic in the following ways:

decrypt encrypted traffic
impersonate a legitimate client
impersonate a legitimate server

This attack was dubbed as SLOTH because it relies on the attacker forcing the usage of a weak hash algorithm; it is the first publicly known preimage/collision attack against the TLS, IKE and SSH protocols. In addition, the paper also reveals a weakness in how the TLS protocol is implemented in many widely used SSL/TLS libraries: TLS1.2 Signature Algorithm Downgrade. This post is going to show the mechanism behind the downgrade, and how to protect against it.

TLS1.2 Signature Hash Algorithm Downgrade.

In the past, we have seen bugs in SSL/TLS where attackers can force clients/servers to downgrade to weaker SSL/TLS protocol versions and cipher suites. POODLE, FREAK, and Logjam all worked this way. SLOTH is different; it can force clients/servers to downgrade to a weaker hash algorithm, lowering the amount of computing power needed for a successful attack. There are two possible downgrades, client side and server side:

Client side: Occurs when the TLS client accepts a weak hash algorithm from the server. In the case of SLOTH, the new field named SignatureAndHashAlgorithm present in ServerKeyExchange in TLS 1.2 allows this downgrade.
Server side: Occurs when server accepts a weak hash algorithm from the client. In case of SLOTH, the TLS message ClientCertificateVerify allows this.

In the following section we are going to show one example of a client side downgrade attack.

Client side TLS 1.2 MD5 Downgrade

Prior to TLS 1.2, there was no option for client and server to negotiate the signature and hash algorithm. A concatenation of MD5 and SHA1 was always used. TLS 1.2 introduced a new SignatureAndHashAlgorithm field in the ServerKeyExchange message to allow the server to specify which signature and hash algorithms the client must use. Unfortunately, this also allows attackers to force the client to downgrade to a weaker hash algorithm, like MD5. The following process demonstrates how the downgrade happens:

At the start of handshake the client will send the Client Hello packet to the server; the packet states the signature and hash algorithms the server can use. However, a malicious attacker that can intercept this packet and send back a packet that suggests different (and weaker) algorithms, which the client will accept. This allows an attacker to start an attack impersonating a target server.

The figures below will help show this attack more clearly. Figure 3 shows an example of a Client Hello message that doesn’t include RSA-MD5 as an acceptable algorithm:

Figure 1. Client Hello without RSA-MD5 Signature Algorithm.

An attacker sitting between the client and server will respond to the client request with the Server Hello, Certificate and Server Key Exchange replies. In Server Key Exchange the attacker will not use the actual algorithms specified by the client, instead the attacker will specify RSA-MD5.

Figure 2. Server Response with RSA-MD5 signature hash algorithm in Server Key Exchange.

The client accepts the server’s response, and the client ends up using a weak hash algorithm and the client will respond back with the Client Key Exchange message, and the handshake will be successfully completed.

Figure 3. Attacker successfully downgraded the Client to use weak hash algorithm

The MITM attacker can impersonate the server and decrypt all encrypted traffic once the TLS channel is downgraded.

Server-side TLS 1.2 MD5 Downgrade

The SLOTH attack also works from the opposite direction. An attacker can use it to impersonate the client and force the server to use a weak signature and hash algorithm. The mechanism used in this case is described in the following section.

At the start of handshake, the client will send the Client Hello packet to the server. An attacker sitting between the client and the server can intercept this and forward a forged Client Hello packet which specifies that the RSA-MD5 is the only supported signature algorithm.

Figure 4. Attacker sent Client Hello with signature Algorithm RSA-MD5 only.

The MITM attacker can also send additional data in the signature_algorithms field containing values unsupported by the server, which will ignore it. The attacker can now impersonate the client once the TLS channel is downgraded, bypassing TLS-level client authentication.

Remedies

The response from many TLS implementations was to remove MD5 support in signatures from TLS 1.2 onwards. Upgrading existing TLS stacks will solve the issue in most of the cases. However, the upgrade cannot be limited to TLS as SSH and VPN services can be also affected by SLOTH. We recommend reviewing all configurations related to TLS, SSH, and VPN services and disabling MD5 support. At same time, if the secure communication infrastructure is using third party communication device, review the current configuration and check for vendor updates.

While the SLOTH paper describes the combined attack where client impersonation and server impersonation are both occurring at the same time, these attacks can be implemented independently.

Trend Micro Deep Security customers are protected in two different ways:

DPI rules that can alert security administrators if weak TLS configurations are being used in the network. These rules are very important because they detect possible undesirable weaker algorithms in the TLS stack, in this case the use of MD5.

DPI rules that prevent the SLOTH attack. These rules stop the attack and block the MITM malicious device.

For the first case Trend Micro Deep Security customers can apply the following DPI rules:

1007382- Identified MD5 Hash Algorithm In TLS Server Key Exchange Traffic – Client
1007380- Identified MD5 Hash Algorithm In TLS Server Key Exchange Traffic – Server

For the second case Trend Micro Deep Security customers can apply the following DPI rules:

1007384- TLS1.2 Signature Hash Algorithm Downgrade Attack Used In SLOTH – Client
1007379- TLS1.2 Signature Hash Algorithm Downgrade Attack Used In SLOTH – Server

In both cases clients and servers using TLS are protected.

Conclusions

The SLOTH attack demonstrates several weaknesses in newer versions of TLS protocol and implements the first public preimage-collision attack to the TLS, IKE and SSH protocols. This attack can be implemented even when weak cipher suites are disabled from the secure protocols stack. Sometimes, understanding the consequences of weak use of cryptography are not immediately evident, and this is one of those cases.

Patching the systems will prevent the SLOTH attack; however Trend Micro Deep Security is able to protect its customers in scenarios where patch deployment takes some time due to maintenance delays or patching incompatibility issues. Trend Micro Deep Security IPS rules will block SLOTH attacks.

We recommend the auditing of the entire TLS, SSH, VPN stack as well as checking for third party devices acting as load balancing in the TLS channel path.