5 ms·

I was confused about that too. They don't make the request, they force you to make the request (by putting a bunch of them as pixels in an HTML email, or by get

by seldo 13y ago

I was confused about that too. They don't make the request, they force you to make the request (by putting a bunch of them as pixels in an HTML email, or by getting you to trigger some JS). I'm still not clear on how they see the traffic -- I guess the attack relies on having a packet sniffer that can see the encrypted packets go by?

StavrosK 13y ago
No, I know that part, but I mean that this method can only sniff headers, pretty much, as long as they're being compressed. They own the body, since they're injecting data into it, the only thing they don't own is the headers, which is the only thing they can guess. If HTTPS compresses headers separately, or not at all, it's useless.
- AnIrishDuck 13y ago
  This attack is on HTTP compression, which covers only the body of the request, not the headers [1]. 1. http://en.wikipedia.org/wiki/Http_compression http://en.wikipedia.org/wiki/Http_compression
  - StavrosK 13y ago
    Yeah, so you'll have to be able to write to, but not read, the body of the request, observe the ciphertext on the wire and guess things in the body only. So this is only good for CSRF tokens and the like, and only if you can write to the plaintext you want to guess but not just outright read it.
- seldo 13y ago
  The attack builds on the CRIME attack, which is discussed in more technical detail here: http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl http://zoompf.com/2012/09/explaining-the-crime-weakness-in-s... That page suggests that guessing known text like an SSN or email address contained in the body would give them an opening to break the encryption entirely, but I don't know enough about crypto to know if that's actually a possibility.
- singlow 13y ago
  I guess I thought they were guessing the POST data from a login form -but I see what you are saying. The POST request in URL encoded form or multi-part form data is not compressed anyway, only the response is affected by deflate. So I am curious too, how a password would be in the gzip dictionary, since it should never be sent back to the browser in compressed form.
bradleyjg 13y ago
For the attack to work you need to be able to eavesdrop on the ciphertext. Network protocols don't make any particular effort to prevent that, although the move from shared ethernet to switched ethernet has made it more difficult.
- cma 13y ago
  The rise of wifi means there is still a lot of shared ethernet.
- adamtj 13y ago
  Arp spoofing works even over switched ethernet. With it, you can convince other machines that yours is their gateway, and then you can not only see, but modify all their network traffic. https://en.wikipedia.org/wiki/ARP_spoofing https://en.wikipedia.org/wiki/ARP_spoofing
AnIrishDuck 13y ago
I think it's actually more limited than that ... they have to be able to modulate the response body through a request, which sounds really f'in difficult to do with a properly designed web application. I'm pretty sure they need a server that responds to POST form requests with user-specified unchecked data from that form, in addition to secret data the attacker actually wants. And the more I think about it, the more I wonder how existing CSRF protections wouldn't block that already. I really wish I could find more details on this attack; I like Ars Technica for general news but the technical details are lacking here.
- samwillis 13y ago
  Most forms maintain the data that was entered by the user when there is a validation error. Say the attacker is after csrf token they could just use one of the fields in the form for entering their guess and it will be included in the responce.
- StavrosK 13y ago
  You could do this more easily if the page included data from the GET query, something like a name or a search query or something like that, which gets echoed in the response.
peterwwillis 13y ago
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)
- seldo 13y ago
  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.
  - peterwwillis 13y ago
    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.

by seldo 13y ago

StavrosK 13y ago

No, I know that part, but I mean that this method can only sniff headers, pretty much, as long as they're being compressed. They own the body, since they're injecting data into it, the only thing they don't own is the headers, which is the only thing they can guess. If HTTPS compresses headers separately, or not at all, it's useless.

AnIrishDuck 13y ago
This attack is on HTTP compression, which covers only the body of the request, not the headers [1]. 1. http://en.wikipedia.org/wiki/Http_compression http://en.wikipedia.org/wiki/Http_compression
- StavrosK 13y ago
  Yeah, so you'll have to be able to write to, but not read, the body of the request, observe the ciphertext on the wire and guess things in the body only. So this is only good for CSRF tokens and the like, and only if you can write to the plaintext you want to guess but not just outright read it.
seldo 13y ago
The attack builds on the CRIME attack, which is discussed in more technical detail here: http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl http://zoompf.com/2012/09/explaining-the-crime-weakness-in-s... That page suggests that guessing known text like an SSN or email address contained in the body would give them an opening to break the encryption entirely, but I don't know enough about crypto to know if that's actually a possibility.
singlow 13y ago
I guess I thought they were guessing the POST data from a login form -but I see what you are saying. The POST request in URL encoded form or multi-part form data is not compressed anyway, only the response is affected by deflate. So I am curious too, how a password would be in the gzip dictionary, since it should never be sent back to the browser in compressed form.

bradleyjg 13y ago

For the attack to work you need to be able to eavesdrop on the ciphertext. Network protocols don't make any particular effort to prevent that, although the move from shared ethernet to switched ethernet has made it more difficult.

cma 13y ago
The rise of wifi means there is still a lot of shared ethernet.
adamtj 13y ago
Arp spoofing works even over switched ethernet. With it, you can convince other machines that yours is their gateway, and then you can not only see, but modify all their network traffic. https://en.wikipedia.org/wiki/ARP_spoofing https://en.wikipedia.org/wiki/ARP_spoofing

AnIrishDuck 13y ago

I think it's actually more limited than that ... they have to be able to modulate the response body through a request, which sounds really f'in difficult to do with a properly designed web application. I'm pretty sure they need a server that responds to POST form requests with user-specified unchecked data from that form, in addition to secret data the attacker actually wants. And the more I think about it, the more I wonder how existing CSRF protections wouldn't block that already. I really wish I could find more details on this attack; I like Ars Technica for general news but the technical details are lacking here.

samwillis 13y ago
Most forms maintain the data that was entered by the user when there is a validation error. Say the attacker is after csrf token they could just use one of the fields in the form for entering their guess and it will be included in the responce.
StavrosK 13y ago
You could do this more easily if the page included data from the GET query, something like a name or a search query or something like that, which gets echoed in the response.

peterwwillis 13y ago

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)

seldo 13y ago
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.
- peterwwillis 13y ago
  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.