Black Hat USA 2016 — HEIST Attack

A great example of how a security vulnerability is exploited outside the realm of its “attack surface”. In this case, the HEIST attack, an acronym for “HTTP Encrypted Information can be Stolen Through TCP-Windows,” is used to target the application’s weak encryption. But not through cryptic and algorithmic means, but by calculating data packet sizes and the transmission gap between each message.

The cryptographic protocol exploited by the HEIST attack is HTTPS, specifically targeting the application’s weak encryption. In the demo, Mathy Vanhoef and Tom Van Goethe ran an attack tool that finds the “tipping point” to sense resource requests that no longer fits the TCP window.[1] Once this is found, a variance of the BREACH and CRIME attack can be executed, which decrypt payloads by manipulating the file compression used by many web sites.
 
 BREACH is an instance of the CRIME attack against HTTP compression — the use of gzip or DEFLATE data compression algorithms via the content-encoding option within HTTP by many web browsers and servers.[2] This attack uses a blind brute-force search to “guess” a few bytes and followed by applying simple arlogrithm to guess large amount of content.
 
 Cryptographic encryption exploit
 
 This attack specifically targets SSL, the underlying cryptographic encryption used by HTTPS. At the heart of the attack is a vulnerability with the TCP protocol and the way encrypted data is transmitted once the HTTPS handshake has been established. In the demo by Vanhoef and Van Goethem,[3] they demonstrated the ability to measure the size of each packets as data is transmitted between the requestor and the provider, the application server.
 
 Knowing the sized of each packet and the transmission gap between each, Vanhoef and Van Goethem were able to apply a divide-and-conquer approach in applying a guessing algorithm to decrypt CSRF tokens, a key element in preventing Cross-Site Request Forgery attack. Once compromised, attackers can initiate attacks using third party sources with malicious scripts. In our previous course discussion, CSRF attacks on a users bank account while the user is unknowingly browsing a malicious site.
 
 Data encryption vulnerability

The type of data encryption demoed in the talk is a data transport attack. It exposes a vulnerability on data exchanges over HTTPS, which comes in a form of data packets. Vanhoef and Van Goethem came up with a way to determine groups of packet sizes by monitoring data exchanges and applying a simple algorithm to measure each request between data packets.
 
 The attack also exploits weak encryption. As demonstrated in the demo, the CSRF tokens were decrypted opening a way to bypass CSRF mitigation and initiate CSRF attack, more specifically BREACH attack, as stated in the talk. HTTP/2 is a highly vulnerable protocol, according to the talk[3], making compression based attacks easy.

Mitigation techniques, my recommendation
 
 According to Vanhoef and Van Goethem, disabling third-party cookies is the best option to prevent a HEIST attack.[3] However, they also pointed out that there is no complete solution to prevent this vulnerability. Any web application is vulnerable. Additionally, disabling compression is recommended warning the audience that this offers “some” mitigation, however, it is not a complete mitigation. 
 
 At the heart of the vulnerability is the ability to determine the window between packet transmission, a core aspect of TCP protocol. In that regard, I would recommend randomizing the TCP congestion window using TCP management tools such as TCP Reno or TCP Vegas.[4] Both offers congestion management capability, which also offers the ability to randomize the transmission window between TCP packets. With randomized window, the HEIST attack will be limited in its ability to determine packet sizes and apply its divide-and-conquer approach in decrypting CSRF tokens.

Further mitigation technique is blocking of 3rd-party cookies. However, given the quoted text below, internet economics rely heavily on third-party cookies.

“Blocking third-party cookies increases user privacy and security but has created a problem for consumer tracking / ad serving firms, which often place ads that follow users around the Web. Mozilla’s decision threatens to make an impact equivalent to the market share of Firefox in their bottom line. Combined with the removal of third-party cookies by other means, some firms estimate that 40 percent of all third-party cookies are removed. Some firms argue that this will affect small business users who rely on third-party consumer tracking and ad serving for revenue.
 
 “As it affects their survival, firms have tried to undermine these changes by using other techniques such as respawning cookies, Flash cookies, entity tags (Etags) and canvas fingerprinting.”
[6]
 
 Based on my own experience, with the social networking content and news magazines I subscribe to, I can see how this is critical in providing targeted content to users. Not just advertising, but personal preferences. Preferences that makes consuming web content more interesting for users. I personally don’t mind advertising that is aligned to my areas of interest such as running and cycling. Even products that I’ve searched for in Google, most recently, backpacks with clamshell-style opening (for an upcoming trip to Europe).
 
 It’s a unique product. And with 3rd-party cookies used by search sites I saw offerings that is relevant to me. Things that interests me, rather than irrelevant advertising.
 
 Having viewed the talk by Mathy and Tom, I now have doubts on the benefits of third-party cookies. Given the risks and privacy associated with it I can see web providers abusing this valuable privilege. Selling users browsing activities and data is a privacy concern, at least for me. 
 
 This is relevant because the discussion talk’s mitigation approach to the HEIST attack, a very serious vulnerability, is turning off third-party cookies. So I’ll be turning them off moving forward, and will observe any impacts in my web surfing activity, if any. I will let you all know.
 
 (I am posting this in Mozilla Firefox with third-party cookies turned off.)

REFERENCES
 [1] Vanhoef, M., Van Goethem, T. Youtube.com. Black Hat 2016 Conference, HEIST. https://www.youtube.com/watch?v=GwQsu8dGSeA. Accessed Jul-14–2017.
 [2] Wikipedia Article. https://en.wikipedia.org/wiki/BREACH. Accessed Jul-14–2017.
 [3] Vanhoef, M., Van Goethem, T. Youtube.com. Black Hat 2016 Conference, HEIST. https://www.youtube.com/watch?v=GwQsu8dGSeA. 40:38. Accessed Jul-14–2017.
 [4] OWASP. Sites.google.com Article. https://sites.google.com/a/owasp.org/nitin-arya/heist-steal-information-from-any-secure-website-tls-broken-again. Accessed Jul-14–2017
 [5] Loyola University, Chicago Article. http://www.lcu.edu. http://intronetworks.cs.luc.edu/current/html/reno.html. Accessed Jul-14–2017.

[6] Techtarget.com. Article. http://whatis.techtarget.com/definition/third-party-cookie. Accessed Jul-14–2017.