Hacker News Reader

Comment by jgrahamc | Hacker News Reader

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

View on HN

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!

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.

> 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...)

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.

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.

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.

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

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!

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.

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.

Reply on news.ycombinator.com