Release the BEAST!Understanding the BEAST
By Daniel Yepes | April 27, 2018
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
Thai Duong and
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
i will try to avoid most if not all
Shall we begin!?
SSL/TLS Implementation flaw
The core of the attack starts here,
with the Secure Socket Layer
and Transport Layer Security
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
TLS 1.0, the way how
Initialization Vectors (IV)
Back in 2004, an
TLS 1.0 could be exploited
by a variation of the
Chosen Plaintext Attack
CBC, if the
IV is known
or can be predicted by the
attacker, attempting to
inject plaintext to
be encrypted with the
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 succesfull!,
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 explaination, 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, .
CBC mode. Each block
of plaintext, is
a bit operation) with the
before being encrypted.
This way each ciphertext block
depends on all plaintext blocks
processed up to that point,
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, . 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.
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.
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
Remeber, encryption is done on the message splitted in 8 bytes blocks, just to make it simple we will take the first two blocks:
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 mathches.
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
let’s see that with this simple example:
As you may see, it’s quite hard
to guess the block that came
before it, specially when
IV it’s random. You
migth think this made
it secure, isn’t?
But hey, if things were easy like that, i wouldn’t be writting this article. Remeber i mentioned a theorized vulnerabilty that came up in 2004? There is a variation called Blockwise-Adaptive Chosen-Plaintext Attack (BACPA), .
The attack derives from the way
transmit data: Any plaintext sent
is fragmented into blocks of length
less than or equal to 214 bytes,
Which is then processed and sent as follow:
Message type (8 bits);
Major/minor version number (16 bits);
Length counter(16 bits);
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 transmision each
packet will be encrypted, were
the first package will be the only
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
Chosen-Plaintext Attack by injecting
his own packets into the
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
IV, Then the message is
splitted into 8-bytes chunks,
each block after the first will
CBC residue and lastly
will be encrypted:
The only thing D can see from there is:
But performing the packet injection
rigth there would throw an output
not worth considering, because
XOR the injected plaintext
with the previous residue
- The next CBC is just a supossition, for
the sake of not extending the example -
as seen here:
The attacker to be able to inject
succesfully it’s own packet must
XOR the guessed plaintext with
CBC Residue as seen here:
XOR that output with
That remaining output
is then substracted with
XOR properties, the
commutativity propertie to be exact,
A xor B = B xor A
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:
Where is the Browser attack?
Perhaps you migth be thinking
how this can be exploited?
Well, the B in
stands for Browser if you
remember, is not there
because it’s fancy.
An attacker is entitled
to perform a
on a user using an
which allows the attacker to get the
ciphered message, splitted as seen previously.
Duong wrote a Java
Applet Agent, which purpose was
HTTPS request and
trick the user into visiting their
Java Applet. Once the user were
Applet web site they
took advantage of the
Same-Origin Policy (SOP)
vulnerabilty, although it worked
only for the time the user was
SOP is meant to
cross-site issues, like
evil site trying to access
session and cookies from
your bank account stored
within the same browser using
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
SOP, plus as stated by the
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
vulnerabilties, the exploitation
is thanks to how
communication, where each packet
sent requires an specific format.
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.
Although this attack seems dangerous, it only works when the following requeriments are met:
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.
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.