Slashdot Mirror
BREACH Compression Attack Steals SSL Secrets
msm1267 writes "A serious attack against ciphertext secrets buried inside HTTPS responses has prompted an advisory from Homeland Security. The BREACH attack is an offshoot of CRIME, which was thought dead and buried after it was disclosed in September. Released at last week's Black Hat USA 2013, BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes. Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at Black Hat. Once the Web application was opened and the Breach attack was launched, within 30 seconds the attackers had extracted the secret. 'We are currently unaware of a practical solution to this problem,' said the CERT advisory, released one day after the Black Hat presentation."
Wow, my jaw is on the floor
Those guys are giving away all your exploits.
Sig Battery depleted. Reverting to safe mode.
Lets see, gotta have man in the middle AND requires the attacker and victim to be on the same network.
Piece of cake!
A bullet may have your name on it, but artillery is addressed to " Whom It May concern"
The last attack required that the attacker pwn the server and install malicious javascript on the page that would send tons of data between the client and the server so that the attacker could watch the traffic. Which I guess could be easier than just pwning the server and getting the secret data from it.
It's not clear to me how this attack works outside of a lab. Someone MITMing SSL would either break the certificate chain and read the data directly, or not break the certificate chain and not be able to communicate with the server. From the linked description, somehow they are directing the browser to a URL like somesite.com/trysecret=aaaaaaaaaaaaaaaaaaaaaaaaaa and playing a mastermind-like game where if the packet is shorter due to the string in the URL compressing with the string in the cookie, they know they have X characters in a row correct, but not which ones. When they get all 32 characters in a row, they win your sessionID.
So... how do they get my browser to initiate all these requests?
Perhaps Verisign can offer some form of overpriced "insurance" to make customers feel safer on the Internets. I'm sure it'll be thrown in for "free" with a "SecureSite Ultimate" package, for a mere $1500! GoDaddy will no doubt follow suit.
Nevermind. RTFA for explanation.
So if sounds like this could be practical on a WiFi network??
We simply need more surveillance.
This is quite an ingenious attack, but I am very surprised it has taken people so long to find it, as it is very straightforward and easy to understand conceptually. Makes you wonder "how did I not think of that".
Although it may seem like the requirements of a successful attack are difficult to achieve, this may not be the case.
It is usually very easy to inject some plain-text in the source code of webpages.
On facebook:
https://www.facebook.com/photo.php/INJECT_WHATEVER_YOU_WANT_HERE/
If you view the source of that URL you can see the text "INJECT_WHATEVER_YOU_WANT_HERE" appears 3 times in the source code.
By appending the query string, on youtube:
https://www.youtube.com/watch?v=hLkugwOYbFw&INJECT_WHATEVER_YOU_WANT_HERE
And on google:
https://www.google.com/?INJECT_WHATEVER_YOU_WANT_HERE
That means that an attacker can extract secret information from a lot of the HTTPS pages that you're visiting.
When I first read about this attack, the first fix that came into my mind was to just append /* [random text of random size] */ to all text/html responses.
But this may cause troubles: if the random padding is too large, the purpose of compression
is defeated. If it is too small, workarounds may be found.
Maybe it is time to start thinking of algorithms that perform compression and encryption together, not separately?
Compressing the same secrets many times along with user data repeatedly seems like a bad idea. I know its really easy to point that out now, but this isn't a new issue.
I'm not clear on the details, so this is just my guess at how it really works:
So the issue here is you can be caused to send your secret (a cookie) millions of times adjacent to the injected data and monitor some side channel (size, or timing I suspect).
How about we don't send the same secret every freaking time? Maybe sign the message with the secret, or just trust that the darn TLS session is doing its job? Any time your client can be made to send a secret a ton of times it should set off a red flag. Web dev always seemed like a horrible mess to me: secret tokens that you send with messages is a horrible approach to just about anything, even if the channel is encrypted.
We (the sane) already agree how credit card numbers and passwords are used on the web is stupid (here, let me send you my secret so you can tell who I am/impersonate me). These cookies are the same stupid shit all over again with the same problems, and we are stuck with them for the foreseeable future for legacy reasons. Its a solved problem in cryptography (SRP for passwords, use public key crypto and hashes to sign credit card transaction requests etc). I hate this.
While it is tempting to make-believe SSL provides strong security, this is not the case, never has been. Moreover, nobody seems to believe that it provides strong security: users, UX designers, web developers, browser vendors, third-party vendors, certificate authorities, ⦠certainly none of these.
My personal view is that SSL provides adequate protection against casual passive observer. It would be very useful if we had means of communicating securely on the Internet, but we do not.
FTA: "mitigations include disabling HTTP compression"
What's the point of HTTP compression anyway? Text is a small part of the bandwidth, and most other stuff (pictures, etc.) are already kept/stored/transferred in highly compressed formats like JPEG. Trying to compress files like that does little or no good. What am I missing here?
I realize most sites have no built in throttling or automatic banning of abusive ip's, but I would imagine most decent (important and so well maintained by someone other than a teenager) sites do. So if this attack requires thousands of attempts, even if the attack attempts are distributed from many ip's, any decent website framework should and could watch for both thousands of request from same ip or thousands of requests for the same base url but different post data... I mean really! There are so many attacks, both dos and breach, that start with malicious, redundant requests - identify and block them!!!! Good Lord folks....
Just disable compression. On Apache its commenting out the LoadModule for mod_deflate. Maybe more of a mitigation than a solution but it should work.
It should be security 101 that you never send your secrets, just send proof that you know the secret.
Nevermind. RTFA for explanation.
See? Text compression in action!
"A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
Amused by notion one would expect a different outcome with HTTP layer vs TLS layer compression. In every way that matters it is exactly same issue only this time attack analysis is limited to response body.
Also have some trouble with assertion "it is very common to use gzip at the HTTP level." For static assets sure however I expect numbers for dynamic content to be a much different story.
The DEFLATE and gzip formats allows multiple blocks of compressed data as well as blocks containing literals with no compression. Plus, just because the default implementation always looks for duplicate strings, doesn't mean you always have to do so. While it would add a heck of a lot of complexity, it should be possible for a web server to ignore duplicates that occur in sensitive strings, and output them in literal blocks so that they don't effect the frequency data of the rest of the stream. All without requiring any changes to browser implementations. This is far from simple, but could probably be done in a generic way for well known http headers.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
The CERT advisory is wrong.
“There’s a small, but definite chance that RSA and non-ECC Diffie-Hellman will not be usable for security purposes within two to five years”
The sooner the world switches to ECC the better.
Could adding random-length, random padding to the data before compression help?
This is a known vulnerability to anyone who's thought about it. The solution to this vulnerability is to pad SSL transmissions in a way that totally obfuscates packet size - transmissions from A to B should be quasi-randomly padded so that the transmission size is indistinguishable. The simplest way to accomplish this is by padding all transmissions until they are the same size, which adds a layer of difficulty on top of existing protocols. You can also pad them onto a distribution of expected packet sizes, and deny (or segment and delay) transmissions that exceed that size.
Another parallel vulnerability is that non-dynamic pages on a website can be sniffed out by transmission size. The problem is similar.
Anyone else getting the feeling we're approaching security the wrong way? There will never be an end to these kind of exploits. Worse yet, they force us to reduce performance in order to gain security.
Does it matter if encryption is made before or after compression?