The BEAST cryptographic attack, once thought to be largely mitigated, has two things conspiring against it to make breaches potentially possible again.
Not only has a server-side mitigation essentially been rendered moot by recent research into the RC4 cryptographic protocol, but Apple has yet to enable by default a client-side mitigation into its Safari browser that would keep BEAST at bay, according to research done by Qualys director of application research Ivan Ristic.
BEAST is an attack tool that targets a vulnerability in TLS 1.0 and SSL 3.0 and was reported in September 2011 by researchers Juliano Rizzo and Thai Duong. They built the BEAST tool, which is capable of grabbing and decrypting HTTPS cookies and hijacking browsing sessions in order to steal credentials and more. Major browser makers, except for Apple, addressed the issue on the client side by implementing a technique known as 1/1-n split. The technique stops attackers from being able to predict the initialization vector blocks that are used to mask plaintext data before it is encrypted.
An attacker with a man-in-the-middle presence in a browser session can predict the initialization vector blocks, see what the encrypted data output looks like and influence what is encrypted, Ristic said. No data can be decrypted, Ristic said, but an educated attacker with enough guesses is likely to land on the correct one.
“Because guessing is not very efficient, the BEAST attack can in practice used to retrieve only small data fragments,” Ristic wrote. “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.”
Ristic told Threatpost that browser vendors were quick to deploy the 1/1-n split except for Apple, which encoded the mitigation into its Mountain Lion release more than a year ago, but disabled it by default.
“There is no statement [from Apple] on its intentions or published information on how to enable mitigation if people wanted to,” Ristic said, adding that only experience security-aware people would likely think about enabling this type of defense.
On the server side, the best way to mitigate BEAST had been to enforce RC4 encryption whenever TLS 1.0 is used. However, experts Dan Bernstein, Kenny Paterson, Nadhem AlFardan, Bertram Poettering and Jacob Schuldt published an attack that exploits a weakness in RC4 that could allow an attacker to decrypt the key stream—an issue that’s been known about in the community for 15 years.
“Now that RC4 is weak, we have to begin to take measures to disable it. So therefore, we can no longer mitigate BEAST on the server side,” Ristic said. “As long as Safari remains theoretically vulnerable, we are afraid that any change in browser capabilities may lead to a condition that would enable an exploit to the BEAST attack.”
BEAST attacks are ideal in targeted attacks against specific individuals and attackers would need to carry out a man-in-the-middle attack to exploit the issue; BEAST cannot be done on any kind of scale, Ristic said. Also, the source code for BEAST was never released by Rizzo and Duong.
Ristic also cautions that deploying TLS 1.1 or TLS 1.2 would not address BEAST, regardless of the fact they don’t know carry the same initialization vector weakness as TLS 1.0. Most of the Internet remains on TLS 1.0 and while future browsers will support TLS 1.2, Ristic said they will still be vulnerable 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,” Ristic said. “At that point, the predictable [initialization vector] 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.”
