Hacking

SSL ATTACKS: Part 2

In the first part of SSL attacks, we have seen details about two attacks, namely BEAST (browser exploit against SSL/TLS attack) and SSL renegotiation attack. In this second part, we are going to deal with CRIME, TIME, and Lucky13 attacks. Let us proceed further and try to understand each of these attacks in detail.

Compression Ratio Info-leak Made Easy Attack

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

This is a side-channel attack on SSL/TLS that can be used to predict sensitive information, such as the session tokens, etc. This is done based on the compressed size of the requests. This attack is known to work against SSL compression and SPDY, which use deflate/gzip data compression techniques. SPDY is not widely used, but SSL compression is one technique which is very much in use.

Background Information

Before we see the details of the actual attack, let me explain a few things about "compression." Web pages are generally compressed before the responses are sent out (this is called HTTP compression), primarily to make efficient use of available bandwidth and to provide greater transmission speeds. With compressed data, we can send the same amount of data to the destination but using fewer bits. The browser usually tells the server (through "accept-encoding" header), what compression methods it supports and the server accordingly compresses the content and sends it across. If the browser does not support any compression, then the response is not compressed. The most commonly used compression algorithms are gzip and deflate.

Accept-Encoding: gzip, deflate

When the content arrives, it is uncompressed by the browser and processed. So, basically with SSL-enabled web sites, the content is first compressed, then encrypted and sent. But you can determine the length of this compressed content even when it's wrapped by SSL.

How Is the Attack Accomplished?

A CRIME attack is based on observing how the compressed length changes for different input values. Initially the attacker observes the size of cipher text sent by the browser and then makes multiple requests to the target website to observe the compressed response sizes. The attack primarily works by taking leverage of the "compressed size" of the text when there are repetitive terms. The attack can be best understood by following the below example, which demonstrates how an attacker can exploit it in real time.

Practical Example

Consider the below POST request made by a valid user.

Request:

POST / HTTP /1.1

Host: testing.com

User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1

Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1

Accept -Language: en -US ,en;

<-----body-------->

As mentioned earlier, this content is first compressed and then encrypted and sent. But note that the size of this encrypted piece can still be found out just by sniffing the network traffic. Now the attacker's target is to get the value of "secretcookie." The attacker now can make the victim click on a link and, using JavaScript, he can trigger the below request.

Request triggered by the attacker:

POST /secretcookie =0 HTTP /1.1

Host: testing.com

User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1

Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1

Accept -Language: en -US ,en;

<-----body-------->

In the above request, "secretcookie =0" is the attacker-controlled input. When repetitive terms are encountered during the compression, instead of displaying it a second time the compressor says "This text is found 67 characters ago." So this reduces the overall size of the compressed output. In the above request, since the word "secretcookie" is repeated, the compression is done accordingly by taking note of it. Now the attacker sends the below POST requests and observes the compressed sizes.

POST /secretcookie =0….

POST /secretcookie =1…

POST /secretcookie =2…

POST /secretcookie =3…

POST /secretcookie =4…

POST /secretcookie =5…

Now can you guess which POST request would be best compressed, i.e., which POST request would have the smallest compressed size? The one with "secretcookie =5" would compress the best. This is because it has more repetitive characters. In other words, "secretcookie =5" is repeated twice and hence the compressed size is less. Thus the attacker can confirm that 5 is the first character of the secretcookie. Going ahead with this logic, he can brute-force the other characters as well and extract the entire cookie value.

Solution:

CRIME can be remediated by preventing the use of compression at the server end. It can also be prevented at the client end by disabling the compression of HTTPS requests. This is because, in TLS 1.2, the client sends the server a list of compression algorithms that are supported by it and the server picks one of them. If the client sends no compression algorithm, then the data cannot be compressed.

Timing Info-leak Made Easy Attack

In spite of being a very interesting attack, CRIME majorly suffers from two drawbacks:

The attacker must be the man in the middle (to be able to read the messages) and he must also control the plaintext (which is sent as input to the application).

CRIME was very soon mitigated by disabling the TLS compression.

The TIME attack overcomes both of these problems. So this attack doesn't need an attacker to sniff the network. Instead of focusing on the HTTP request, it focuses on the HTTPS responses. To explain this attack in simple terms, all an attacker needs to do is redirect a user to a malicious website that will run some JavaScript to get the encrypted secret data.

Background information

The basic concept here is that, in order to find out if there is difference in the length of two messages, we can observer the time it takes to send these messages across the network. The larger the difference, the more time it's going to take.

How Is the Attack Accomplished?

The basic goal of the attacker is to force the length of compressed data to overflow into an additional TCP packet. The attacker then pads the remaining data. When the maximum size is crossed, any additional packet created (due to wrong guess), introduces an additional full round trip with a significant delay. Consider a simple user input (say "secret = data"). Assume that the value is reflected in the response along with the "secret." In other words, whatever the user inputs is reflected in the response. Let us say in the first request, the user sends "secret = anything" and receives a response with a size of 1024 bytes. If the user input is "secret=a" in the second request, the response size will be less and hence it will take less time to reach than the first request. Likewise, it is possible to predict the every character in every position of our payload by observing the response times (to be precise by observing the "shortest response times"). This attack is little difficult to comprehend and so I have mentioned a video link here which could give you a better insight for the folks who are interested.

Black hat video link: http://www.youtube.com/watch?v=rTIpFfTp3-w&noredirect=1

Solution

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Including CSRF, CAPTCHA tokens in the request could avoid the multiple requests that an attacker makes using the JavaScript. Adding random timing delays to the decryption for any timing attack can be reasonable to disrupt this attack, but it may not be completely helpful. The application should take care of the reflection of user input in the response.