Comment by peterwwillis | Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Parent Full thread

Here is the attack:

Jim "Doctor Doom" Brosowski, an extraordinary hacker and renowned flip-cup player, sits in a Starbucks sipping his grande caramel macchiato. His laptop is open to a Youtube clip of cats dancing to "Stayin' Alive", while in the background a curious text box displays an application waiting for input.

Suddenly there's text flashing in the window. A Starbucks customer has just attempted to log into Hotmail! In a microsecond, the hacker's application sends packets that inject javascript code into their browser window, instructing the browser to open an iframe.

First the javascript will query a page with the user's actual e-mail address. The hacker can't see the response over the network because it's encrypted, but he can see the size of the encrypted message.

Then the previously-injected javascript will poll the iframe repeatedly with a specific URL and part of an e-mail address. As responses are returned from a web page, they will either be bigger or smaller, depending on if the compression algorithm has seen that requested text before. So by comparing the size of the original response with the size of these guessed responses, Jim can guess what the "correct" value from the original request was, piece by piece.

Since this attack can be done "in 30 seconds", it should be practical enough to perform in an open area such as a wifi cafe. For more lengthy attacks you'd need a more dedicated place to listen to traffic and inject HTML.

Another method besides injecting HTML into their browser would be to send them some spam to click on with a malicious website. But you still need to be able to listen to their responses, so it is not an attack everyone will be able to use. (But then again, that's the only time SSL/TLS really matters: against man-in-the-middle attacks)

Thanks for the explanation. Please excuse my ignorance, but I want to understand something: the 'html injection' phase would be done by some sort of response spoofing? Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ?

Injection typically involves sniffing their connection and determining the right bits of the connection to be able to spoof your own fake response. It can be done in-between an existing connection or at the start of one.

Browsers have developed all kinds of protections to prevent different kinds of attack. In general, if your cookies have been set with the HttpOnly flag, malicious javascript can not submit someone's cookies to any site other than the original domain (as far as the browser can tell). You can't even view the cookies in javascript to be able to submit them somehow else.

But HTML forms on plaintext pages can be spoofed or injected to submit them to a fake server using SSL or to the real server without SSL, making it easy to view the form data and the server's response. If the site doesn't set the "secure" token on the cookie, existing session credentials can be viewed as well without needing to observe or force the user to log in. This is how the sslstrip program works, and why many people look to new technologies like HSTS to better protect users against these attacks.

The SSL attack in the OP could be used against a site that employed HSTS to capture data from the body of a response if sslstrip failed. If you just want cookie data, the original CRIME attack would be better as it technically works on the headers AND the body, but CRIME depends on TLS compression being enabled, while this attack uses the compression of the body (that every website uses).

>Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ?

You didn't address this question of his, it seems. I would agree that in the scenario you're explaining, it would make far more sense for an attacker to simply modify the non-HTTPS landing page in such a way that the user hands his credentials in plaintext straight to the attacker.

From what I can tell, for BREACH, you don't actually need to inject Javascript into any page belonging to the domain you want to extract secrets from; you simply need to force the user to load a hidden iframe that you control. That iframe will then make repeated GET requests to HTTPS endpoints (which does not violate the same origin policy, so this iframe can be hosted on any arbitrary domain).

Thanks! Minor nitpicks: this would fail if the login page were itself on HTTPS (as most login pages should be). Also, Hotmail no longer exists.

Hotmail was a joke :) But almost all browsers try HTTP before they try HTTPS, which is where the attack commonly comes in (or you intercept their primary request, or sslstrip, etc). Exceptions are if they're Chrome and have a whitelisted set of URLs, or support HSTS, or explicitly specified by the user or a bookmark.

The point is, the attack is there and it works, even if it doesn't work in 100% of cases.

Reply on news.ycombinator.com