The perfect CRIME? New HTTPS web hijack attack explained
BEASTie boys reveal ingenious login cookie gobble
More details have emerged of a new attack that allows hackers to hijack encrypted web traffic - such as online banking and shopping protected by HTTPS connections.
The so-called CRIME technique lures a vulnerable web browser into leaking an authentication cookie created when a user starts a secure session with a website. Once the cookie has been obtained, it can be used by hackers to login to the victim's account on the site.
CRIME (Compression Ratio Info-leak Made Easy) was created by security researchers Juliano Rizzo and Thai Duong, who cooked up the BEAST SSL exploit last year. CRIME works on any version of TLS, the underlying technology that protects HTTPS connections. The number of requests an attacker would need to make to pull off the hijack is fairly low - up to six requests per cookie byte. Unlike the BEAST attack, CRIME can't be defeated by configuring the web server to use a different encryption algorithm.
Punters using web browsers that implement either TLS or SPDY compression are potentially at risk - but the vulnerability only comes into play if the victim visits a website that accepts the affected protocols. Support is widespread but far from ubiquitous.
The researchers worked with Mozilla and Google to ensure that both Firefox and Chrome are protected. Microsoft's Internet Explorer is not vulnerable to the attack, and only beta versions of Opera support SPDY. Smartphone browsers and other applications that rely on TLS may be vulnerable, according to Ars Technica.
"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."
Each encrypted request includes an image file name - a constantly changing detail that is generated by the malicious script; the browser's identification headers, which don't change; and the login cookie, the target of the attack. When the file name matches part of the login cookie, the size of the message drops because the compression algorithm removes this redundancy.
"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."
This brute-force attack has been demonstrated against several sites including Dropbox, Github and Stripe. Affected organisations were notified by the pair, and the websites have reportedly suspended support for the leaky encryption compression protocols. Ivan Ristic, director of engineering at Qualys, estimates 42 percent of sites support TLS compression.
The researchers will present their work at the Ekoparty security conference in Buenos Aires, Argentina next week. In the meantime, Jeremiah Grossman, founder and chief technology officer of WhiteHat Security, has a detailed take on the attack here. ®