(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.1crlf
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.1crlfH
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:
- 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).
- 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 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.
The biggest problem with this is, it appears, that XHR cannot be used to create streaming requests, which are needed to perform the guessing. 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.
–
Bojan
INFIGO IS
Article source: http://isc.sans.edu/diary.html?storyid=11722&rss
View full post on National Cyber Security