SSL/TLS attacks: Part 3 – BREACH Attack

SSL Breach AttackBrowser Reconnaissance and Ex-filtration via Adaptive Compression of Hypertext (BREACH) Attack:

Previously we learnt how CRIME attacks SSL/TLS using SSL/TLS compression. Now we look at a more recent attack called the BREACH attack.

BREACH attack is quite similar to CRIME attack with subtle differences. This attack also leverages compression to extract data from a SSL/TLS channel. However, its focus is not on SSL/TLS compression; rather it exploits HTTP compression. Here, the attack tries to exploit the compressed and encrypted HTTP responses instead of requests as it was the case with CRIME attack.
Note: HTTP response compression applies only to the body of the response and not the header.

BREACH attack is more powerful than CRIME since HTTP compression can’t be readily turned off. It targets HTTP responses by targeting the size of the HTTP response and extracting data from the HTTP response.

Prerequisites of the BREACH attack:
  • The application must support HTTP compression.
  • User input should be reflected in the response.
  • The attacker must be able to do a Man-in-the-middle (MITM) attack on the victim.
  • The HTTP response should have some secret information like CSRF token.

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.

How BREACH attack works?

Consider the following request to an SSL enabled web server

GET /stuff/form.php?id=786345

This generates the following response

<a href=”form2.php?token=csvfdfcrvet343v”>Go to form2</a><form target=”https://example.com:443/stuff/everything.php?id=786345“>…………..

Here we see the string id=786345 is reflected back in the response body. The attacker leverages this very functionality to guess the ‘token’ value character by character.

The attacker injects the token value in the id parameter. If the value of the attacker injected token matches that of the actual token then the length of the response decreases by the length of the duplicate strings due to HTTP compression. In this case the value will be 21 viz. the length of the string token=csvfdfcrvet343v.Initially the attacker only knows that the ‘token=’ part of the string. This the attacker can know by simply logging into the application himself.

Step 1: The attacker initiates the attack by sending the following value as the value of the token
token=a

The request will look like this

GET /stuff/form.php?id=token= a

The response will be as follows

<a href=”form2.php?token=csvfdfcrvet343v”>Go to form2</a><form target=”https://example.com:443/stuff/everything.php?id=token=a “>…………..

The length of the response will decrease by the 6 viz. the value of the length of the following string ‘token=’.

Step 2: The attacker looks at the response length and concludes that the value of the token is incorrect.

The attacker repeats the process with different value of ‘token’.

Step 3:  When the attacker tries ‘token=c’, the request looks like this:

GET /stuff/form.php?id=token= c

The following will be the response

<a href=”form2.php?token=csvfdfcrvet343v”>Go to form2</a><form target=”https://example.com:443/stuff/everything.php?id=token=c “>…………..

Since the first character of the attacker’s guess matches the actual value of the token the response length decreases by 7.

Step 4: The attacker concludes that he has successfully guessed the first character of the token. The attacker then keeps the first character constant and varies the second character and repeats the entire process again.

Step 5: The attacker does this until he has successfully guessed the entire value of the ‘token’.

Impact of BREACH attack

The BREACH attack can be practically executed under a minute depending on number of per thousand requests required as per the secret size. The power of the attack comes from the fact that it allows guessing a secret one character at a time.

Mitigations for BREACH attack:

The following mitigations must be applied for BREACH attack:

  • Disabling HTTP compression
  • Separating secrets from user input
  • Randomizing secrets per request
  • Masking secrets (effectively randomizing by XOR’g with a random secret per request)
  • Length hiding (by adding random amount of bytes to the responses)
  • Rate-limiting the request
 Conclusion

BEAST, CRIME and BREACH are a part of the increasing number of attacks on the SSL/TLS protocol. It is important that we should remain aware of them and apply the recommended mitigation measures to secure our data flowing through SSL.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

1 Trackback / Pingback

  1. SSL/TLS attacks: Part 2 – CRIME Attack - Checkmate

Comments are closed.