Modern Browsers Are Undefended Against Cookie-based MITM Attacks Over HTTPS

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.

Comments

How does injecting a cookie expose data?

[Anonymous Coward]

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:How does injecting a cookie expose data?

[Anonymous Coward]

Read this USENIX paper for specific implementations demonstrating attacks using this vuln.

Re:How does injecting a cookie expose data?

[Anonymous Coward]

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 as you if the stolen cookie is your authenticated session ID for that (secure) site.

Quick solution (assuming the above is correct): Connect to your bank / site with incognito/private sessions and don't browse other things until you finish your transaction and close the session (which would purge the cookies).

Re:How does injecting a cookie expose data?

[Anonymous Coward]

There's a paper if you're interested in the details.

Re:How does injecting a cookie expose data?

[TWX]

My solution that I've used for a decade is to clear all of everything when the browser gets closed and to not cache anything to disk. I'm on a computer with 8GB RAM and a high-speed Internet connection; my setup is more than capable of caching to RAM everything that I'll need for the next few minutes and quickly downloading that which needs to be retrieved over longer timescales.

Re:How does injecting a cookie expose data?

[Archangel Michael]

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:How does injecting a cookie expose data?

[Anonymous Coward]

Actually I've found not caching to disk and reloading from the web instead to be faster, at least if the cache would reside on a spinning disk. Plus the tens of thousands of small cache files are a headache for AV scanning and backups. Disk cache off.

Re: How does injecting a cookie expose data?

[Anonymous Coward]

Exactly! When opening your browser use a script. When the browser closes delete... Works great for me. Now I just need to make one for Android.

Re:How does injecting a cookie expose data?

[Anonymous Coward]

That doesn't stop an attack performed during one browser session.

Re:How does injecting a cookie expose data?

[Anonymous Coward]

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:How does injecting a cookie expose data?

[phantomfive]

The clarifying example for me was google chat. Gmail has a google chat window, which is actually loaded from a different URL and composed together on the page. Using that, the attacker can inject the cookie for a different chat account. The user thinks he is on his own page, but is chatting with someone else.

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 signed in with someone else's account. Using that technique, they were able to steal money from payment services.

So the cookie itself is not a vulnerability, but combined with slightly careless coding, it can give an attacker an entrance.

Re:How does injecting a cookie expose data?

[phantomfive]

To steal a credit card this is what they did (AFAICT):

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 detail on that example, but that is my understanding of the situation.

Re:How does injecting a cookie expose data?

[Anonymous Coward]

Not sure how the volatility of your session affects a cookie injection attack. They aren't just used for storage between sessions. In fact their persistence is secondary to their use in current active sessions (even those stored entirely in volatile ram).

One of us is missing something here...?

Re:How does injecting a cookie expose data?

[bondsbw]

Isn't this just private browsing mode?

Re: How does injecting a cookie expose data?

[Anonymous Coward]

Didn't they recently determine that is "destroying evidence" even if they can't prove there was "evidence" there to begin with?

Re:How does injecting a cookie expose data?

[Lennie]

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 user for the site

Something a long those lines...

Re:How does injecting a cookie expose data?

[Anubis IV]

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: How does injecting a cookie expose data?

[TWX]

I've configured every single browser on every computer that I've used with any regularity for the last decade this way, as my first order of business when I use it for the first time, and I've configured browsers for others the same way.

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:How does injecting a cookie expose data?

[TWX]

Private browsing mode did not exist when I started doing this.

Re:How does injecting a cookie expose data?

[u19925]

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.

Re:How does injecting a cookie expose data?

[Anonymous Coward]

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:How does injecting a cookie expose data?

[MobyDisk]

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:How does injecting a cookie expose data?

[Anonymous Coward]

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:How does injecting a cookie expose data?

[Anonymous Coward]

It's not a fake cookie. It's a valid cookie transplanted into a different browser session.
Currently there's no way from the server side to know whether something is the same session or not without significant inconvenience.

