CRIME (Deflate Token Bruteforce)

INTRO

Many people are talking about the new SSL/TLS attack called CRIME (brought to you by the same people who did BEAST). Just as people were going crazy over BEAST, we are seeing people go crazy about CRIME. Well, someone over at the security section of stack exchange, called Thomas Pornin, came up with a theoretical idea for what this attack might be [1]. After a proof of concept was released revealing that the idea does work and verification that Chrome disabled TLS compression in OpenSSL due to a locked ticket [2], it does seem to be the yet to be released attack. In this post I will be talking about the attack, how it works, and how it may affect you.
Deflate Issue?

SSL supports a compression method called LZ77 found in popular compressions such as gzip. This compression treats the entire request, including given request headers, as a stream of bytes, while deflate finds repeated strings of x length [3] for a compression block. When two string values of x length are seen in the request, they should be deflated and given a token and location to previous match. If there are extra bytes after the match, then those bytes will be given a different token. Therefore, if we were able to know a victim value and give it part of a known value, we should be able to check lengths of returned data to see if the known value was given this same token as a previous match (victim value token). When we are off from a valid match, then extra data will be seen from a new token of a different compression block.
Example Please!

Let’s say we know that authentication for a particular web application, victimapp.com, is validated using only a php web server’s session cookie. We will call this cookie PHPSESSID. Let us also say that the victim has been redirected to our attack site, attacksite.com, and the attacker is located on the same public wifi access point as the victim. We know that we need the PHPSESSID cookie of the victim in order to authenticate to victimapp.com, but we do not know the value. However, we have javascript and can submit multiple POST requests to victimapp.com. As the browser includes known origin data for the local user, victim, their information will be transmitted along with our created POST request. So it should look like:

POST / HTTP/1.1
Host: victimapp.com
Cookie: PHPSESSID=38df848273efa73d
Accept-Encoding: gzip,deflate,sdch

As you see, the PHPSESSID value was already available to the browser and thus submitted with the request. What we will try to do is guess the cookie value by submitting the headers in our post body.

POST / HTTP/1.1
Host: victimapp.com
Cookie: PHPSESSID=38df848273efa73d
Accept-Encoding: gzip,deflate,sdch
/*post body below*/
POST / HTTP/1.1
Host: victimapp.com
Cookie: PHPSESSID=0
Accept-Encoding: gzip,deflate,sdch

When the compression happens, deflate will see the string “Cookie: PHPSESSID=” as an 18 byte repeated sequence and give it the token it gave the first 18 byte sequence. However, as 0 is not a match, this will not be part of the same token and instead will be part of a whole new token, which will extend the length of the packet. If we keep guessing, as soon as we have our first match of “Cookie: PHPSESSID=3″, then deflate will not have to create a new token for the extra bytes, meaning a shorter packet. So we can keep bruteforcing values until we tokenize the entire wanted victim value of “Cookie: PHPSESSID=38df848273efa73d”.

*This is a very simplified version for easy consumption. Size of 8 bits for hufmann style compression blocks not talked about. Watch now available Rizzo slides for more technical details.

Is This CRIME?

We still do not know if this is the CRIME attack or not. It looks very convincing and the attack works, but we will not know for another couple of weeks if this is the same issue. Proof of concept code has been posted [4] for the deflate issue and available to check out and play with. While we may not know if it is CRIME 100%, we do know that this is a working attack.
Can We Patch It?

It is possible to disable SSL compression in your browser of choice. Chrome has already disabled it for their browser and more may be to come. Until then you can take steps to disable it yourself in whatever browser(s) you are using in your environment(s).

Conclusion

So, should we be worried about this attack? I equate the CRIME attack to using a bomb to kill an ant. While it is cool, it is much more than what is needed to get the objective done. Yes, this can be used for any plaintext data like xsrf tokens or oauth tokens. Remember that the crux is the attacker needs to see the response body. The attacker needs to be able to get the victim to visit his website for the duration of time while he can monitor response packets or inject data into live sessions using a tool like Ettercap with a MiTM situation. Sure, it is possible, but the prior requirements make this attack more complicated than it needs to be. It’s noisier than other options, has more requirements than is acceptable for given objective, and is more complicated than it needs to be. I am reminded by a passage from the Zero for Owned zine:

“Are you professional types really this out of touch? I see all these papers about how to protect yourself from these super-fucking-advanced techniques and exploits that very few people can actually develop, and most hackers will NEVER USE. It’s the simple stuff that works now, and will continue to work years into the future.”

References

[1] http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/ – Analysis of Thomas Pornin’s Possible CRIME attack
[2] https://chromiumcodereview.appspot.com/10825183 – Chrome TLS Compression Disabled Commit
[3] http://tools.ietf.org/html/rfc1951#page-12 – LZ77 Deflate Length values
[4] https://gist.github.com/3696912 – SSL Deflate Attack



Contribution by Tyler Borland, Security Researcher