Hacker News Reader

Comment by jgrahamc | Hacker News Reader

Yes.

See: http://security.stackexchange.com/a/19914

Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)?

I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.

You need three things:

1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication.

2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in).

3. Ability to monitor the SSL connection is it is transported across TCP.

Would have been fun if they called this the CPE1704TKS attack instead of CRIME: http://www.youtube.com/watch?v=NHWjlCaIrQo

To expand on your second point, if you have 3, then in many cases you also have the ability to intercept and modify non-encrypted traffic. Meaning, if the victim is using a secure web site and a non-secure site at the same time, the MITM can infiltrate the non-secure site and use it to generate requests to the secure site.

I think you're correct here but how would you manipulate the cookies being sent when sending XSS requests from a different domain?

you don't need to manipulate the cookies being sent, only the body of the message. The browser will send the correct cookie in the header, you control the body, and use the length of the message to determine how close the cookie value in the body is getting to the one in the header.

For CRIME, I don't think that it's necessary to control the cookies. Having control of other parts of the request should be sufficient (e.g., using request headers, request body, etc).

As for manipulating cookies from the MITM perspective, here's one clunky way to do it: redirect the victim's browser to the plain-text version of the target web site, intercept that request, and set a new cookie (pretending to be the plain-text version of the target web site). The next request to the secure version of the target web site should contain the injected cookie. As tptacek mentioned in another comment, this approach would not work with a site that uses HTTP Strict Transport Security.

The attack as Pornin outlines it does not involve controlling the cookie header, but rather on being able to get content into the client's TX stream that happens to match the cookie header; think in terms of things like query args and post data.

I think all three comments in this little subthread might be saying the same thing. Go nerddom!

That's why sites need to enable the Secure flag on their cookies, and to set the Strict-Transport-Security headers.

Won't help in this case.

I don't know what you're saying. If you're saying that the "Secure" flag won't defend against CRIME, nobody is saying that. I'm saying that the "Secure" flag and HSTS mitigates SSL-stripping.

Oddly, GP's account was made for the purpose of writing that comment. I'm unsure what that means.

I think both ivanr and thatwonthelp were suggesting that any non-secure site (same origin or not) can be hijacked in order to make the requests necessary for this attack.

I understand and agree with your comment about the secure flag, but if I understood ivanr's comment it doesn't apply.

Would have been fun if they called this the CPE1704TKS attack

That one was not cracked one character at a time in series, portions in the middle were discovered sooner. But, yeah, would have been a more appropriate, cooler name.

You don't even need (3) if you can do enough trials and have an accurate clock. Compression by its very nature drips timing side channels.

Due to the padding of even compressed SSL segments only having timing data will significantly complicate things. You'll be trying to measure the variance in deflate compressing different blocks with single byte differences. You better have an extremely low jitter connection!

> You better have an extremely low jitter connection!

