The Latest in IT Security

Recently, there’s been a lot of talk on how “SSL is broken”. This came on the heels of two researchers, Juliano Rizzo and Thai Duong, releasing what they called Browser Exploit Against SSL/TLS, or BEAST. If you believe some of the reports, secure connections as we know are worthless.

This issue may seem quite complex for most users, so right off the bat I’ll try to describe this attack in “human terms”. Most encryption relies on two things:

1. The attacker doesn’t know the key used to encrypt the message.
2. The attacker doesn’t know the message being sent.

However, if the attacker can trick your browser into sending some known plain-text over the target Secure Sockets Layer (SSL) connection and they can also capture a copy of that message in transit, then the possibility arises of decoding other plain-text within the same message. While having a copy of a known message encrypted is not as good as having that key, it does give the attacker a good foothold making the cryptanalysis of the message much easier.

Now that the attacker now has the capability, with some effort, to decode parts of the of messages sent by the user to the secure server. It should be noted that the this attack only works on one direction at a time. Using this method it is possible to decode portions of other plain-text in the same message as our injected text. The BEAST toolkit uses this capability to extract session cookies that can be used to hijack the user session.

Security experts have known for years that TLS/SSL is potentially vulnerable to this kind of attack. Simply put, the BEAST toolkit did not reveal anything we don’t already know. What it did was to package this attack into an easy to use form that vastly reduces the resources and skills required to execute it.

How BEAST Works

There has been a lot of talk about this being a man-in-the-middle attack, but it can just as easily be executed with browser and local network access. Depending on network configurations the sniffer could reside on the target host or an adjacent host. There is a great deal of infrastructure flexibility possible here.

The first step is to somehow inject code into the current browser session. This can be accomplished by using techniques, like an embedded iframe, or a cross-site scripting attack (XSS). This code must then cause the browser to include some known plain-text to the server over the SSL channel. Again, this can be done with simple Javascript. Before this code is injected, the attacker also needs to be able to capture the SSL user traffic – either by running a sniffer on the target machine, or capturing the traffic via a man-in-the-middle attack. Either way, with both the plaintext and the encrypted payload, the attacker can now run some cryptanalysis tools and hope to get a cookie.

What can users do?

1. Keep time spent on sensitive SSL sessions as short as possible. The attacker needs time to decode the encrypted message. If the session cookie is invalid before the attacker has finished, this attack fails.
2. When leaving an SSL protected site, be sure to actually log out, not just move to a new site. In many cases, actively logging out will invalidate any cookie/session data that the attacker may have successfully decoded.
3. Standard security best practices still work. For this attack to be successful, the attacker must have access to either your network or your computer. At the very least, up-to-date security software will make life harder for an attacker.

However, the burden of fixing this problem really falls on website administrators. What can they do?

1. Make sure your logout button performs the expected action. You are leaving users at risk if your site does not actually invalidate session cookies when they click “log out”.
2. Ensure that session cookies are tied to an IP address where the session was established. If that IP address changes, consider validating that the source of the requests is still your user. This will not prevent this attack, but it will make it harder to exploit your users.
3. Resist the temptation to change SSL ciphers without carefully considering the risks first. While it is true that RC4 is not subject to this attack, it presents more risk than AES. Also, it isn’t a bad idea to keep an eye on the IETF TLS working group.
   New versions of the TLS standard exist that eliminate the weaknesses used in this attack. Unfortunately HTTP server and browser coverage of these new standards is spotty at the moment at the moment. So you have to carefully consider both your environment and your user base before such a change.

Updated at 5:30 PM PST to clarify certain matters.