A couple of days ago, information about a new attack (CRIME) against Transport Layer Security (TLS) was released. This attack was developed by the same researchers (Juliano Rizzo and Thai Duong) that developed the BEAST attack against SSL/TLS. Although details of the attack are not officially known yet, there is speculation (How can you protect yourself from CRIME, BEAST’s successor?) that it has something to do with TLS compression as specified in RFC 3749. Some testing reveals that this is likely the case.
RFC 3749 specifies a method for compressing data in TLS connections. When a browser attempts to establish a TLS connection, it specifies a list of compression methods that it supports in the “Client Hello” message as shown below.
The server selects one of the compression methods that it supports, and includes it in the “Server Hello” response as shown below.
If the current speculation is correct, the CRIME attack is possible if the Deflate compression method is chosen for a TLS connection.
The attack setup is the same as BEAST. The attacker and the victim have to be on the same LAN. The attacker has to inject code into a HTTP site open in the victim’s browser and make cross-domain requests to a HTTPS site that supports TLS compression. The attacker needs to be able to sniff the traffic that his/her code is generating.
One of the operations in Deflate compression is duplicate string elimination (http://en.wikipedia.org/wiki/DEFLATE#Duplicate_string_elimination). The idea is that the request to the HTTPS site will already contain the user’s cookie if the user is authenticated to the site. So, the request will look like:
Now, if the POST data (which is controlled by the attacker) contains the string “JSESSIONID=X”, the compressed request will be smaller than if the POST data contains the string “JSESSIONID=Y” (for example). This is because a longer duplicate string will be found in the request in the first case, and so, the request will be compressed more. So, an attacker can iterate through all possible characters for the first byte of the cookie and pick the one that generates the smallest request. Then, the attacker can move on to the second byte, and so on. This will allow the attacker to brute force the user’s cookie one byte at a time.
To test the theory, I used a version of cURL that supported TLS compression to submit requests to a server that also supported it. I set the following cookie value in my requests:
When I submitted a POST request containing TEST=X, I saw that the compressed request size was 250 bytes:
When I submitted a POST request containing TEST=? (where ? is any other character), I saw that the compressed request size was 251 bytes:
I was able to continue to brute force the cookie one byte at a time in this manner.
Note that in this case, the server picked the TLS_RSA_WITH_RC4_128_SHA cipher suite. If it had picked a block cipher in CBC mode instead of a stream cipher, this attack would be slightly more complicated as the attacker would have to deal with block boundaries when guessing characters. However, this is not a significant hurdle.
For this attack to be effective, both the browser and the server have to support TLS compression. As of today, the latest versions of Microsoft Internet Explorer, Google Chrome and Mozilla Firefox on Windows do not support TLS compression. Google Chrome was apparently updated in early August to fix this issue: https://chromiumcodereview.appspot.com/10825183/diff/1/net/socket/ssl_client_socket_openssl.cc. I do not know when other vulnerable browsers might have been updated.
Additionally, I had a hard time finding a server that would allow TLS compression to be used. I visited 20+ HTTPS sites that I commonly visit and all of them selected null compression.
This may have been a significant problem a couple of months ago, but it does not currently seem to be an issue. However, you should make sure that you are running the latest versions of browsers and server software.
There are at least two lessons to be learned here:
Amit Sethi, Principal Consultant, has been with Cigital since 2004. He specializes in Mobile Security, Online Game Security and Cryptography. Amit’s work includes extracting cryptographic keys from embedded devices using side-channel attacks, designing mechanisms to make those attacks more difficult, and designing a format-preserving encryption algorithm based on well-studied cryptographic primitives for a Fortune 500 company. Even in his free time, Amit enjoys reverse engineering binaries, analyzing open source software, and experimenting with new technologies.
Words of Security Wisdom: Just because you don’t know of any security incidents in your software/environment doesn’t mean that you haven’t had any security incidents –especially if you don’t have good monitoring controls in place.
Cigital is one of the world’s largest application security firms. We go beyond traditional testing services to help our clients find, fix and prevent vulnerabilities in the applications that power their business.
Our experts also provide remediation guidance, program design services, and training that empower you to build and maintain secure applications.
Gary McGraw Delivers AT&T Cybersecurity Conference Keynote
Building Security into the SDLC Without Impacting Velocity
Adding Security Steps to Your “agile” Development Process
Benefits of Code Scanning for Code Review
Get a free 30-day trial of SecureAssist & build more secure code from the start. Click here sws.ec/1hm9GkS pic.twitter.com/FARYchzkE0
About an hour ago
RT @cigitalgem: Flying to NY for that now (in a tiny turbo prop built pre-wifi). @cigital @ATTsecurity
.@cigitalgem to Deliver @ATTsecurity Conference Keynote | Cigital sws.ec/1jKvet7 #appsec
About 2 hours ago
Attackers Use Webmail Server for Access to Firm's Systems via @securityweek | sws.ec/1jKvB77 #appsec
This @Cigital Whitepaper will show you how to Prevent Common Bugs and Flaws from being introduced into your software sws.ec/1jKdX3q