Slashdot Mirror
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.
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
Read this USENIX paper for specific implementations demonstrating attacks using this vuln.
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