Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the never-ends-does-it? dept.

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.

11 of 66 comments (clear)

  1. How does injecting a cookie expose data? by Anonymous Coward · · 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.

    1. Re:How does injecting a cookie expose data? by Anonymous Coward · · Score: 3, Informative

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

    2. Re:How does injecting a cookie expose data? by Anonymous Coward · · 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 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).

    3. Re:How does injecting a cookie expose data? by TWX · · Score: 2

      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.

      --
      Do not look into laser with remaining eye.
    4. Re:How does injecting a cookie expose data? by Anubis+IV · · 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

  2. How to avoid by Anonymous Coward · · 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

  3. Re:Cookies are for cows. by SeaFox · · Score: 4, Funny

    I think Cookie Monster would like a word with you.

  4. Re:HTTPS-specific cookies and security .. by nullchar · · Score: 2

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

  5. Cookies by 140Mandak262Jamuna · · Score: 2

    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!".

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  6. Cookie self declares path by 140Mandak262Jamuna · · Score: 2
    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.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  7. On a server side - hash IP + Random UID by sinij · · Score: 2

    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.