Background

Juliano Rizzo and Thai Duong, the authors of the BEAST attack on SSL (or TLS - used interchangeably here), have released a new attack dubbed CRIME, or Compression Ratio Info-leak Made Easy. The attack allows an attacker to reveal sensitive information that is being passed inside an encrypted SSL tunnel. The most straightforward way to leverage this vulnerability is to use it to retrieve cookies being passed by an application and use them to login to the application as the victim.

CRIME is known to work against SSL Compression and SPDY. SPDY is a special HTTP-like protocol developed by Google, and used sparingly around the web. According to Ivan Ristic's statistics, gathered by SSL Pulse, about 42% of the servers support SSL compression, and SPDY support is at 0.8%. SSL Compression is an optional feature that may or may not be enabled by default - it's unlikely to have been explicitly configured. SPDY however is something that would be explicitly designed into your web application.

Technique

CRIME works by leveraging a property of compression functions, and noting how the length of the compressed data changes. The internals of the compression function are more sophisticated, but this simple example can show how the information leak can be exploited. Imagine the following browser POST:

POST /target HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Cookie: sessionid=d8e8fca2dc0f896fd7cb4cb0031ba249

sessionid=a

This data shown in binary looks like this:

As mentioned, the internals of the DEFLATE compression algorithm are more sophisticated, but the basic algorithm is to look for repeated strings, move them to a dictionary, and replace the actual strings with a reference to the entry in the dictionary. We'll take the above example, and identify two repeated strings we can remove: ".1" and "sessionid=". We'll move them to a dictionary, and replace them with bytes not used in the message (0x00 and 0x01):

This has compressed the message from 195 byte to 187 bytes. In the body of the request, we specified "sessionid=a". Watch what happens when we specify "sessionid=d", which is the first character of the secret session cookie:

Now we've compressed the resulting message from 195 bytes to 186 bytes. An attacker who can observe the size of the SSL packets can use this technique in an adaptive fashion to learn the exact value of the cookie.

As mentioned, the internals of the real deflate have to account for a lot more than this (for example, length of the extracted string) and works with a sliding window across the data (examining the entire data in chunks instead of at once) - but this toy example shows the single byte length difference we are looking for to reveal we've guessed the correct character. For more sophisticated analysis you can check out Thomas Pornin's answer at stackexchange and Krzysztof Kotowicz'a proof of concept code. In the coming weeks we'll also get more details from the authors that explain how they overcame other hurdles to exploitation, such as the Block Cipher Padding in AES.

Exploitation Scenarios

In our toy example above we placed our guess for the cookie in a POST body. Initially, speculation was to exploit CRIME you would require the ability to run JavaScript inside the target domain - such as through a Cross-Site Scripting Attack. Since then, a number of novel techniques have been discussed, including:

• Cross Domain requests
• moving the payload to the querystring in a GET request
• using <img> tags (a method used by Rizzo/Duong)

It's clear that there are an uncountable number of ways to exploit the vulnerability if it is present. Rather than trying to block individual avenues to exploitation - which is likely impossible - we recommend you mitigate the issue at the source by disabling SSL Compression (and SPDY Compression if used.)

Mitigation

Disabling compression is the agreed-upon approach to mitigating the vulnerability. Very few clients support SSL or SPDY Compression, and the major ones that do (Chrome and Firefox) have patched it. Disabling SSL Compression is different from disabling HTTP Compression - and will almost always have no adverse affects (especially because many clients already do not support it). If HTTP Compression is enabled, SSL Compression will only compress HTTP Requests and Response Headers - a small percentage of the traffic compared to the body of web application pages.

At this point, the latest versions of all browsers will not offer Compression in SSL. The following versions were explicitly tested.

• All versions of Internet Explorer (No Versions of IE support SSL Compression)
• Google Chrome 21.0.1180.89
• Firefox 15.0.1
• Opera 12.01
• Safari 5.1.7 on Windows
• Safari 5.1.6 & 6 on OSX Lion

Server-Side Mitigation

In most cases you can rely on clients having been patched to disable compression. If you want to perform due diligence you can disable SSL Compression server-side also. You can test for SSL Compression using the SSL Labs service (look for "Compression" in the Miscellaneous section) or using iSEC Partners' ssl scanning tool SSLyze v0.5.

If you have Compression enabled, the method of disabling it varies depending on the software you're running. If you're using a hardware device or software not listed here, you'll need to check the manual or support options and note that you want to disable SSL Compression - it shouldn't be confused with HTTP Compression.

Apache 2.4 using mod_ssl

Apache 2.4.3 has support for the SSLCompression flag. This is a very new release of Apache - the feature itself was added in August, 2012. SSLCompression is on by default - to disable it specify "SSLCompression off".

Apache 2.2 using mod_ssl

The patch will be backported from Apache 2.4 to Apache 2.2 in 2.2.24 according to the corresponding issue for mod_ssl.

Apache using mod_gnutls

If you are using mod_gnutls you can specify the GnuTLSPriorities flag to disable compression. Specify "!COMP-DEFLATE" to disable compression.

IIS

Microsoft IIS does not support SSL Compression - even in IIS 7.5/Server 2008 R2.

Amazon Elastic Load Balancers

iSEC Partners has confirmed with Amazon that Elastic Load Balancers do not support TLS Compression.

Acknowledgements

Thanks to a few folks for their help in preparing this post: Alex Garbutt, Doug DePerry, Rafael Turner, Rachel Engel, and the team at Second Market.

This post originally appeared on iSEC Partners' blog.

if 1 * 2 < 3:
    print "hello, world!"