Translation Is beast still a threat?

Original link: https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat

Published date: 2013.9.10

This blog post is only the translation of the original text, for research purposes only, I do not make any warranty of accuracy, invasion of the deletion, if reproduced, it is necessary to bear all the responsibility. If the translation is inaccurate, please feel free to advise.

Yesterday, I changed the SSL labs scoring rules (Translator note: SSL Labs is a Web site that detects SSL site security online) and stops detecting whether the site is enabled for Beast mitigation on the server side. This means that we now think this can be mitigated from the client, but there are some things you need to know.

What is Beast?

There is a serious vulnerability in TLS 1.0 and earlier protocols: the initialization vector (IV) used to confuse plaintext before encryption in a block cipher can be predicted by a man-in-the-middle attack (MITM). IV is used to avoid encryption in a rut, without them, you will get the same encryption results each time you use the same key to encrypt the same grouping. This is not very good. A clever attacker can guess what the original text is in the following three steps: 1) Guess iv;2) See what the encryption results are, 3) change the encrypted text (the Translator note: "Select plaintext Attack"). From a technical point of view, the attacker did not decrypt any data, but could verify that his guesses were correct, but if there were not enough guesses, no plaintext information could be found.

This is just a super-condensed version of the problem, and if you are interested in the details, it is recommended that you refer to an article I wrote earlier and reference the link recommended in that article.

Because guesswork is not very effective, in practice beast attacks can only get a small piece of data. It doesn't sound like an egg, but many of the high-value messages we use are small data segments, such as HTTP session cookies, authentication voucher sets (which are used in many protocols, not just HTTP), URL-based session tokens, and so on. Therefore, beast is a very serious problem.

Current status of mitigation measures

Beast is purely client-side vulnerability. Because this attack has been made public, many mainstream browser vendors have solved the problem through a technology called 1/n-1 split. This technique effectively solves the problem by preventing the attacker from guessing the IV.

But there was a platform that dragged its hind legs--the Apple family. We know nothing about what they think, because they don't have an official explanation of the issue. My understanding is that mountain lion's release will contain 1/n-1 split, but it is disabled by default. In addition, as far as I know, the prevention technology is not used in iOS.

Because Apple did not solve the Beast attack, the user is still potentially facing a threat. For this reason, at the beginning of this year, SSL Labs began to detect whether the site used server-side mitigations to combat this attack.

Unfortunately, the only effective way to combat Beast TLS1.0 and earlier protocols (most of which currently use protocols) is to use the RC4 algorithm. The reason for "misfortune" is that we just started a service-side mitigation test shortly after, a study on RC4 found that the algorithm was weaker than we thought before. While this vulnerability does not immediately pose a hazard, it is clear that the RC4 algorithm is heading for no return.

Things are getting a little bad because we can't solve two problems at the same time. But since the two issues are broadly thought to be equally low-risk, the final strategy is also obvious: RC4 affects everyone and cannot be mitigated; beast affects only a few people and no longer has the means to use it (hopefully). In addition, we know that attacks against RC4 are becoming more effective, and attacks against Besat seem to be getting less.

Is beast still a threat?

From the present situation, the only job left is to prove that the path to the use of beast has been cut off. But we don't have any credible information about this, so I'm going to test some browsers running on the vulnerability platform, read its source code if possible, and try to use beast.

This study takes a lot of effort and time, mainly because I don't want to just run the existing utility, I want to fully understand the attack and explore other possible ways to attack it. Juliano and Thai (beast author) gave me a lot of useful answers to my question. I have gone some detours, partly because of the reality of the problem, partly because of my mistakes. I think beast is still available for a long time because I am surprised to find that the same-origin strategy bypass used in Beast still exists. Obviously, the fix for that question (the translator's note: The fix for the same-Origin policy bypass) is screwed up. With this vulnerability, MITM can still use Java applets to control the victim's browser to encrypt arbitrary plaintext and send it to any host.

Fortunately, since Beast was released, the operating mechanism of the applet has changed a lot. For example, there is always a warning before running the applet. In my test, the Java plugin was unable to get HttpOnly's cookie and could not send or receive it in any request. More importantly, the HTTPS request issued by the applet uses the Java TLS protocol stack instead of the host browser. Because Java implemented the 1/n-1 split, Beast couldn't make it.

Conclusion

While SSL labs punishes sites that do not implement server-side beast mitigations (low scores), the problem persists because there are still a large number of browsers that have not yet been repaired. Although I don't think the problem has been exploited now, there may be some attack patterns that we don't know about. One of the new features that Safari adds can make the vulnerability available again, or someone who has time to test may prove me wrong. For this reason we need a good security guarantee and we need safari default implementation 1/n-1 split.

In addition, supporting TLS1.1 and 1.2 in the present and not far future will not really solve the beast, even if these protocols do not contain the IV predictive vulnerability exploited by such attacks. First question the current network is also primarily dependent on TLS1.0, and only about 18% of the servers in SSL pulse detection support TLS1.2. Therefore, even if the next-generation Web browser supports TLS1.2, it will still take some time for the service to complete the upgrade.

The second problem is that all major browsers are vulnerable to a protocol downgrade attack, and an active MITM can emulate a failed scenario, forcing the browser to fall back from TLS1.2 to SSL3.0, thereby exploiting the IV predictive vulnerability. Unless the protocol demotion vulnerability is fixed, the updated protocol is only valid for passive attackers and not for active attackers.

Translation Is beast still a threat?