That said, TLS channel id is coming, and when that's really available, that can prevent (or at least make it significantly more difficult) all cookie transplant like this.

Re:How does injecting a cookie expose data?

[MobyDisk]

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 used to be more common to mix HTTP and HTTPS.

Re:How does injecting a cookie expose data?

[sribe]

So, thanks for confirming (although implicitly) that there is absolutely no problem with sites which properly encrypt or sign their cookies ;-)

Re:How does injecting a cookie expose data?

[Anubis IV]

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 connections.

And as AC said, the MITM attack doesn't rely on Amazon or Google having subdomains open to individuals. The MITM attack relies on intercepting an HTTP response from Amazon or Google and replacing the Set-Cookie header property with something that the attacker chooses instead. That value will then be used in the later HTTPS communications.

Until either the spec for cookies is amended or domains can be locked down to ONLY accept HTTPS connections (which HSTS is insufficient for, as the authors discussed), it will continue to be possible to engage in these sorts of attacks.

Re:How does injecting a cookie expose data?

[Anubis IV]

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.

To wit, I'm not sure what good signing by itself would do, since a form of replay attack could still be used. All they'd need to do is intercept and replace the Set-Cookie property that you got back from Google or whoever with their own valid Set-Cookie property that they separately got back from Google. You'd end up with valid, signed cookies from Google, but the cookies would contain data referencing the attacker. Given that that's how all three of the attacks I outlined above functioned, we can say that signing, by itself, may not do you much good.

Likewise, encryption by itself doesn't necessarily do you any good, since it too can be replayed to the same effect. To implement signing and/or encryption in a sufficient manner, you'd additionally need to establish a proper authentication protocol, but at that point we're basically just reinventing the wheel, since that's what TLS and HTTPS are for, and the whole point of this attack is that HTTPS isn't ubiquitous, cookies are flawed by design (since they allow values that can only be read over secure channels to be written to from insecure ones), and that the lack of ubiquity can be exploited.

Re:How does injecting a cookie expose data?

[sribe]

... 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 token. Granted, there's tricky corner cases, but "still logged in as John Smith, but my transfer goes to Jane Doe" is pretty basic to prevent.

Re:How does injecting a cookie expose data?

[Outtascope]

So I was going to go all "what a bunch of bu..." on this, but your point about being able to set the secure flag from a non-secure connection makes the issue clear. This seems a rather easy fix for the browsers, refuse any cookie that has the secure flag set if it is being set over http. I'm actually astounded that this isn't the default behavior, I had always assumed it was. If this change breaks anything, well tough. You don't want to visit a site that is saving something "secure" over plain http anyway.

Re:How does injecting a cookie expose data?

[Anubis IV]

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.

How to avoid

[Anonymous Coward]

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:How to avoid

[RatherBeAnonymous]

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, your router, or your ISP's DNS server, they can set a cookie and use it hijack browser sessions. HTTPS Everywhere should help, provided that all of your financial institutions are supported. DNSSEC would help as well because it requires DNS responses for protected zones to be digitally signed.

Re:Cookies are for cows.

[SeaFox]

I think Cookie Monster would like a word with you.

Re:All about Cookie is good

[jonbally7631]

I want to know how to get the code from HTTPS and it is really sounds crazy man !

Microsoft Edge

[ddtmm]

No mention of Edge. Does that mean it's clean?

Re:Microsoft Edge

[Anonymous Coward]

No mention of Edge. Does that mean it's clean?

as recently used latrine!

Re:Microsoft Edge

[SumDog]

It's a problem with the actual implementation of the protocol, so most likely no.

HTTPS-specific cookies and security ..

[nickweller]

Is there any other way of providing the same functionality without cookies?

Re:HTTPS-specific cookies and security ..

[The-Ixian]

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:HTTPS-specific cookies and security ..

[nullchar]

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 won't read anything if you visit a compromised site, and your server will ignore any injected cookies.

