How to CRIME without CRIME

 

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?

In this case, an attacker may insert some [malicious] Javascript content into the HTTP response of one of the plain-text requests. Particularly attractive are requests initiated from SCRIPT or IFRAME tags. Since this Javascript is executed on the “bank” domain it can steal cookies (document.cookie), hijack a users authenticated session, compromise account data, send authenticated requests the victim did not intend, and so on.

Another roadblock for the attack might be if https://bank/ set their cookies with the httpOnly flag, which prevent Javascript from reading document.cookie. Its true, the attacker is prevented from getting the cookies, but everything else is still possible in Javascript space, including simply popping up an authentic looking https://bank/ dialog asking for their username and password. Standard phishing attacks, hosted on https://bank/, apply.

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 http://bank/ is used, the attacker may inject Javascript into the response, which brings us back to scenario #1, complete with the ascribed capabilities and restrictions. If however a previous visit to https://bank/ set an HSTS header, the browser will not issue http://bank/ requests even when instructed to.

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. 

Scenario 3) Similar, but not identical to #2. Victim’s browser connects to ANY unencrypted website (i.e. http://foo/), where the attacker subsequently injects an IFRAME into the response pointing to an XSS URL for https://bank/. This obviously presumes the attacker has identified an XSS issue beforehand, which at 55% of websites is still very common. At this point the attackers Javascript is auto-executed from the XSS attack and operates under https://bank/. Back to the scenario #1 and most likely full account takeover.

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.