(This is a bit longer diary – if you are just interested in conclusion and recommendations, skip below to the “Is SSL broken?” section. I recommend that you read the whole diary – and let us know if you have any comments).

Unless you’ve been hiding on a deserted island, you heard about the latest attack on SSL, named BEAST. We wrote several diaries (first, second, third) on this topic. I got interested into the attack a lot and finally had some time to go through all the details.

So, first of all – big props to Duong and Rizzo for implementing this in practice. While the idea itself is really cool (a bit more about it below), the implementation is what really impressed me, and all the effort they invested into the research here.

Some basics about the attack

As has been already written on million places, the BEAST attack attacks SSL 3.0 and TLS 1.0, in particular their implementation  of the Cipher-block chaining (CBC) block encryption algorithms.

This is probably the most widely used mode for block encryption algorithms today, so it is obvious that any attack on this (and SSL/TLS overall) can have huge impact.

In a nutshell, BEAST very cleverly uses predictable IV (initialization vector) values in order to set up particular input vales for SSL. By very carefully modifying these input values, the attacker can exploit BEAST to guess what value 1 byte in an encrypted block had. Block encryption algorithms fragment input messages into blocks, usually 8 or 16 bytes long.

The IV is initially a random number and then every next block uses the previous cipher text as the IV. The IV is XORed with the input plain text – this produces input for the encryption algorithm. So normally, in a block encryption algorithm, encrypted block C4 = encryption ( C3 XOR P4), where C is an encrypted block and P is a plain text block.

According to this, the last blocks (CN) IV will be CN-1: CN = encryption (CN-1 XOR PN). Doung and Rizzo cleverly used this so they leave the channel open and add the next block (N+1) whose content will be of one of the previous blocks. Imagine that we supply P4 (with only 1 byte modified), XORed with CN and it’s original C3:

CN+1 = encryption ( CN XOR ( CN XOR C3 XOR P4 ))

This results in:

CN+1 = encryption ( C3 XOR P4)

For which we know the result as it is C4! Now, if we can influence P4 to give us the opportunity of guessing one byte (by supplying, for example, 7 known bytes) we can try to guess what the last byte was: if CN+1 is equal C4, we guessed the byte, otherwise we didn’t.

This is just a brief overview – for more information read the leaked paper – it is written very well.

Guessing HTTP values

As you’ve seen above, the attacker can now guess byte by byte. With HTTP creating this boundary is actually simple since we know what each HTTP request will look like:

GET /AAAAA HTTP/1.1<cr><lf>
header

If we want to guess the first character of Header, we can make the previous line 23 bytes long (if blocks are 8 bytes each):

GET /AAAAAAA HTTP/1.1<cr><lf>H

Notice how only H will make it into the 3rd block. The attacker now knows the content of the first two blocks and can try to guess the first character by using the attack described above.

Attack prerequisites and implementation

As if the attack itself was not impressive enough, Doung and Rizzo managed to actually do all this in the browser. Let us revisit what they have to do for this attack:

1. They need to pull a MITM attack on the victim. This is needed for two things: first, they need to monitor the network traffic in order to guess bytes. Second, they need to somehow influence the browser to make it issue requests such as the one shown above that will let them do the guessing. For the demo they used a Java applet, but there are other ways of exploiting this (more below).
    
2. Once they injected the Java applet into the victim’s browser, they wait for the victim to log in to the target site. Now the Java applet will open an SSL connection to the target site and send a specially crafted request as above (i.e. GET /AAAAAAA …). The SSL connection must stay opened so they can feed new blocks in real time, as they monitor network traffic. This will allow them to guess content of bytes encrypted by the browser. So, their Oracle in this case is the browser itself – the web server that they are attacking is irrelevant, it is the victim’s browser that let’s them guess encrypted content.

As you can see from 2), the crucial requirement is that the SSL connection is open (so they are able to append the data and use the last block as the IV). This proved to be very difficult to do (and is one of the things in Doung’s and Rizzo’s research that impressed me the most).

