Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by 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: (Score:3, Informative)

      by Anonymous Coward

      Read this USENIX paper [usenix.org] for specific implementations demonstrating attacks using this vuln.

      • by Anubis IV ( 1279820 ) on Thursday September 24, 2015 @06:45PM (#50592923)

        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

        • by 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.

        • by MobyDisk ( 75490 )

          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.

          • by 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.

            • by MobyDisk ( 75490 )

              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

              • 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

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

        • by sribe ( 304414 )

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

          • 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

            • by sribe ( 304414 )

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

      by 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

      • by TWX ( 665546 )
        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.
        • by bondsbw ( 888959 )

          Isn't this just private browsing mode?

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

    • 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
      • 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
    • by Lennie ( 16154 )

      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

    • by u19925 ( 613350 )

      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)

    by Anonymous Coward on Thursday September 24, 2015 @04:16PM (#50591867)

    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

    • 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,

  • No mention of Edge. Does that mean it's clean?
    • by Anonymous Coward

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

      as recently used latrine!

    • by SumDog ( 466607 )

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

  • Is there any other way of providing the same functionality without cookies?
    • 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...

    • 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

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

  • NSA

  • by 140Mandak262Jamuna ( 970587 ) on Thursday September 24, 2015 @05:35PM (#50592431) Journal
    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!".
  • by 140Mandak262Jamuna ( 970587 ) on Thursday September 24, 2015 @05:46PM (#50592513) Journal
    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.

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

    • by MobyDisk ( 75490 )

      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.

    • 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]

  • by sinij ( 911942 ) on Thursday September 24, 2015 @08:21PM (#50593437)
    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.
  • 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.

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

Dynamically binding, you realize the magic. Statically binding, you see only the hierarchy.

Working...