Like AWS. (Cite: http://dl.acm.org/citation.cfm?id=1653687.)

I doubt youd even have to break SSL using that attack. Lots of people do SSL termination at the load balancer.

Okay, but people don't run web browsers on AWS.

except when they do! http://www.amazon.com/gp/help/customer/display.html/?nodeId=...

Doesn't do HTTPS, also I am skeptical of cross-site javascript shenanigans happening on the server-end of silk.

People do run HTTPS clients on AWS, though. Web APIs tend to [1] require exactly that.

[1] Lala people never send sensitive data over plain HTTP I'M NOT HEARING YOU.

Sure, they might use HTTPS, but how often do they load arbitrary pages with uncontrolled javascript?

Pretty much never. How often do they make requests that are at least partially attacker-controlled, though? (Note that variants on https://www.someapi.com/...?username=foo contain attacker-controlled data...)

Low jitter is not a requirement for timing side-channel attacks. As long as the jitter is uncorrelated with the timing difference that you're after, you can filter the signal from the noise.

Are there credible situations where you would be able to do (2) but not able to simply read the cookie from the DOM and send it to an attacker controlled website?

An attacker can build a hidden form that submits to a URL at the victim site, and submit it repeatedly using javascript. Alternatively an attacker could put the test content in the URL (we don't care if it 404s), which would work just as well and allow them to use a series of script-free pages full of images.

edit: tptacek is absolutely right; there isn't a way to defend against this in application code. All you can do is turn off TLS compression. This is NOT by any means the only approach, it's just the most obvious one.

Careful: you're outlining the attack well, but you wouldn't want to give someone the impression that defending against CSRF also defends against attacks like BEAST.

You can't read the cookie for the victim website from a malicious site. What you can do is send POST/GET requests to which the browser will attach the appropriate cookies.

Oops, yes of course, now I feel stupid for asking. Thanks.

As I understand it, only 2 and 3 are needed. The (secret) cookies are the part that is determined by the SSL compression exploit, by trying subsequent parts.

You're right that Hollywood "guess the password one character at a time" animation makes sense here. It also makes sense for timing based attacks. Ie, if checking "AB" against the password takes longer than "A", you know the second character is B...

What I meant was that the browser must have some cookies stored to send to the target, cookies that the attacker wants to discover.

The attack as described by Thomas Pornin is indeed specific to HTTPS. Generalize it past HTTPS and its elements are:

1. Attacker controls some parts of plaintext

2. Attacker's content is mixed with content attacker wants to discover

3. Attacker can make repeated trials against the same plaintext (not against same ciphertext stream or key)

4. Defender compresses content on the fly

There are probably other cryptosystems that have this flaw, but it's less inherent to TLS than it is to the HTTPS security model.

Juliano and Thai actually coined the name "Hollywood attack" for exactly this concept back when they presented the chosen-boundary attack on TLS 1.0.

> Hollywood "guess the password one character at a time" animations

Did you see the BEAST attack? Exactly one byte at a time: http://www.youtube.com/watch?v=BTqAIDVUvrU

Serge Vaudenay's CBC padding oracle attack plays out the same way, as does the simplest attack on ECB mode crypto.

You also need the client and server to both support TLS compression. But there aren't any major sites (that I know of) which do support TLS compression.

In my quick test, about 42% of the sites in the SSL Pulse data set (~180k SSL sites in Alexa's top 1m) support compression. For example, mail.yahoo.com does.

Google, Yahoo, Twitter are vulnerable based on SSL Labs tool

That "Guess the password one char at a time" thing also occurs in real life when people forget to use constant time comparison functions.

A better comparison function:

Variable time until some threshold number of repeat failures occurs (e.g. 3). After this, manipulate the comparison time in such a manner that someone attempting to do this sort of attack would come up with a dummy password. If they come up with said dummy password, alert the user of an attempted attack.

Cool idea, but remember the botnets. I also am not sure what we gain by verifying their class of attempt if we're already defending against it.

Very interesting, using differential analysis on the compression output is pretty clever.

Note that it is effectively the same attack as ECB byte-by-byte decryption, except using record length instead of repeated blocks as the signal.

Stupid question: does TLS's compression use the _same_ compression state for both directions of the connection? That seems hard to me, because they could be sending information in parallel, and there's no provision for syncing streams.

So I suspect the attack there cannot work on TLS, and in fact the demo code posted in a comment attacks local zlib, not TLS.

I think the actual attack, if it's along these lines, involves getting the server to echo back your guess of the cookie, so that the cookie and your guess are both on the same stream. Perhaps with TRACE?

The attack Pornin outlined involves only the client TX stream, which the attacker shares with the defender by virtue of content-controlled Javascript.

Oh, I got Set-Cookie and Cookie mixed up in my head. You're right.

Heh, anyone else notice the proposed attack strongly resembles Level 8 in the last Stripe CTF?

That Stripe CTF was deceptively excellent. If you (the reader of this comment) got through it and had fun, I promise, we'd be both interested to talk to you and an interesting company for you to talk to. www.matasano.com/careers.

Unless I'm missing something, I reckon there's a really obvious improvement on that, but Stack Exchange doesn't let new users leave comments. Think of the old puzzle where you've got 9 bags of gold coins which weight 10 grams each and one bag of shaved coins which weigh only 9 grams each and you need to figure out which bag has the shaved coins in only one weighing. You should be able do the same thing here - add one "Cookie: secret=A", two "Cookie: secret=B" and so on. Because of the limited look-back window in the compressor you'll need to interleave them like ABCD...BCD...CD... but it should give more information.

Edit: Wait, I am. That wouldn't work because it'd compress the repeated subsequences. D'oh.

You could still probably get more than a bit per request along those lines with some experimentation.

Probably, yeah. Thinking about it, one obvious approach might be to try and overlap the last step of guessing one byte with the first step of guessing the next byte, for instance.

Interesting. The attacker would also need to push the request size up to the next block boundary, but it should work.

At least we can still do compression at the HTTP (or other higher-level protocol) level. That gets us most of the benefit anyway.

I suspect most TLS libraries will flush the compression buffer after each write call so its highly likely that every request will end on a deflate block boundary already.

Compressed Redundancy in Message Exploit?

Compression Reveals Information Meant (to be) Encrypted?

This attack procedure applies only for dictionary based compressions. Correct?

What would be the procedure if you use bzip2 (which is based on Burrows-Wheeler transformation) compression?

It shouldn't matter so long as redundancy between headers and body result in a smaller cyphertext.

Due to the nature of compression algorithms using BWT, changing a single byte in the uncompressed data might give you +/- 5 bytes difference in the size of the compressed data; that makes pulling off an attack like this much, much, much more difficult. Don't get me wrong, you'll get variance with deflate as well, but it's nowhere near the level of something like bzip2.

I do a lot of experimentation with new compression techniques for web demos, and I recently implemented my own compression algo from scratch based around the same building blocks as bzip2. The variance I saw was just staggering; a tiny change in my source material would totally warp the output.

I would love to see somebody proving or disproving whether BZip2 is susceptible to these type of attacks. My assumption is that small changes in MTF transformation and tweaks in creating encoding table will make it impossible to crack using this method.

Fascinating explanation / prediction, thanks.

Reply on news.ycombinator.com