| 7 min read
The Browser Exploit Attack on SSL/TLS (B.E.A.S.T), - bet you thougth it was a rampage hack that launched nukes - it is a practical attack demonstrated by Thai Duong
and Julian Rizzo
at ekoparty
in 2011.
That was the lamest introduction ever, it’s not because the attack doesn’t deserve it, it’s because it is quite a BEAST
to ride. As a warning to all mathemagicians
i will try to avoid most if not all math terms.
Shall we begin!?
SSL/TLS Implementation flaw
The core of the attack starts here, with the Secure Socket Layer (SSL)
and Transport Layer Security (TLS)
, it’s successor, both, essential protocols to transmit our data secured by implementing cryptography, in this case, symmetric cryptography using Cipher Block Chaining (CBC) mode, plus one single but significant change introduced on the CBC
mode on TLS 1.0
, the way how Initialization Vectors (IV)
were computed.
Back in 2004, an attack was theorized, SSL 3.0
and TLS 1.0
could be exploited by a variation of the Chosen Plaintext Attack
on CBC
, if the IV
is known or can be predicted by the attacker, attempting to inject plaintext to be encrypted with the IV
and if the output of the injected plaintext is identical as the output of one of the packets sent by the client, then the attack was successfull!, [1].
Breathe! I know it’s hard to assimilate, but let’s crumble it into small pieces:
Symmetric encryption with CBC mode
For the sake of simplicity, let’s take the Data Encryption Standard (DES) for this sample. Short explanation, symmetric encryption algorithm, where a plaintext comes in along with a key, the plaintext it’s chopped into a fixed-length, blocks of 8 bytes to be precise. Then each block along the key is encrypted to result in a ciphertext made of 8 bytes blocks, [2].
Now, the CBC mode
. Each block of plaintext, is XORed
(Bit a bit operation) with the previous ciphertext
block before being encrypted. This way each ciphertext block depends on all plaintext blocks processed up to that point, [3].
Almost there, we gotta need to know what is a block cipher. It is a deterministic algorithm operating on fixed-length groups of bits, called a block, [4]. The overall purpose of a block cipher is to ensure the transformation of each block, while on encryption or decryption, it means, giving it more randomness, which in this terms means more security.
CBC Mode - Wikipedia.
Last but not least, the initialization vector (IV)
In a few words, it is the first block cipher which, makes each message unique, the IV
is made entirely of random data.
What is so special about this? let’s join all of that.
Alice (Client) and Bob (Server) are going to chat, but D (Attacker) is an active stalker with feelings for Alice and he wants to learn about her habits.
It was a mistake…
Alice sends a message "I’m hungry, send me pizza" to Bob. The only thing D knows is that Alice most of the time starts the message with "I’m hungry". The message encrypted with DES
is:
Message encrypted with DES.
Remeber, encryption is done on the message splitted in 8 bytes blocks, just to make it simple we will take the first two blocks:
DES sample.
D somehow can see Alice’s encrypted connection, whilst D does not know Alice’s key, knows how the "I’m hung" looks like after encrypted, after all knows how the message starts. But does not know the rest, D only has to guess and trick Alice into encrypt several messages until it matches the second block.
Notice, that this guess and trick game does not compromise the key, this is pure Chosen-Plaintext Attack, you know barely some portion of the message and you just try to craft more combinations until it matches.
Here is where CBC
comes in action. Is specially designed to overcome this kind of situations, the addition of the block cipher before encrypting each block invalidates the Chosen-Plaintext Attack
, let’s see that with this simple example:
CBC sample.
As you may see, it’s quite hard to guess the block that came before it, specially when the IV
it’s random. You might think this made it secure, isn’t?
But hey, if things were easy like that, I wouldn't be writing this article. Remember I mentioned a theorized vulnerability that came up in 2004? There is a variation called Blockwise-Adaptive Chosen-Plaintext Attack (BACPA), [4].
The attack derives from the way SSL/TLS
transmit data: Any plaintext sent is fragmented into blocks of length less than or equal to 214 bytes, [5].
Which is then processed and sent as follow:
Unencrypted Portion:
-
Message type (8 bits);
-
Major/minor version number (16 bits);
-
Length counter(16 bits);
Encrypted Portion:
-
Plaintext fragment (< = 214 bytes);
-
Message authentication code (160 bits);
-
Padding (0-56 bits);
-
Padding length (8 bits);
But why do we care about how SSL/TLS
sends data? Well, if a message is splitted into several chunks, following the description above, a 100 bytes message is splitted into 10-10 bytes blocks of messages, which during transmission each packet will be encrypted, were the first package will be the only one who’s IV
it’s random, then the last 8 bytes of each former packet (or n-1 package) will be the CBC
residue of the first 8 bytes of packet n.
Practically, it means, the residue of the last package becomes the IV
of the current package, technique ofently referred as Chaining IV’s across messages
.
Thus, an attacker can perform the Blockwise-Adaptive Chosen-Plaintext Attack by injecting his own packets into the SSL
stream, he’ll know what CBC
will be used to encrypt the beginning of his message.
Perhaps this example will clarify all of this:
Alice and Bob will start their communication, we already know Alice will send "I’m hungry, send me pizza", here we can see how the process starts, with a random IV
, Then the message is splitted into 8-bytes chunks, each block after the first will use the CBC
residue and lastly will be encrypted:
DES encryption CBC mode.
The only thing D can see from there is:
Output.
But performing the packet injection right there would throw an output not worth considering, because TLS
will XOR
the injected plaintext with the previous residue CBC
, - The next CBC is just a supposition, for the sake of not extending the example -
as seen here:
Initial injection.
The attacker to be able to inject successfully it’s own packet must XOR
the guessed plaintext with that CBC
Residue as seen here:
Xoring with next block.
Then XOR
that output with the second CBC
residue. That remaining output is then subtracted with XOR
properties, the commutative property to be exact, A xor B = B xor A
CBC Residue XORing with injected packet.
And if the attacker is able to inject it’s packet on the stream Alice would end up encrypting it with her key, thus revealing the message, well, at least a fragment:
Injection succeed.
Where is the Browser attack?
Perhaps you might be thinking how this can be exploited? Well, the B in BEAST
, stands for Browser if you remember, is not there because it’s fancy.
An attacker is entitled to perform a Man-In-The-Middle-Attack
on a user using an HTTPS
connection, which allows the attacker to get the ciphered message, splitted as seen previously.
Rizzo
and Duong
wrote a Java Applet Agent, which purpose was to intercept HTTPS
request and trick the user into visiting their Java Applet
. Once the user were in the Applet web site
they took advantage of the Same-Origin Policy (SOP)
vulnerability, although it worked only for the time the user was logged in.
Basically, SOP
is meant to prevent cross-site
issues, like evil site trying to access session and cookies from your bank account stored within the same browser using JavaScript
. But back then several browsers were affected by this vulnerability.
To be fair, i will not expand on all the possible ways to exploit it besides than the mention of SOP
, plus as stated by the authors:
We wanted to focus on more important parts of BEAST such as the actual crypto attack and optimizations, so we stopped looking for alternatives, and used the SOP vulnerability to make an agent.
Besides than the browser vulnerabilities, the exploitation is thanks to how TLS
handles communication, where each packet sent requires an specific format.
For example,
HTTP Request format sample.
As we can observe there are values an attacker cannot easily guess, but there a lot of parameters which can be predicted, just by knowing the format of an HTTP request.
What if the last parameters is a password field within its value? Or what if the attacker can predict which block contains cookies?
When the attacker has predicted it, it can act in two ways:
-
Reassure that certain block has what predicted or not.
-
Determine the value of the block. Notice, that this values on the stream ranges from 256 characters in ASCII, plus 8 bytes per block, which means 2568 possibilities.
Of course fewer, if special characters are removed and other advanced mechanisms are used, which are out of the scope here.
Attack requirements
Although this attack seems dangerous, it only works when the following requirements are met:
-
JavaScript
enabled in browser. -
Encryption using
SSL 3.0
orTLS 1.0
. -
Able to packet capture communications.
-
Able to modify packets sent from you.
-
Browsing with multiple tabs/sessions.
-
Attacker must have an idea where you are going to browse.
-
Attacker must be able to perform their action(s) within the time you are logged in.
Conclusion
Again, although it was dangerous, when both researchers found it and spend several weeks on demonstrating the attack they informed browser vendors and TLS devs about such vulnerability, no harm was done. Sadly, they never released their code nor an official paper describing each phase of the attack.
At least it is unknown if somebody before them took advantage of it.
References
Recommended blog posts
You might be interested in the following related posts.
Introduction to cybersecurity in the aviation sector
Why measure cybersecurity risk with our CVSSF metric?
Our new testing architecture for software development
Protecting your PoS systems from cyber threats
Top seven successful cyberattacks against this industry
Challenges, threats, and best practices for retailers
Be more secure by increasing trust in your software