Of course, make sure all your services are only available over HTTPS (HTTP -> HTTPS redirects, which everyone uses, are not safe from MITM attacks if you use cookies).

Re:HTTPS-specific cookies and security ..

[Carewolf]

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.

Re:HTTPS-specific cookies and security ..

[Anonymous Coward]

Cookies are mainly used for storing a session identifier. Transferring the cookie on the wire (encrypted or not) is unsafe since public cryptography discovery.

Want secure session handling then use public crypto:

1. Negotiate a ephemeral key (DH and others)
2. Use message authentication code to sign the every piece of communication

Or, just use client certificate in a bi-directional context.

Re:Cookie is required for browser

[bigfinger76]

I haven't been able to decipher any of your posts.

Uh huh...

[koan]

NSA

Re:Cookie is required for browser

[axlworldstore]

Of course about that you really getting bore us brother. Browser cookie is a best stuff to crack a login access

Cookies

[140Mandak262Jamuna]

Yes, it is not encouraged much in slashdot, but still I clicked on the link provided in the summary to, gasp!, read the fine article. That site popped a banner that said, "This site is using cookies to improve your web experience!".

Re:Cookies

[Anonymous Coward]

Do you have a point, numbnuts?

Re:Cookies

[Anonymous Coward]

Yes and guess what I saw in the supermarket today? Cookies! Rows of them! Will they never learn?

Cookies are for chickens

[Anonymous Coward]

You are all chickens. Chickens say cluck. CLUCK! CLUCK! Cluck chickens CLUCK! Cluck says the chicken. YOU COOKIE CHICKENS!!

Re:Cookies are for chickens

[Anonymous Coward]

You are all ducks. ducks say quack. qqqquack! QQQQUACK! Quack duck QQQQUACK! Quack says the duck. YOU COOKIE DUCK!!

Re:Cookies are for chickens

[davester666]

Cookie Ducks are delicious.

Cookie self declares path

[140Mandak262Jamuna]

According to the article, per my understanding, the cookie is stored as a name-path-domain to value map. The path and domain are not authenticated to make sure site A does not set a cookie fraudulently for site B. 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.

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:Cookie self declares path

[Carewolf]

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.

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:Cookie self declares path

[MobyDisk]

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:Cookie self declares path

[lamber45]

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) 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, ASP.NET, Classic ASP, and GWT) 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 is a bit better, it just exposes a bucket, but that's harder to work with.)

How to avoid this while developing

[Anonymous Coward]

Cryptographically sign your cookies based on hashing it combined with a secret only the server knows.

e.g. signed_payload = hash(secret + hash(secret + cookie_payload))

Then it doesn't matter whether the cookie is set on the insecure bit, or the secure bit, or by random attackers. You simply verify the cookie before you trust it. If it wasn't signed with the secret, it ain't safe.

This still gets you all the niceties of cookies, but you use a wrapper function that tests the signature on the cookie before it is used.

This is not new stuff.

Re:How to avoid this while developing

[Anonymous Coward]

Actually, I suppose there's still a man-in-the-middle thing in certain circumstances, because there could, just about, be a way to exploit this by tricking a browser to use a _different_ signed cookie (e.g. to commit changes to the attacker's account instead). Obscure, but feasible.

On a server side - hash IP + Random UID

[sinij]

On a server side - hash IP + Random UID, then challenge cookie with every important request. Very hard, but not impossible to defeat. If you want perfect protection - implement TLS session binding.

Did Google just fix this today?

[MtViewGuy]

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:Did Google just fix this today?

[dotancohen]

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.

Already known?

[Anonymous Coward]

Sorry, am I missing something? These vulnerabilities are plainly obvious in the specs. Am I really the only one who knew this?

The only thing that really surprises me is that big names like Google and Amazon have known vulns of this kind...

Ironic?

[Anonymous Coward]

That page asks me to allow cookies.....