Cigital

BEAST and SSL/TLS

Posted On September 26, 2011 by Cigital

This is a guest post by Amit Sethi, Technical Manager at Cigital.

There has been a lot of talk about BEAST (Browser Exploit Against SSL/TLS) lately. The attack against SSL 3.0 / TLS 1.0 was recently publicized by Thai Duong and Juliano Rizzo. Do you know what the risks are, and how to protect yourself?

How does it work?

The attack has two components, and the goal is for the attacker to get your cookie so that he can hijack your session:

• Some client-side code (Java applet, Silverlight application, etc.) that is injected into a page delivered over HTTP that can make requests to a site that uses HTTPS. This may require bypassing (or finding loopholes in) same-origin security policies.
• A sniffer on the network that the victim is on, to record encrypted data generated by the client-side code. The sniffer and the client-side code need to communicate with each other for the attack to work.

The easiest way to carry out this attack is over a public Wi-Fi network; however, attackers on other types of networks including wired networks can also do this. The main requirement is that the attacker and the victim need to be on the same LAN. The attacker will need to conduct a man-in-the-middle attack to inject malicious code into a HTTP page that can make requests to the targeted HTTPS site. This attack only works if the HTTPS connection is established using SSL 3.0 or TLS 1.0 and a block cipher (e.g. 3DES or AES) in CBC mode is chosen. Unfortunately, most HTTPS sites currently support only SSL 3.0 and TLS 1.0, and prefer using block ciphers in CBC mode.

Some technical details

The main techniques used by the attack are described below. Feel free to skip this section if you don’t care about the technical details.

• Some types of client-side code (Java applets, Silverlight applications, etc.) have the ability to send partial HTTPS requests. They keep the SSL/TLS connection open, and send data as it becomes available. With SSL 3.0 / TLS 1.0, each time a new block of data is sent, a new random initialization vector is not generated. The data is simply appended to the previous stream. An attacker who sees the last ciphertext block and can control the next plaintext block can gain complete control over the next ciphertext block (this is a consequence of how CBC mode works).
• Since HTTP headers preceding cookie headers are predictable and can be obtained by an attacker who sniffs a single HTTP request from the victim, and since the attacker can control the URL of requests, he can control exactly where the cookie header’s bytes end up in relation to ciphertext block boundaries.
• If an attacker knows the previous block of ciphertext and can completely control the next block of plaintext, he can determine whether a previously seen block of ciphertext corresponded to a given block of plaintext. Let’s assume that the attacker wants to determine whether the plaintext, P_i, for a previously seen block of ciphertext, C_i was x. Now, the attacker knows C_j-1, the last block of ciphertext, and wants to set P_j, the next block of plaintext to be encrypted, to a value that helps him determine whether P_i was equal to x. If he sets P_j = C_j-1 ⊕ C_i-1P_i ⊕ x (note that C_j-1 and C_i-1 are sniffed from the network, and x is the attacker’s guess), and P_i was indeed equal to x, then C_j = E(C_j-1 ⊕ P_j) = E(C_j-1 ⊕ C_j-1 ⊕ C_i-1 ⊕ x) = E(C_i-1 ⊕ x) = E(C_i-1 ⊕ P_i) = C_i. Therefore, if the attacker’s guess is correct, then the next block of ciphertext, C_j, will equal the previously seen block of ciphertext, C_i.

Given the above details, let’s say that an attacker makes a request to /AAAAAAAAAA, and knows that it will result in a block of ciphertext containing part of the cookie header: “ookie: x” (this is realistic if a 3DES cipher suite is used). Now, the attacker can make all 256 possible guesses for x, and can determine the first byte of the cookie header. Next, the attacker can make a new HTTP request to /AAAAAAAAA (one less A, which shifts the cookie header one position to the left such that the ciphertext block is now “okie: xy”) and can guess y. The attacker can continue in this manner until he guesses all bytes of the cookie. In reality, there are a lot less than 256 possibilities for each byte of the cookie header, and so the attack requires less work. There are also several details required for the attack to work that are omitted here.

Why the problem can’t be fixed quickly

TLS 1.1, which fixes this issue, was defined in April 2006. As you may have guessed, this problem was known before April 2006. However, it was considered mostly a theoretical issue until Thai Duong and Juliano Rizzo showed how it can be used to decrypt cookies sent over HTTPS. Even though this issue has been known for a while, it is probably not going to be fixed anytime soon because most websites do not support TLS 1.1 or TLS 1.2. According to Opera, only about 0.25 percent of web servers support TLS 1.1, and only 0.02 percent of web servers support TLS 1.2. There are workarounds that some browser vendors are currently implementing and testing; however, this problem is not going to be completely fixed until most web servers start supporting TLS 1.1 or TLS 1.2.

Risks

Should you be worried? Probably not. This does not significantly increase the risk of connecting to untrusted networks. There are easier attacks that can be used to steal your cookies (or your username and password) for many websites, or even install arbitrary software on your computer if you connect to untrusted networks. Some examples are:

• Many websites do not set the ‘secure’ flag on their session cookies, which means that a tool like sslstrip can be used by an attacker on your network to get your cookie.
• Many websites provide login forms over HTTP (even though your password may actually submitted over HTTPS), and attackers on your network can modify the login pages to get your username and password.
• Many users ignore certificate warnings provided by browsers, or may not even notice that a tool like sslstrip is being used and that they are not actually accessing a site over HTTPS before entering their credentials.
• Tools such as Evilgrade can be used to install arbitrary software on your computer by leveraging software that has insecure automatic update mechanisms.

Protecting yourself

If you want to protect yourself against BEAST-like attacks, you can take several steps:

• Delete all your cookies before you connect to an untrusted network.
• Limit the amount of time you spend authenticated to HTTPS sites on untrusted networks, and remember to log out as soon as you are done.
• Until your browser vendor releases a fix, disable all cipher suites that use block ciphers in your browser (leave only cipher suites with RC4 enabled).

Note that the last workaround may cause you to be unable to access many websites. Of course, when browser vendors release security updates, install them immediately.