Re: Cookie Monster
On Wed, Sep 17, 2008 at 6:39 PM, EMC IMAP [EMAIL PROTECTED] wrote: It turns out hardly anyone bothers to mark their cookies secure. In Firefox, if you list your cookies, you can sort on the Secure field. I only found a couple of cookies marked - mainly from American Express, one of the few sites that gets this right. (Bank of America, for example, doesn't; Gmail with the new HTTPS-only setting does, but other Google services don't.) This isn't a new problem. I might be inclined to argue that it used to be worse in terms of vulnerability (though today it's worse in the asset exposed through vulnerability, e.g., a stolen session can be a bigger problem today than it was). We found the same problem with the BankOne Online site eight years ago. The part that we found significant about that was that the UserID field then was a working customer payment card number. http://www.interhack.net/pubs/bankone-online/ Back-end systems for dealing with authentication of sessions and so on tend to be more sophisticated these days, which also helps. While this is probably happening very little if at all in systems like Web-based email, at least in higher-value Web applications there is better detection of fraud. In particular, I am seeing more systems that are paying attention to source IP addresses in combination with other factors like cookies to determine whether the request is legitimate. -- Matt Curtin, author of Brute Force: Cracking the Data Encryption Standard Founder of Interhack Corporation +1 614 545 4225 http://web.interhack.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cookie Monster
EMC IMAP wrote: Yet another web attack: http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/ My own conclusion from this: This is yet another indication that the whole browser authentication model is irretrievably broken. It's just way too complex, with way too many moving parts which can interact in dangerous ways. The list of requirements for a safe Web application - even just based on attacks known today - is so long that no one can remember them all, much less check any substantial Web application to see if it follows them. We need a better approach. As I posted earlier: SSL/TLS does not supply secure logon and sessions, because it does not know what a session or a login is. Instead http+tls provides a pile of matchsticks and glue with which the website server can implement something that kind of sort of mostly behaves rather like logins and sessions. It should have been obvious that everything really important relates to logins and sessions and that the rest can be treated as a login by anon 37283 with the null password, and that therefore the cryptography *and* *the* *browser* *user* *interface* needs to implement logins and sessions. It should have been obvious that logging in on the web page was going to lead to the phishing disaster - that people should login on a trusted path from the browser chrome. The user login status should be displayed in the chrome on every logged in web page, and the server has to know that the user knows his login status, has to know the login status not only of the user, but of the web page that the user has clicked on that generated this request to this server. The state of being logged in should guarantee privacy and authenticity - that only the client and the server can know what they are communicating, and that no one else should be able to pass himself off as client or server, or modify their communications Everything should have been written around the user concepts of logging in a logged in page, and logging out, and should have made those user concepts real, made them into pages with appropriate built in cryptographic behaviors, rather than providing capabilities that could potentially be used to make pages behave like that. The user concept of logged in has to be real rather than superficially simulated by server side code - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cookie Monster
On Fri, 19 Sep 2008, Barney Wolff wrote: | Date: Fri, 19 Sep 2008 01:54:42 -0400 | From: Barney Wolff [EMAIL PROTECTED] | To: EMC IMAP [EMAIL PROTECTED] | Cc: Cryptography cryptography@metzdowd.com | Subject: Re: Cookie Monster | | On Wed, Sep 17, 2008 at 06:39:54PM -0400, EMC IMAP wrote: | Yet another web attack: | | As I understand the attack, it's this: Cookies can be marked Secure. | A Secure cookie can only be returned over an HTTPS session. An cookie | not marked Secure can be returned over any session. So: If a site | puts security-sensitive data into a non-Secure cookie, an attacker who | can spoof DNS or otherwise grab sessions can send a HTTP page | allegedly from the site that set the cookie asking that it be returned | - and it will be. | | Why on earth would anyone put security-sensitive data in a cookie, | unencrypted? It's the server talking to itself or its siblings, after | all, and it's vulnerable to attack on the client's machine. a) It depends on who you think it has to be secure against. Typical reasoning: If it's effectively the *client's* information, why/from whom do I need to protect it while it's on the *client's* machine? After all, it can only be seen by the client and me. b) The way this attack is actually likely to be used is to steal a logged-in session. If I have the cookie, and can MITM the stream to the server, I can act within the logged-in session. I don't need to be able to decrypt the cookied - the real client has no need to (but in fact there isn't much point in encrypting, while at rest, the nonce that identifies the logged-in session.) I put logged-in session in quotes in agreement with James Donald's message on this subject. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Cookie Monster
Yet another web attack: http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/ Apparently, this one was found and described over a year ago by Mike Perry, who decided to release all the details when there was no significant followup. (Sidejacking was announced at about the same time, and people apparently think the two attacks are the same; but they aren't, and mechanisms to prevent sidejacking generally don't block Cookie Monster.) As I understand the attack, it's this: Cookies can be marked Secure. A Secure cookie can only be returned over an HTTPS session. An cookie not marked Secure can be returned over any session. So: If a site puts security-sensitive data into a non-Secure cookie, an attacker who can spoof DNS or otherwise grab sessions can send a HTTP page allegedly from the site that set the cookie asking that it be returned - and it will be. It turns out hardly anyone bothers to mark their cookies secure. In Firefox, if you list your cookies, you can sort on the Secure field. I only found a couple of cookies marked - mainly from American Express, one of the few sites that gets this right. (Bank of America, for example, doesn't; Gmail with the new HTTPS-only setting does, but other Google services don't.) My own conclusion from this: This is yet another indication that the whole browser authentication model is irretrievably broken. It's just way too complex, with way too many moving parts which can interact in dangerous ways. The list of requirements for a safe Web application - even just based on attacks known today - is so long that no one can remember them all, much less check any substantial Web application to see if it follows them. We need a better approach. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
