Update: The CRIME paper actually talks about SPDY as predicted in this article.
We’ve heard a lot about CRIME recently. And also a lot about security researchers predicting that CRIME may be some form of a chosen plain text attack exploiting TLS data compression. With fingers crossed, we are waiting to see whether Juliano Rizzo and Thai Duong were trying to do something similar with CRIME. Let’s hope it is and we’ll have one less thing to worry.
Some homework first
Before diving into SPDY and the attack, please feel to read the existing research done on this, by Thomas Pornin and the solid Proof of Concept by Kotowicz to get some idea on data leakage using TLS compression. Now what makes the above attack less interesting to me is because browsers have started disabling TLS compression already, take Chrome for instance.
SPDY - Probable successor of HTTP/1.1
SPDY is Google’s proposal to make HTTP much faster and acts like a wrapper to the already existing HTTP and works only over SSL connections. You should read this article on SPDY vs. HTTP if you’re new to SPDY. The chances are that SPDY is behind the curtains if you use any of Google’s services on a Chrome browser.
SPDY’s Design
The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. TLS encryption is nearly ubiquitous in SPDY implementations, and transmissions are gzip-or DEFLATE-compressed by design (in contrast to HTTP, where the headers are not compressed)
- Wikipedia
The real problem here is SPDY’s compression by design to make it faster (they get ~88% efficiency in doing so). This whitepaper contains details on how SPDY compresses headers using zlib and a new idea on how to make it more efficient (Well, we are not bothered about that now)
The Attack
If we can control the request headers that are sent and use chosen plain text attacks just like the ones discussed above, we can leak encrypted data - especially the user’s cookies which are a part of the request headers. Now it doesn’t come easy; we need to take care of a few issues like setting custom header values as part of the cross-domain request and adding the chosen plain text as part of the header itself.
The sometimes harmful CORS
So as we know, the XMLHttpRequest object in latest browsers use XHR Level 2 (Cross-Origin Resource sharing), and they have some subtle bypasses which enable us to send specific Cross-domain requests with certain headers like Allow, Content-Type to be set. Now that is good news for us.
We could do something like, Content-Type: text/plain;<–Chosen Plain Text to be bruteforced–>
Let’s play a scenario
Lets take this attack to Google services. Google as I said already serves almost 90% of its https pages using SPDY if you are using a supported browser like Chrome or Firefox. Now, let’s assume that I am interested in cookies which have a secure or httpOnly flag set. There are already a few of them, but let’s try leaking the cookie named SSID which must have something to do with the session of the currently logged in user.
Imagine a cookie like, SSID=BhjKLJFRhgpeC2Ir. Brute-forcing a cookie like this requires a charset of 26 + 26 + 10 = 62 characters. And imagine the possibilities like HTML5’s WebWorkers which can be used to spawn new threads and make brute-forcing easier. I’ve tested this locally, and yeah SSL can leak data using a PoC like what Koto made. Now that, we have to wait and see how this technique can be used on a real SPDY enabled web application with a tool similar to BEAST.