There are many ways that can be used in a browser to open a new connection. The easiest way is to use JavaScript’s XmlHttpRequest (XHR). There are some limitations here though. First, Internet Explorer does not support XmlHttpRequest level 2 (which is needed in order to send cookies) and instead has an XDomainRequest object. XDomainRequest will never send cookies so, in theory, Internet Explorer users are more protected than Mozilla Firefox or Chrome users (is this a first or what!?!).

Firefox and Chrome support XHR level 2. It is worth pointing out here that the attacker is not able to read the request response through active scripting due to the fact that the server will not set the correct Access-Control-Allow-Origin header, but the attacker does not care about that since he just wants to be able to use the browser as an Oracle for guessing encrypted stuff. Similarly, settings such as Secure or HttpOnly will not help with this attack (but will with other).

The biggest problem with this is, it appears, that XHR cannot be used to create streaming requests, which are needed to perform the guessing (the attacker needs to be able to append those pre-calculated blocks to a request). Many other possible exploitation vectors, such as plain IFRAMEs, Websockets or Silverlight have similar issues that prevented Doung and Rizzo from using them – keep in mind that this does not mean these are “safe” against BEAST, just that current attempts to use them failed.

Is SSL broken?

Simple question, simple answer – NO. As you can see above, there are many prerequisites that the attacker needs to do in order to conduct the BEAST attack.

While the attack is inherent to block encryption algorithms, it requires the attacker to be able to append these specially crafted input blocks into an active session. In other words, it is very difficult, or impossible to exploit BEAST on other protocols that use SSL, such as POP3s, IMAPs and similar. Doung and Rizzo did it with browsers because there are many scripting (extending) possibilities with browsers and the HTTP protocol.

Couple of things I would suggest doing:
-    Be careful about switching to TLS 1.1 or TLS 1.2 because you might break things for many clients. While this definitely fixes the vulnerability, be very careful.

-    Move to RC4 over CBC. RC4 has also its own issues but just the fact that Google prefers RC4 says something too – you can use the nice sslscan utility to see what ciphers are supported by a server, here are the results for mail.google.com:
# sslscan --no-failed mail.google.com:443
                   _
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | '_ \
          \__ \__ \ \__ \ (_| (_| | | | |
          |___/___/_|___/\___\__,_|_| |_|

                  Version 1.8.2
             http://www.titania.co.uk
        Copyright Ian Ventura-Whiting 2009

Testing SSL server mail.google.com on port 443

  Supported Server Cipher(s):
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):
    SSLv3  128 bits  RC4-SHA
    TLSv1  128 bits  RC4-SHA

-    Do not accept any unsigned Java applets and allow them to run. You should always do this, not only in this case. Same goes for any other active technology.

-    When accessing sensitive sites, close all browser windows (not tabs, all windows) and open a fresh new one and use it only to access the sensitive site. After you’re done, close it again and reopen it for further surfing. This should make exploitation a bit difficult, but keep in mind that as of Java 6 Update 10 an attacker can potentially trick a victim into dragging applets out of browser windows so they continue running after the browser is closed (I’m not sure if this can be used to help BEAST).

-    If you are a sensitive server owner – keep an eye on errors on your server. The BEAST attack needs to issue quite a bit of requests (generally each byte has a 1/256 chance of being guessed, so in average 128 blocks need to be appended to a single request). One request is needed for a byte so if you see a lot of 404 requests with similar patterns (/AAAAA) that should raise some flags. Of course, you should always monitor and correlate your logs, not only now :)

At the end, I must again admit I like the attack a lot - the idea is really cool, amazing how they came up with everything. That being said, as you can see above, there are a lot of prerequisites for successful exploitation so I don't think that the resulting risk is very high at the moment.

(small update): There have been some comments about recommending RC4. While there have been plenty of bad/broken/failed implementations of RC4 (take a look at WEP), I definitely do not consider RC4 to be broken, especially not the OpenSSL implementation that is widely used.

Besides me ;-), US CERT is also recommending that RC4 is prioritized in their advisory available at http://www.kb.cert.org/vuls/id/864643.

--
Bojan
INFIGO IS
@bojanz on Twitter