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:
- The attacker doesn’t know the key used to encrypt the message.
- 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.
What can users do?
- 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.
- 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.
- 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?
- 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”.
- 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.
- 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.