Is BEAST Still a Threat?

Yesterday I changed the SSL Labs rating criteria to stop penalizing sites that do not implement server-side mitigations for the BEAST attack. That means that we now consider this attack sufficiently mitigated client-side, but, there are still some things you should now.

What is BEAST?

TLS 1.0 and earlier protocols suffer from a serious flaw: the Initialization Vector (IV) blocks that are used to mask data (plaintext) prior to encryption with a block cipher can be predicted by an active man-in-the-middle (MITM) attacker. IVs are used to prevent encryption from being deterministic; without them, every time you encrypt the same block of data with the same key, you get the same (encrypted) output. This is highly undesirable. A clever attacker who can 1) predict IVs, 2) see what encrypted data looks like, and 3) influence what is encrypted, is then able to make guesses about what plaintext looks like. Technically, he cannot decrypt any data, but he can find out if his guesses are right or wrong. With enough guesses, any amount of data can be uncovered.

This is a highly condensed explanation of the problem. If you care about the details, I suggest that you start with my previous post on this topic, and follow the links provided there.

Because guessing is not very efficient, the BEAST attack can in practice used to retrieve only small data fragments. That might not sound very useful, but we do have many highly valuable fragments all over: HTTP session cookies, authentication credentials (many protocols, not just HTTP), URL-based session tokens, and so on. Therefore, BEAST is a serious problem.

Mitigation status

BEAST is purely a client-side vulnerability. Since it had been released to the public, most major browsers addressed it using a technique called 1/n-1 split. This technique stops the attacker from predicting IVs and effectively addresses the underlying problem.

But one platform held back—Apple’s. We know little about their intentions, because there hasn’t been any official communication on this topic. My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.

Without Apple addressing the BEAST attack, there’s a substantial chunk of users that are still potentially vulnerable. For this reason, at the beginning of this year, SSL Labs started penalizing all sites that do not incorporate server-side mitigations against the attack.

Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say “unfortunately”, because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out.

The situation became uncomfortable because we couldn’t solve both problems, but also because both issues were of roughly the same risk. (Low.) Still, the end result was clear: RC4 affects everyone and cannot be mitigated; BEAST affects only a part of the user base and there isn’t a workable exploitation path for it any more (we hoped). In addition, we knew that attacks against RC4 were going to get better; and that the attack surface vulnerable to BEAST likely to get smaller.

Is BEAST still a threat?

From this conclusion, the work that remained was to prove that the exploitation path used by BEAST was genuinely closed. We had no reliable information about that, and so I set out to test a bunch of browsers running on various platforms, read source code where available, and attempt to exploit BEAST myself.

The research required a lot of effort and time, mostly because I did not want just to run the existing exploit; I wanted to fully understand the attack as well as explore other potential attack vectors. Juliano and Thai (BEAST authors) have been very helpful answering my questions about their choices. I had detours, some because of real problems, some because of my mistakes. For a long time I thought BEAST was still exploitable because, to my great surprise, I discovered that the Same-Origin Policy (SOP) bypass that was used for BEAST still existed. Apparently, the fix for that problem was botched. Using this bypass, a MITM can still use a Java applet to instrument a victim’s browser to encrypt arbitrary plaintext and send it to arbitrary hosts.

Fortunately, there have been many changes to how applets work since BEAST was originally discovered. For example, there are now always warnings before an applet is started. In my testing, the Java plug-in had no ability to access HttpOnly cookies; it couldn’t even send them in a request, or receive any of them back. Most importantly, HTTPS request made by applets are encrypted using Java’s TLS stack, not that of the host browser. Because Java does implement the 1/n-1 split, BEAST cannot be exploited.

Epilogue

Even though SSL Labs no longer penalizes sites that do not implement server-side BEAST mitigation, the problem remains for as long as we have a major browser without the fix. Although I don’t believe that the problem is exploitable today, there might be other attack vectors we are not aware of. A new feature added to Safari could make it exploitable again tomorrow. Or, someone with more time on their hands could prove me wrong. For this reason, we need a healthy security margin, and we need Safari to implement the 1/n-1 split by default.

By the way, supporting TLS 1.1 and 1.2 does not actually address BEAST now or in the near future, even though these protocols do not have the predictable IV weakness that’s exploited by the attack. The first problem is that most of the Internet still relies on TLS 1.0. Only about 18% of the servers tracked in SSL Pulse support TLS 1.2 today. Thus, even though the next generation of web browsers will all support TLS 1.2, it’s going to take a while until the servers are upgraded.

But there is also the second issue, which is that all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.