Modern Browsers Are Undefended Against Cookie-based MITM Attacks Over HTTPS 66
An anonymous reader writes: An advisory from CERT warns that all web-browsers, including the latest versions of Chrome, Firefox, Safari and Opera, have 'implementation weaknesses' which facilitate attacks on secure (HTTPS) sites via the use of cookies, and that implementing HSTS will not secure the vulnerability until browsers stop accepting cookies from sub-domains of the target domain. This attack is possible because although cookies can be specified as being HTTPS-specific, there is no mechanism to determine where they were set in the first place. Without this chain of custody, attackers can 'invent' cookies during man-in-the-middle (MITM) attacks in order to gain access to confidential session data.
Re: (Score:1)
Cookie Ducks are delicious.
Re:Cookies are for cows. (Score:5, Funny)
I think Cookie Monster would like a word with you.
How does injecting a cookie expose data? (Score:2, Interesting)
It's not clear from the article or from the CERT page linked, how the injecting of a cookie exposes data from the secured connection.
Re: (Score:3, Informative)
Read this USENIX paper [usenix.org] for specific implementations demonstrating attacks using this vuln.
Re:How does injecting a cookie expose data? (Score:5, Informative)
Having skimmed through the paper (and with an interest in summarizing some information for the benefit of others here), the problem generally isn't so much that they get access to information stored in the cookies (as per the OP's question above, though it is possible in some cases), so much as it is that they can cause information to be associated with accounts or transactions that they control. Some examples of potential attacks:
Gmail chat logging
The chat window in Gmail's web interface uses different cookies from the main e-mail interface. By replacing those cookies with ones tied to a dummy account under the attacker's control, the attacker can cause a target to log into chat under that dummy account. If the dummy account was made to look seemingly identical to the victim's own (i.e. visually identical username, same friends already added, etc.), the victim would likely be none the wiser, and the attacker would have full access to the dummy account, including the logs that can be enabled in chat settings.
Amazon order hijacking
When a user clicks the "Proceed to Checkout" button, Amazon ties the order-in-progress to identifying information in the user's cookies (but, strangely, NOT to their session ID, which means that the identifying information can be changed without the victim being logged out of their account). By replacing those cookies with their own, an attacker can cause the order-in-progress to be tied to their identifying information, meaning that both the victim's and the attacker's accounts will share access to that order-in-progress. The attacker could then change the shipping address to theirs or could manipulate the data to cause the order to only show up in their account, even though the victim would have paid for it.
Stealing bank withdrawals
When a user on JD.com (a Chinese e-commerce site) wants to add funds from their bank account, they'll enter an amount, click a button to withdraw funds, be forwarded to their bank to authorize the transaction, and then return back to JD with the funds showing up as deposited. If, however, a MITM attacker injects a JD cookie into the victim's browser with their own account information right before the button is clicked, JD will associate the transaction with the attacker's account instead of the victim's, resulting in the withdrawn funds being deposited into the attacker's JD account.
The authors have apparently already developed all three of these attacks on the sites I mentioned, demonstrating that they are quite possible. They listed out a handful of other attacks as well, such as stealing user's browsing history from Amazon, capturing search history from Google, and XSS attacks against eBay, AWS, and Bank of America, among others.
As for how they can inject these cookies, they have two primary means for doing so:
1) Have the ability to create cookies either on the same domain or on a subdomain. E.g. Github apparently used to allow projects to have control over cookies at projectname.github.com, which would have allowed a malicious individual to inject cookies that would carry over into github as a whole.
2) MITM a target so as to inject an invisible iframe that contains the site you want to breach (e.g. Amazon). Hijack the response from the site and replace the Set-Cookie property in the response's header with values of your choosing. This can be done via HTTP, and the cookie will be used in subsequent interactions with the site, including HTTPS sessions.
The latter one is particularly pernicious, since the MITM attacker doesn't even need to be MITM-ing the victim when the victim knowingly visits the site in order to modify the cookies for it. So, for instance, if a cautious laptop user only accesses Amazon from home but likes to visit Starbucks regularly, a MITM attacker at that Starbucks could still inject a new cookie for Amazon while the victim is at Starbucks. When the victim gets home to their secure network, that cookie will be present and will get used, resul
Re: (Score:1)
All-in-all, it's more reason not to connect to unsecure/untrusted networks for ANY reason, since this is a mechanism to compromise not just the sites you visit while on that network, but also any others that you might visit from home or work later.
Or clear your cookies before logging into your bank, Amazon etc.
But yes, it sucks that you have to also do battle with your browser when it is supposed to be your Ally.
Re: (Score:2)
Thanks for the write-up. It clarifies it a lot. But there is something unfair about these examples. You show how this attack could be used against JD.com, amazon.com, or gmail.com -- but only if those sites allowed subdomains. But since they don't offer subdomains, it seems inappropriate to use them even as hypothetical examples. The github example is a good one.
The second means of injecting cookies seems to go without saying. If someone can MITM, then you are screwed. They don't need this attack.
Re: (Score:1)
Thanks for the write-up. It clarifies it a lot. But there is something unfair about these examples. You show how this attack could be used against JD.com, amazon.com, or gmail.com -- but only if those sites allowed subdomains. But since they don't offer subdomains, it seems inappropriate to use them even as hypothetical examples. The github example is a good one.
The second means of injecting cookies seems to go without saying. If someone can MITM, then you are screwed. They don't need this attack.
What do you mean they don't allow subdomains? If you MITM them and insert your invisible iframe, you also MITM the DNS and add a sub-domain that you control.
The point of the attack is to MITM non-https sessions with a subdomain to manipulate future HTTPs sessions. I don't think a MITM quite gets you this particular attach without their exploit.
Re: (Score:2)
What do you mean they don't allow subdomains?
Those domains don't sell subdomains to 3rd partties. I can't go buy a evilhacker.Amazon.com, and evilhacker.gmail.com.
The point of the attack is to MITM non-https sessions with a subdomain to manipulate future HTTPs sessions.
AHhhhhhhhhhhh!!!!!!!! (I didn't read the PDF - just the linked article.) Now that you say this the article makes much more sense. They MITM the HTTP session, set a cookie, that cookie is read by the HTTPS session. The cookie spec was supposed to take that into account since it has flags for secure and not secure. Sounds like the browsers aren't really abiding by that, probably since it
Re: (Score:2)
From what I read in the paper, the browsers are (mostly) abiding by the spec. The problem isn't so much the browsers, so much as it is that the spec's design isn't sufficient, since the "secure" flag merely indicates that the value of the cookie should only be sent over HTTPS, but doesn't specify how it was set in the first place. Since the flag can be set from an HTTP connection, an attacker can set the secure flag over HTTP for a cookie that they provide, which will then be used in subsequent HTTPS connec
Re: (Score:2)
Re: (Score:2)
Completely agree. It seems like a simple fix to the cookie spec, but you can bet that it'll take at least a few months, if not years, for changes like this to get rolled out.
Re: (Score:2)
So, thanks for confirming (although implicitly) that there is absolutely no problem with sites which properly encrypt or sign their cookies ;-)
Re: (Score:2)
Yes and no.
You're quite right that this problem is one that sites can mitigate on their end..."mitigate" being the key word here. That said, it's not something that should be left up to them, since sites are inherently untrustworthy. Cookies should be secure by design and by default, not only after a webmaster jumps through hoops to do things properly. Given that attacks were demonstrated using Google, Amazon, Apple, Bank of America, eBay, and others, it stands to reason that it is not so simple to secure.
T
Re: (Score:2)
... since sites are inherently untrustworthy.
Absolutely true. My comment was from the perspective of a web site developer, not an end user. Site devs need to implement proper signing. Browser devs need to not let information from unsecured channels leak into information that is supposed to be secure. We need both, but the majority of us have no influence over the second one, and so have to focus on the first.
To wit, I'm not sure what good signing by itself would do, since a form of replay attack [wikipedia.org] could still be used.
"Proper" signing must include some reference to account or session or token, which must be validated against the current account or session or t
Re: (Score:2, Insightful)
I believe what the article was saying is that after you have received a cookie, the browser can't tell if it was received via a secure connection or not. Therefore, if you visit another website (specifically one that sets a cookie with the same name), the browser doesn't know which cookie to return upon request from the unencrypted site. More of a guess on my part is that the browser can be made to return both / all cookies with that name, then the site owner can establish a connection to your secure site
Re: (Score:3)
Re: (Score:1)
It also doesn't stop a guy bashing your head in while you wait in line for the bank, then taking all your money.
What I don't understand is how putting a cookie in your online banking website gets you hired for more jobs as a computer programmer when you've demonstrated a total lack of competence.
Re: (Score:2)
Isn't this just private browsing mode?
Re: (Score:2)
Re: (Score:2)
As far as I understand it, destroying evidence requires doing something after evidence has been created, or taking specific steps in anticipation of doing something wrong, not simply as a matter of course.
Re: (Score:2)
It would be easy to establish a GUID within the cookie, that is only good for that cookie/site/session. Generating a fake cookie without the correct GUID for the session would require re-authentication. Easy Server Side fix.
Re: (Score:2)
That seems a little far-fetched (though possible). A more likely attack vector is single sign-on services, where you think you've logged in with your Facebook account somewhere else, but actually you
Re: (Score:2)
1) Found a website with two-pieces, one that remembers/reads credit card numbers, and one that receives submitted card numbers.
2) The user logs in to the website with his account.
3) The website piece that receives credit card numbers gets logged in with someone else's account.
4) One website piece sends the credit card to the other website piece.
5) Retrieve the credit card (probably on the verification page or something).
They didn't go into great
Re: (Score:2)
Haven't read it yet, but I assume it's something like this (below may or may not work, it's an example):
- attacker controls WiFi network
- user visits any HTTP-website
- attacker injects iframe of some other domain for which it wants to attack the user
- the iframe sets a session cookie over HTTP
- later during that browsing session, the user visits the real site over HTTPS
- the browser sends the session cookie it got over HTTP
- the user logs into the site
- the attacker now has a logged-in session cookie of the
Re: (Score:2)
Let us say you and me are using same tax service. I log into the account and inject my cookie in your browser so that it only gets used when you save the return. Now your return gets saved on my name. I can now log into my tax service and can read your tax return.
How to avoid (Score:3, Informative)
If you're concerned about this attack, it can only occur when an "adversary" controls the subdomain of a site, or if you visit the unencrypted, HTTP version of the site while your connection is being man-in-the-middled. Avoid sites that host user content on subdomains, e.g. http://xx_bluntsmoka420_xx.example.com/, and always use the HTTPS version of a site; HTTPS Everywhere helps https://www.eff.org/Https-everywhere
Re: (Score:2)
The trouble is that DNS does not prevent an attacker from faking a subdomain either by a man-in-the-middle or by DNS cache poisoning. You can't prevent your web browser from accessing any non-http url unless you are willing to completely disable http connections from your computer. Any time you visit any web site it can direct your web browser to access an arbitrary, forged, plain text URL. Then, if they have succeeded in executing a MITM against you or managed to poison the DNS caches on your computer,
Re: (Score:1)
Microsoft Edge (Score:1)
Re: (Score:1)
No mention of Edge. Does that mean it's clean?
as recently used latrine!
Re: (Score:2)
It's a problem with the actual implementation of the protocol, so most likely no.
HTTPS-specific cookies and security .. (Score:2)
Re: (Score:2)
Sure, why not? Just keep all the info server side and use some kind of browser fingerprint (I hear battery state queries work) or marketing id to identify you...
Re: (Score:3)
On the server side, if you only use a single cookie as a session ID (securely randomly generated), then you won't read any injected cookies, but this doesn't prevent leaks.
If a subdomain is compromised, say partner.your.bank, then they may read your session ID set by secure.your.bank (and any other cookies) if they can get you to visit the compromised site (e.g. by modifying a regular HTTP request if they're in the middle).
If you append a session ID to every URL, then you don't need any cookies. Attackers w
Re: (Score:2)
Sure with HTML5 there tons of cookie replacements, LocalStorage, WebSQL, IndexedDB. You can even fingerprint the user and track him even if he has everything disabled.
Uh huh... (Score:1)
NSA
Cookies (Score:3)
Cookie self declares path (Score:3)
To mitigate it browsers should present only the cookies set by a site back to that site. This might break lots of sites. It is very common for the sites to set a cookie and then load a page in another domain which reads the cookie. Many authentication schemes depend on this behavior.
Even browsers start authenticating cookie paths or maintain tables of which cookies came from which site and maintain them in different sandboxes, many big sites would not work right.
Re: (Score:2)
They don't. It is amazing how many websites break from just enforcing minimal cookie sanity. In fact the bigger and more mainstream they are, the more likely they are to break due to all the partnerships and interworking systems they based on.
Re: (Score:2)
It's not THAT bad. You can only do this if the site are in the same domain. So foo.example.com and bar.example.com can get/set cookies for example.com. So foo.example.com can "hijack" bar.example.com.
Re: (Score:2)
The path and domain are not authenticated to make sure site A does not set a cookie fraudulently for site B.
These are called "third-party cookies", and browsers (for example, Firefox [mozilla.org]) already have knobs to disable them. That's not the real issue here, however.
Another problem seems to be, the browsers present all the values associated with the name to the web site, even the cookies not set by that site.
Not only that, a site could get cookies set by "parent" and "child" sites. Furthermore, a lot of web-programming languages (including PHP [php.net], ASP.NET [asp.net], Classic ASP, and GWT [gwtproject.org]) expose the cookies as a key-value store where the key is simply the name of the cookie, and don't document which cookie they use if the browser sends multiple ones with the same key. (Java [oracle.com]
On a server side - hash IP + Random UID (Score:3)
Did Google just fix this today? (Score:2)
I noticed that Google pushed out a new update to Chrome (45.0.2454.101 m) just today. I wonder did that update fix this vulnerability.
Re: (Score:2)
I noticed that Google pushed out a new update to Chrome (45.0.2454.101 m) just today. I wonder did that update fix this vulnerability.
No.