Zer0Byte

Geekiest Techno News

SSL BEAST’s CRIME HTTPS Web Hijack Explained

Continuing from our previous story more details have emerged about Juliano Rizzo and Thai Duong bring us CRIME, a new SSL/TLS attack technique.  CRIME [ Compresison Ratio Info-leak Made Easy] allows secure web browsers used by banks & online shopping sites to be hijacked even when they are encrypted thus capturing those CCD #’s and personal data information associated with it.  CRIME draws a weak web browser into revealing authentication cookie created when a user begins a ‘secure’ session with a site.  Once obtained, cookies can be used by hackers to login into victim’s account on the site.  This is accomplished by fooling the browser into sending compressed encrypted requests for files to a HTTP site and abusing information carelessly exposed in the process.  Malicious Javascript code continually changes the cookie containing encrypted requests and the size of the message is used to figure out the cookie’s contents character by character.

CRIME works on any TLS version that is the underlying technology that secures HTTPS connections.  Unlike Rizzo and Duong’s BEAST attack, CRIME cannot be out maneuvered by web server configuration to allow use of different encryption algorithm.  Browsers used by Punters that allow either TLS or SPDY compression are possibly at risk but the chances only increase if the victim visits a site that accepts the affected protocols.  Support is available but isn’t as universal as we would expect it to be.

Firfox and Chrome are protected as ensured by Google and Mozilla and MS Explorer is not susceptible to the attack only beta versions of OPERA support SPDY.  Although smart phones browsers may stand in the line of fire as per Ars Technica. Rizzo goes on to explain,

“Basically, the attacker is running a script on Evil.com,” Rizzo explained to Kaspersky Labs’ Threatpost. “He forces the browser to open requests to Bank.com by, for example, adding <img alt=””> tags with the src pointing to Bank.com. Each of those requests contains data from mixed sources.”

“The problem is that compression combines all those sources together,” Rizzo added. “The attacker can sniff the packets and get the size of the requests that are sent. By changing the [file name] path, he could attempt to minimise the request size, ie: when the file name matches the cookie.”

http://www.youtube.com/watch?v=gGPhHYyg9r4&feature=youtu.be

But same can be accomplished by using the old HTTP traffic injection route with some XSS as proposed by Jeremiah Grossman.  Grossman offered the following battle plans.

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

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.

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/ orhttps://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.

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.

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!

Dropbox, Github & Stripe have faced brute-forced attacks.  Upon being notified, the organizations suspended sport for the exposed encryption compression protocols. As per the estimation of Ivan Ristic, director of engineering at Qualys, 42% of the sites support TLS compression.

Complete presentation is the main guest of honor at Ekoparty security conference in Buenos Aires, Argentina (aka The Land of Messi!)

 

Categories: Awareness, InfoSec, TOP NEWS