SSL & TLS Attacks for the Layman - Repeated Plain Text

Posted by Arvind Doraiswamy on January 3, 2017 at 10:16 AM

In this five part blog series, I've been focusing on covering some of the attacks that have exploited various features in the SSL/TLS mechanism. We've covered general bad practices, bad implementation, and oracles. Today we'll be discussing Repeated Plain Text.

Sweet32

This is an attack (similar to BEAST) that targets a property of 3DES and likely most other ciphers that use 8 byte blocks while encrypting plain text. However, there are several prerequisites for this attack to be successful including:

  • A victim needs to be passing something confidential that consistently appears in every request (e.g. a session cookie).
  • The attacker must trick the victim into visiting a website under the attacker's control and make a very large number of requests to the target site.
  • The attacker must be in a position on the network to capture all the encrypted traffic.
  • There should eventually be a collision. In other words, bits of plain-text traffic, despite the encryption algorithm doing everything right, must look the same when encrypted.
  • The repeated confidential data should always appear in the same place when traffic is encrypted.

If all these conditions are met, an attacker could steal confidential information like session cookies and impersonate the victim.

The fix is to disable 3DES ciphers on your servers or at least ensure that it is not a preferred cipher. Also, use AES which has 16 byte blocks which ensures it will take exponentially longer to have a collision. Lastly, limit the amount of time a session stays valid so that in the event an attacker does steal a cookie, it is of no use to them.

BEAST

BEAST is a client-side SSL attack. The server is never affected.

A victim needs to be logged into a target site and must have been assigned something secret--say a session cookie. A user then must visit an attacker-controlled home page. The attacker, while sending those requests out, must be able to add data to every single request just before the cookie. If the attacker can't do this, this attack won't work.

The page the victim visited then (maybe via JavaScript) makes a large number of requests to the target site, into which the victim is logged in. The attacker then uses these requests and tries to decrypt the secret cookie. This is an example of a chosen plain-text attack where an attacker can send a million plain-texts, get their ciphertext, analyze them and try to wreak havoc. An attacker can obtain the cookies even if HTTPS is in use and the secure flag is turned on. This is considered an attack because of how CBC works by default. Every cipher suite that uses CBC internally is affected.

RC4 has been suggested by some as a defense as it was a good cipher (at the time) that didn't use CBC. But RC4 is bad for many other and worse reasons--some of which are described in my previous post. I highly suggest never using RC4.

TLS 1.1/1.2 on the other hand is best as it protects you against BEAST by default. If all of your clients support TLS 1.1/1.2 and none depend on TLS 1.0/SSL3.0, disable RC4 and go this route instead.

Topics: developer guidance, crypto

Arvind Doraiswamy

Written by Arvind Doraiswamy

Arvind is a Senior Security Engineer who focuses on conducting security assessments for clients, contributing articles to our secure coding knowledgebase, and writing tools to improve our company's security testing efficiency for clients.