12. September 2012

Breaking SSL/TLS with SPDY

We’ve been hearing 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. Lets hope it is and we’ll have one less thing to worry about.

Some homework first:

Before diving in to 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. 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:

Now the idea is if we can control the headers of the request being 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 enables 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--

I like playing 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, lets assume that am interested in cookies which has a secure or httpOnly flag set. There are already a few of them, but lets 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 yea 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.

The real deal:

I would come up with a PoC soon which works specific to the zlib compression context used in SPDY. And also this sends a message across that, any encrypted payload which incorporates compression opens up a new attack surface to leak encrypted information.