NewsAugust 8, 2016 @ 10:30 AM

HEIST Uses a Cryptographic Scheme to Steal Data

Black Hat conference attendees got to hear about a HEIST, or how “HTTP Encrypted Information can be Stolen Through TCP-Windows,” during a briefing Aug. 3.

This newly announced attack builds on the shoulders of previous attacks that use a cryptographic scheme to advance their aims. The authors noted in the introduction to their presentation that HEIST allows compression-based attacks such as CRIME and BREACH to be performed directly in the browser with no network access required.

Mechanics of a Cryptographic Scheme

“HEIST abuses weaknesses and subtleties in the browser and the underlying HTTP, SSL/TLS and TCP layers,” the introduction stated. “Combined with the fact that SSL/TLS lacks length-hiding capabilities, HEIST can directly infer the length of the plaintext message.”

HTTP/2 traffic must be immune to this sort of thing, right? Unfortunately, HTTP/2 just makes it worse: The authors noted that “HTTP/2 allows for more damaging attack techniques, further increasing the impact of HEIST.”

Guessing Game

HEIST claims it can make a decent guess as to what the plaintext of a message contains based on the length of an encrypted message. That assertion has not been widely tested yet, though HEIST’s previous methods of crypto extraction were shown to be serviceable.

It makes guesses about the plaintext content using the BREACH method. In this case, however, BREACH methods are not performed in a man-in-the-middle (MitM) situation. The need to manipulate the actual web traffic is eliminated in HEIST, so MitM isn’t necessary for the attack to succeed.

The attack can be triggered simply by a JavaScript file, which may be hidden in an web advertisement or hosted directly on a webpage. The malicious code is able to query a variety of pages that are protected by the SSL or TLS protocols. The code will then measure the precise file sizes of the transmitted encrypted data.

No Cookies for You

One of the attack’s developers told Ars Technica that “the only mitigation [the author] knows of is to disable the third-party cookies, since responses sent by the HTTPS site are no longer associated with the victim. At the moment, most web browsers by default enable the receipt of third-party cookies, and some online services don’t work unless third-party cookies are allowed.”

Just shutting down cookies to avoid individually tagged responses may seriously impair a website’s functionality. If that’s the only mitigation, there are problems aplenty here.

The shift to a network-based attack is ominous. Even in the unlikely event that changes are proposed tomorrow to correct the underlying TCP leaks, it would take a long time to see any effect on most sites. Changes in popular software like TCP take a very long time to propagate.

Someone is going to have to get very smart and figure out a way to blunt this kind of attack — before it leads to a massive problem.

Share this Article:
Larry Loeb

Principal, PBC Enterprises

Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He wrote for IBM's DeveloperWorks site for seven years and has written a book on the Secure Electronic Transaction Internet protocol. His latest book has the commercially obligatory title of Hack Proofing XML. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange.