It’s perhaps not immediately obvious that the paper itself is linked from this page at the bottom; I thoroughly recommend a read as it goes into substantial detail about the technical challenges they faced in getting a working proof of concept and therefore sheds a lot of light on various actions you can take to reduce your attack surface.
Here are the slides from their BH presentation. Also the archives are online with a bunch of papers and slides from the rest of the con if anyone is interested.
Related attack that doesn’t even require compression: generate markov chains and search gmail for them. You can check the response length to read somebody’s inbox. Slowly. :)
It’s perhaps not immediately obvious that the paper itself is linked from this page at the bottom; I thoroughly recommend a read as it goes into substantial detail about the technical challenges they faced in getting a working proof of concept and therefore sheds a lot of light on various actions you can take to reduce your attack surface.
They spent over half the talk talking about how the roadblocks they encountered. It comes down to disabling compressed responses.
I don’t suppose you know if the talk will end up online?
I don’t think the BlackHat talks usually end up online, but you never know, I guess.
Here are the slides from their BH presentation. Also the archives are online with a bunch of papers and slides from the rest of the con if anyone is interested.
Cool. I think I wrote about a subset of the same problem. It seemed like the logical next step from CRIME. http://www.tedunangst.com/flak/post/improving-csrf-prevention
Related attack that doesn’t even require compression: generate markov chains and search gmail for them. You can check the response length to read somebody’s inbox. Slowly. :)
In the talk, they mentioned that this was pretty much foretold in the CRIME paper.
Reading your post, it seems you could have presented if you’d built the proof of concept ;)
well…shit.