In the news this week is talk of a new SSL/TLS attack technique called CRIME. CRIME comes to us from none other than Juliano Rizzo and Thai Duong. If you don’t remember Juliano and Thai, they are the same dynamic duo who won the “Top Ten Web Hacking Techniques” for both 2011 and 2010 for their work on BEAST and the Padding Oracle’ Crypto Attack. Anyway, as the first line of the article says…
“Researchers have identified a security weakness that allows them to hijack web browser sessions even when they’re protected by the HTTPS encryption that banks and e-commerce sites use to prevent snooping on sensitive transactions.”
This looks like their typical stellar research, but I’m not at all familiar enough to comment on the details of this CRIME. My first thought when reading was if an attacker is positioned properly on the network to man-in-the-middle a user, they should be able to accomplish the same outcome using old school HTTP traffic injection techniques and perhaps also some XSS. That’s what I’d like to discuss here.
To establish our scenario, let’s say our victim is on a local coffee shop WiFi, where the attacker is also located and sniffing traffic. The attacker’s goal is to compromise the user account and/or data on https://bank/.
Scenario 1) The victim fires up their favorite Web browser and connects to https://bank/. In addition to the HTTPS requests the browser sends to https://bank/, often requests that are NOT encrypted are sent as well because not every resources on the Web page points to SSL/TLS URLs. This is a common website misconfiguration and when you see those all too common mixed-content SSL warnings.
In this scenario an attacker may simply extract the session cookies for http://bank/ right out of the HTTP packets. From here the attacker can take over their [authenticated] session on https://bank/ leading to account compromise. But, what if the “SECURE” flag was previously set on https://bank/ cookies, which prevents the browser from sending those cookies across the network unencrypted?
Scenario 2) Let’s presume that https://bank/ has no SSL mix-content issues. In this case, if an attacker can intercept ANY plain-text HTTP request sent to ANY location (i.e. http://foo/), they can then inject an IFRAME into the response pointing to http://bank/ or https://bank/, which forces the browser to send those requests.
If https://bank/ is used, this causes an SSL mismatch error. Of course the victim might just click through all the mismatch warnings and shoot themselves in the foot. Yah, it happens. Another cool thing to note about the use of HSTS, the browser does not allow bad certs to be overridden by the user. To prevent the error to begin with we could go into discussing “Double DNS Rebinding,” but let’s not and say we did. It’s a little complicated. 🙂
Then of course if we can assume the attacker possesses an XSS vulnerability on https://bank/, then as @crashsystems says we can’t rule out simply convincing the victim to click on the link with the promise of “cute kittens pics.” For this the attacker doesn’t even need to be on the victim’s network. Email, Twitter, and Facebook will suffice.
Scenario 4) Let’s say https://bank/ is doing everything right. They are using SECURE flag, httpOnly, HSTS, do not have XSS issues, and have in place the necessary protections against Double DNS Rebinding, then.. the next thing they’ve got to worry about is CRIME. Isn’t Web security fun! 🙂
Corrections or amendments from my readers are most welcome.