On 06.08.2013 19:36, Paul Querna wrote: > On Tue, Aug 6, 2013 at 10:32 AM, Eric Covener <[email protected]> wrote: >> On Tue, Aug 6, 2013 at 1:24 PM, Paul Querna <[email protected]> wrote: >>> Hiya, >>> >>> Has anyone given much thought to changes in httpd to help mitigate the >>> recently publicized breach attack: >>> >>> http://breachattack.com/ >>> >>> From an httpd perspective, looking at the mitigations >>> <http://breachattack.com/#mitigations> >>> >>> 1) Disabling HTTP compression >>> 2) Separating secrets from user input >>> 3) Randomizing secrets per request >>> 4) Masking secrets (effectively randomizing by XORing with a random >>> secret per request) >>> 5) Protecting vulnerable pages with CSRF >>> 6) Length hiding (by adding random amount of bytes to the responses) >>> 7) Rate-limiting the requests
The attack seems to focus on response bodies. So secrets transferred via cookies seem to be out of scope here. Any one time tokens should be OK to, e.g. using nonces to protect against CSRF like we do in Apache or Tomcat for some of the pages that need protection. It is protected itself and by reducing the rates with which one can probe a site it should also protect the rest of the page against the attack. The examples I saw where attacking a user id that was included in app pages after login. The user id itself was not sufficient for a login so you would still need to attack the password. Of course you are now down to one unknown token instead of two, but the login name often is pretty easy to get by other means. I think there are two different cases: a) Secrets in the response body which are not displayed to the user by the user agent. That should typically be secrets related to credentials, session IDs. An example are URL encoded session IDs, like e.g. Java apps support them when cookies are off (;jsessionid=...). They are part of the response bodies and you can misuse them for session takeover. Or some continuation id contained in the body of a data request that's not meant to get rendered. Or hidden fields in forms. This kind of information could in principle be twisted by the server as long as it can undo the twist when the data is send (URI, query string, form param) and before it is handed over to the application. As far as I understood the attack, this twist doesn't have to be cryptographically secure, it would only be used to increase the combinatorial complexity of the attack. E.g. a session id could be prefixed by a random token that is used to XOR the rest of the session id. Didn't yet think deeper about that though. b) Private data that gets rendered and displayed. Here the twisting without cooperation by the user agent would break the application display. Example could be the login name of a user displayed on every page or simply some private data like the account number or the amount of money on your bank account when doing online banking. Either you would need a cooperating piece of JavaScript etc., or we could only try to do some twist to the full response that's transparent to the UA but not transparent for the exact compressed byte content. The answer could be something generic - for that I don't know enough about the exact algorithm in deflate - or it could be something depending on mime type - adding stuff like random comments etc. >From your list I find the rate limiting interesting. It would also have more uses than "only" making the attack less feasible. Here we would need to find a good pattern though, e.g. would it be enough to focus on client IP and people using proxies need to switch the protection behind a proxy off. >>> Many of these are firmly in the domain of an application developer, >>> but I think we should work out if there are ways we can either change >>> default configurations or add new features to help application >>> developers be successful: >>> >>> 1) Has anyone given any thought to changing how we do chunked >>> encoding? Chunking is kinda like arbitrary padding we an insert >>> into a response, without having to know anything about the actual >>> content of the response. What if we increased the number of chunks we >>> create, and randomly placed them -- this wouldn't completely ruin some >>> of the attacks, but could potentially increase the number of requests >>> needed significantly. (We should figure out the math here? How many >>> random chunks of how big are an effective mitigation?) >> Another option in this neighborhood is small/varying deflate blocks. >> But that probably limits the usefulness of deflate to the same extent >> that it helps. The idea is to make it less likely that the user input >> and secret get compressed together. >> >>> >>> 2) Disabling TLS Compression by default, even in older versions. >>> Currently we changed the default to SSLCompression off in >=2.4.3, I'd >>> like to see us back port this to 2.2.x. >> >> I think it recently made it to 2.2.x, post the last release. Yes, last Saturday but after 2.2.25: http://svn.apache.org/viewvc?view=revision&revision=1510043 >>> 3) Disable mod_default compression for X content types by default on >>> encrypted connections. Likely HTML, maybe JSON, maybe Javascript >>> content types? Or: For non-static Content? >> In the code, or default conf / manual? It's the cautious thing to do, >> but I'm not yet sure if making everyone opt back in would really mean >> much (e.g. what number would give their app the required scrutiny >> before opting back in) > > In the code. But currently mod_deflate is off by default and TLS Compression is off by default in 2.4 and next 2.2. So apart from releasing another 2.2 we are already at disable by default. Regards, Rainer
