Vulnerabilities-Web Application Security

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.



  • Jenny Vingr

    If you are talking about serious important sites, move CRIME to the first scenario.

  • Pingback: Presentation: Practical Attacks on Web Crypto by @webtonull()

  • am06

    In scenario 1 I think you made a mistake:

    doesn’t make sense to me……First you say the secure flag is set and cookies should not be sent on http request, than you say you can steal cookie in the end…..I think ” Javascript is executed on the “bank” domain it can steal cookies (document.cookie)” is wrong in the end.

    • Jeremiah Grossman

      Because Javascript, whether executed in https://bank/ or http://bank/, get’s access to the cookies of both (via document.cookie) — no matter what.

      • am06

        agree, but you said that secure flag is set….So there should be no cookies sent to http, right?

        hmmm… you can still get the cookies from javascript if the secure flag is set and you are in http?

        • am06

          i think it makes sense…..only now i figured that out…..the cookie is not sent over http, you just get access to it on the client using javascript.

      • an_animal

        can you also explain why in scenario 2, if you insert the https iframe, you get invalid certificate error? Won’t it point to the original https website you’re attacking?

  • am06

    then you say:

    “If https://bank/ is used, this causes an SSL mismatch error” . Why?

    • Jeremiah Grossman

      Because in that scenario, the attacker is injecting SSL content (https://bank) into a non-SSL HTTP response. Any time you mix encrypted and non-encrypted content like this causes a mismatch error.

      • an_animal

        aha, good to know…..i thought that it is only the other way arround!

  • Pingback: The perfect CRIME? New HTTPS web hijack attack explained | Technophile()

  • spleeeem

    So if I understand that right, the CRIME attack works by injecting some Javascript that does ever changing requests to https://bank into a http site. And then by looking at how the compression reacts to the change in request it can guess the cookie. But wouldn’t that also give an SSL mismatch error? Unless I guess the attacker had a specially crafted https website with the Javascript and lured the user to that.

  • purificadoras

    It’s nearly impossible to find well-informed people on this topic, but you sound like you know what you’re talking about! Thanks

    • Jeremiah Grossman

      @purificadoras: thank you! I do my best. These subjects can get quite complex and nuanced.

  • shutters toronto

    Great post. I will be dealing with some of these issues as well..

  • chwilowka

    Howdy! Quick question that’s entirely off topic. Do you know how to make your site mobile friendly? My website looks weird when browsing from my iphone4. I’m trying

    to find a template or plugin that might be able to correct this issue.

    If you have any recommendations, please share. Thank you!

  • entertainment

    Hi there! Do you use Twitter? I’d like to follow you if that would be ok. I’m definitely enjoying your

    blog and look forward to new updates.


    hey there and thank you for your info – I’ve certainly picked up anything new from right here. I did however expertise a few technical points using this site, as I experienced to reload the web site lots of times previous to I could get it to load correctly. I had been wondering if your hosting is OK? Not that I am complaining, but sluggish loading instances times will sometimes affect your placement in google and could damage your high-quality score if ads and marketing with Adwords. Anyway I am adding this RSS to my email and could look out for a lot more of your respective fascinating content. Make sure you update this again very soon.

  • vexxhost evaluation

    I’m really impressed together with your writing talents as neatly as with the format on your blog. Is this a paid subject or did you customize it yourself? Either way stay up the excellent quality writing, it’s

    rare to look a great weblog like this one these days..

  • cailleach

    Hey Jeremiah,

    nice article. I was wondering if this kind or a modified type of this attack is still possible nowadays?!

    Regards cailleach