3. BEAST
•Browser Exploit Against SSL/TLS.
•BEAST is a client side attack. It does not affect servers.
•The BEAST mounts a chosen plain text attack on the data
transmitted from a client to a SSL enabled web server.
•The attack only works on Block ciphers such as AES,
DES . Stream ciphers are unaffected by the attack
4. SSL BEAST PREREQUISTES
• The SSL enabled web server must be running version
of SSL 3.0 or lower or TLS 1.0.
• It must support Block ciphers CBC.
• The attacker must be able to mix his content with the
SSL content.
• The attacker must implement a Man-in-themiddle(MITM) so that he can observe the SSL traffic.
7. BEAST in action
Consider the block x:
• Cx-1 ⊕Tx
Cx-1 is the cipher text of the previous block x-1 and the IV
of the current block.
Tx is the plain text password of the user.
Cx = E(Cx-1 ⊕Tx)
Cx is the resulting cipher text after encryption
This will be the IV of the next block, say IV2.
8. The attacker injects the following in the SSL traffic in
block (x+1)
• IV2⊕ Cx-1 ⊕ P
IV2 is the IV of the current block and the cipher of
the previous block Cx
Cx-1 is the IV of the previous block
P is the attacker’s guess of the plaintext password of
the victim.
9. • The XOR function looks like this
(IV2⊕ Cx-1 ⊕ P)⊕IV2
• The two IV2s are XORed and cancel each other
giving
Cx-1⊕P
Cx+1 = E(Cx-1⊕P)
If,
Cx= Cx+1, then
P=Tx the attacker has successfully guessed the
password.
10. BEATING THE BEAST
• The most preferred way is to use TLS 1.1 or TLS 1.2.
• If using a lower version of TLS or if the server is
using SSL then use a stream cipher such as RC4.
11. CRIME
• Compression Ratio Info-leak Made Easy
• CRIME exploits the data compression feature of SSL
and TLS.
• CRIME attack works only when both the browser
and server support TLS compression.
12. PREREQUISITES FOR ATTACK
• The server must support SSL/TLS compression
• The attacker must be able to mix his content with the
SSL/TLS traffic
• The attacker must be able to do a Man-in-themiddle(MITM) attack on the victim
13. CRIME INTERNALS
• SSL/TLS compression use an algorithm called
DEFLATE
• DEFLATE compresses the HTTP requests by
eliminating duplicate strings
• Every instance of a duplicate string is replaced by a
pointer to the first occurrence of the string
• More redundant data will lead to more compression and
thus smaller will be the length of the HTTP request
14. CRIME in action
• Cookie: secret=341267
• The attacker knows that the session token contains
Cookie: secret=
• The attacker will keep changing the string after
secret= and try to brute force the value
15. POST / HTTP/1.1
Host: importantserver.com
Cookie: secret=341267
...
Cookie: secret=1
• DEFLATE recognizes that there is more than one
occurrence of Cookie: secret= part and replaces the
second instance with a small token that points to the
location of the Cookie: secret= of the first string
21. Brute forcing the session token:Byte1,
Iteration 3
POST / HTTP/1.1
Host: importantserver.com
...
Cookie: secret=341267
...
Cookie: secret=3
22. The length of the request decreases by 1
more byte. Thus we have successfully
guessed the first byte of the session token.
The attacker can repeat the process to
guess the second byte of the request
keeping the first byte constant.
24. BREACH
• Browser Reconnaissance and Exfiltration via
Adaptive Compression of Hypertext
• BREACH happens to be more powerful than CRIME
as it is not really possible to turn off HTTP
compression.
25. PREREQUISTES FOR ATTACK
The prerequisites of the BREACH attack are as follows:
• The application must support HTTP compression
• User input should be reflected in the response
• The attacker must be able to do a Man-in-themiddle(MITM) attack on the victim
• The HTTP response should have some secret
information like CSRF token
26. RESPONSE NOT REQUEST
• The attack works by injecting data into the HTTP
request and analyzing the length of the HTTP
responses
• Any variation in length of the response indicates a
successful guess
27. BREACH IN ACTION
REQUEST:
GET /stuff/form.php?id=token=attacker's_guess
RESPONSE:
<a href=“form2.php?token=csvfd123”>Go to form
2></a>
……………………
<form
target=https://example.com:443/stuff/everything.php?
id=token=attacker’s_guess”>
29. BREACH IN ACTION
REQUEST:
GET /stuff/form.php?id=token=a
RESPONSE:
<a href=“form2.php?token=csvfd123”>Go to form
2></a>
……………………
<form
target=https://example.com:443/stuff/everything.php?id=
token=a”>
31. BREACH IN ACTION
REQUEST:
GET /stuff/form.php?id=token=b
RESPONSE:
<a href=“form2.php?token=csvfd123”>Go to form 2></a>
……………………
<form
target=https://example.com:443/stuff/everything.php?id=
token=b”>
33. BREACH IN ACTION
REQUEST:
GET /stuff/form.php?id=token=c
RESPONSE:
<a href=“form2.php?token=csvfd123”>Go to form 2></a>
……………………
<form
target=https://example.com:443/stuff/everything.php?id=
token=c”>
34. The length changes by 1 extra
byte. We have successfully
guessed the first byte of the token
35. MITIGATIONS
• Disabling HTTP compression
• Separating secrets from user input
• Randomizing secrets per request
• Masking secrets (effectively randomizing by XORing
with a random secret per request)
• Length hiding (by adding random amount of bytes to
the responses)
• Rate-limiting the requests