Browser Exploit Against SSL/TLS (BEAST) is an attack that exploits a vulnerability in the Transport-Layer Security (TLS) 1.0 and older SSL protocols, using the cipher block chaining (CBC) mode encryption. It allows attackers to capture and decrypt HTTPS client-server sessions and obtain authentication tokens. It combines a man-in-the-middle attack (MitM), record splitting, and chosen boundary attack.
The theoretical vulnerability was described by Phillip Rogaway as early as 2002, and a proof of concept was demonstrated in 2011 by security researchers Thai Duong and Juliano Rizzo. The BEAST attack is similar to protocol downgrade attacks such as POODLE in that it also uses a MITM approach and exploits vulnerabilities in CBC.
While the probability of this attack is very low, and it can, at best, be used to read short strings of plaintext, it is one in the line of many attacks that exploit CBC vulnerabilities. Moreover, it could potentially be used along with a downgrade attack, such as in POODLE, to force a server to revert to TLS 1.0 or older.
BEAST Security Assessment
CVSS Vector: AV:N/AC:M/Au:N/C:P/I:N/A:N
What is the BEAST vulnerability?
A server using TLS 1.0 with block ciphers is vulnerable to BEAST. This is due to the inherent weakness in CBC that allows attackers to act as a man-in-the-middle and execute the remaining attacks.
For BEAST to be possible, several conditions need to be met:
- An attacker must be able to monitor or “sniff” the network connection and the sessions between the client and server
- A vulnerable version such as TLS 1.0 or an older SSL protocol must be in use (or a downgrade must be possible) with a block cipher
- An applet or JavaScript injection must be likely, overriding the same-origin policy of a website
Due to the specific conditions required to launch BEAST, it is improbable it to succeed. It is, therefore, not a particularly practical attack. Furthermore, web applications are now protected by default due to the same-origin policy in modern browsers. Unless the policy is somehow circumvented, such as via server-side CORS headers or another way, performing an injection will be impossible.
That said, it is not entirely inconceivable that this attack could be executed, especially on legacy systems found on organizational intranets. Besides that, it is also helpful to be aware of BEAST for the simple fact of understanding how attackers can use a multi-pronged approach and underscore the need for timely patching and measures.
Here’s how the BEAST attack works in detail.
How does the BEAST attack work?
BEAST relies on the predictable nature of how initialization vectors are generated as part of the encryption process in CBC mode. Due to the predictability in this process and the fixed size of ciphers (i.e., blocks), attackers can manipulate cipher block boundaries (the chosen boundary attack part of BEAST) and slowly reveal plaintext without actually having to decrypt it by obtaining the key.
A brief explanation of how block ciphers work is required to understand this process.
TLS, block ciphers, and initialization vectors
TLS uses cipher suites with symmetric encryption and block ciphers in the main. Symmetric encryption means that the same key is used to encrypt and decrypt information. To be more protected, though, an asymmetric encryption mechanism is initially used during the negotiation process between browser and server to arrive at the shared key. After the shared key is negotiated, encryption proceeds in a symmetric fashion which is faster.
Block ciphers are called this way because they encrypt data in blocks of a fixed length (8 bytes, to be exact). When encrypting information shorter than the entire block length, the remaining length is padded with a random data block. Common types of block ciphers include DES, AES, and 3DES.
To make the decryption of data more complex and secure, CBC uses what’s called an initialization vector (IV). Without an initialization vector, the same data would always yield the same ciphertext block after encryption, exposing it to a plaintext attack. To introduce randomness in the equation, the first block of encrypted data is combined with an IV (random data) which is then encrypted with the negotiated key and generates a ciphertext block.
After that, every subsequent block uses the previous block’s ciphertext as its IV. Then, it combines it with the message’s plaintext via what’s called XOR (a logical operation of chaining the blocks together, hence the name cipher block chaining). All of that is then encrypted with the negotiated key.
This block chaining is used instead of generating a random IV for every message, but it makes each subsequent IV predictable and known because it is the previous block’s ciphertext output. Moreover, XOR is a reversible operation, which introduces another vulnerability element. This predictability is the basis of BEAST.
Launching a BEAST attack
Assuming an attacker can “sniff” the exchange of messages between the client and the server. Considering also that the server uses TLS 1.0 or SSL and that the attacker is capable of tricking a user into running a JavaScript or applet via a malicious website.
This would result in the attacker injecting data blocks into the session. They would both have the IV of a message and XOR it with the plaintext block they wish to inject. They could then send these to the server and observe the server’s response – i.e., they would launch a man-in-the-middle attack and perform a so-called record-splitting attack. That’s how they can access information exchanged between web servers and browsers, such as passwords, credit card numbers, and more.
Initially, with the BEAST attack, the problem was that only guessing an entire block of ciphertext seemed possible. But unfortunately, guessing a whole block of data, even just an 8-bit block, is a challenging task that might require as many as 2568 attempts. This made BEAST a theoretical attack that seemed unfeasible, if not impossible.
But as Thai Duong and Juliano Rizzo discovered in 2011, a different approach was possible. The duo did that instead of trying to guess the whole block. They moved the cipher block boundaries, isolating only one byte. As a result, guessing one byte is significantly more manageable, as it limits the maximum attempts of guessing a single digit of a number, for example, to 10.byte, with borders being shifted after every successful guess. This is the chosen boundary part of the attack.
Are you likely to get hit by the BEAST vulnerability?
Given the many conditions needed to execute a BEAST attack, you will not likely get attacked in this way. Moreover, if attackers manage to position themselves in such a way as to meet all the requirements, they would have many more options to compromise your system and user data.
Since BEAST exploits vulnerabilities used in other attacks, it is still essential to take measures to avoid exposure. For example, a host of vulnerabilities will be present if your server supports TLS 1.0 or any version of SSL. See the section below for brief information on preventing the possibility of a BEAST attack.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to prevent the BEAST attack?
Initially, switching to the RC4 stream cipher was recommended to quickly prevent the vulnerabilities associated with CBC in TLS. But in 2013, the RC4 cipher was found to be unsafe in many ways. So two years later, its use in TLS implementations was prohibited.
Currently, the simplest and most efficient way of preventing a BEAST attack is to turn off and disable support for TLS 1.0 and 1.1., as well as SSL on your server. Doing this also protects you from other security flaws that exploit vulnerabilities in SSL and earlier versions of TLS, such as POODLE or DROWN.
To learn how to disable older versions of SSL and TLS, see our Secure TLS Configuration page.
