What is BEAST?

Browser Exploit Against SSL/TLS

BEAST is an attack against SSL/TLS which is the cryptographic system that protects data sent online. A practical attack was found to be possible against TLS v1.0 and SSLv3.0 (and below). The issue is that the Initialisation Vector (IV) utilised as part of the encryption process can be determined by an attacker. IVs are utilised to prevent encrypted data from being deterministic, they essentially make it harder for attackers to determine patterns in encrypted data. Without them if a repeating pattern is evident in the plaintext then it will be evident in the ciphertext and this type of informations is greatly useful to an attacker. IVs are designed to prevent this, however with the BEAST attack they are shown to be deterministic which greatly reduces their use as a protection mechanism.

It reduces the protection but the deterministic nature is of limited use to an attacker and they are only able to retrieve small amounts of information from the encrypted data, however with attacks against web applications small amounts of data can cause a large impact – if an attacker is able to retrieve information such as session tokens.

For a BEAST attack to be successful, there are difficult conditions that must be met:

  • A vulnerable version of SSL/TLS must be in use, with a block cipher
  • an attacker must be actively monitoring the SSL connection, using a man-in-the-middle attack
  • It must be possible to inject JavaScript or an Applet into the same origin of the target web application

The original BEAST attack utilised a flaw in Java’s Same Origin Policy (SOP) however this is not the only way that an attack of this nature could be achieved, Cross-site Scripting is an alternative (XSS). A weakness within a file upload system could also potentially be exploited. Generally speaking however if an application is vulnerable to cross-site scripting or has a vulnerable file upload system then an attacker is likely to utilise that vulnerability alone to have the desired impact.

For example, an attacker may be able to read session tokens directly by leveraging XSS – however if an attacker is well placed, all of the above conditions are met and session tokens are protected against XSS through a mechanisms such as HttpOnly cookies then an attacker may exploit BEAST to gain access to the protected tokens.

For this attack to work the client must be vulnerable, modern browsers are protected against this attack. Servers may wish to protect their users directly instead of relying on the web browsers protection by enforcing the use of RC4 ciphers instead, however issues have been identified within these ciphers also. Servers could instead enforce a version of TLS above 1.0, however this has compatibility issues. Therefore developers are left with options:

  • Ignore the issue and rely on the protections offered by modern browsers
  • enforce RC4 ciphers and the issues they bring but effectively mitigate BEAST
  • enforce TLS v1.1 and above and the compatibility issues that this brings

Developers should also bear in mind that the BEAST attack only affects a small portion of the userbase and requires another vulnerability such as XSS – whereas vulnerabilities with RC4 ciphers affect all users.