Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Friday August 05 2016, @01:27AM   Printer-friendly
from the inherently-insecure dept.

The HTTPS cryptographic scheme protecting millions of websites is vulnerable to a newly revived attack that exposes encrypted e-mail addresses, social security numbers, and other sensitive data even when attackers don't have the ability to monitor a targeted end user's Internet connection.

The exploit is notable because it doesn't require a man-in-the-middle position. Instead, an end user need only encounter an innocuous-looking JavaScript file hidden in an Web advertisement or hosted directly on a webpage. The malicious code can then query a variety of pages protected by the secure sockets layer or transport layer security protocols and measure the precise file sizes of the encrypted data they transmit. As its name suggests, the HEIST technique—short for HTTP Encrypted Information can be Stolen Through TCP-Windows—works by exploiting the way HTTPS responses are delivered over the transmission control protocol, one of the Internet's most basic building blocks.

[...] "HEIST makes a number of attacks much easier to execute," Tom Van Goethem, one of the researchers who devised the technique, told Ars. "Before, the attacker needed to be in a Man-in-the-Middle position to perform attacks such as CRIME and BREACH. Now, by simply visiting a website owned by a malicious party, you are placing your online security at risk."

Using HEIST in combination with BREACH allows attackers to pluck out and decrypt e-mail addresses, social security numbers, and other small pieces of data included in an encrypted response. BREACH achieves this feat by including intelligent guesses—say, @gmail.com, in the case of an e-mail address—in an HTTPS request that gets echoed in the response. Because the compression used by just about every website works by eliminating repetitions of text strings, correct guesses result in no appreciable increase in data size while incorrect guesses cause the response to grow larger.

[Continues...]

[...] To determine the size of an HTTPS-protected response, the attacker uses an oracle technique that returns what amounts to a yes-or-no response to each guess. When a request containing "value=" results in the same data size, the attacker knows that string is inside the encrypted response and then tries to modify the guess to include the next character, say "value=0". If that guess results in a larger file size, the attacker knows it's wrong and will try "value=1", "value-=2", and so on until the new guess similarly results in a response that shows no increase in file size. The attacker then tries to guess the next character and repeats the process until the entire token has been recovered.

HEIST is able to count the number of frames and windows sent by interacting with a set of newly approved APIs, one called Resource Timing and another called Fetch. In the process, they allow a piece of JavaScript to determine the exact size of an HTTPS response. The malicious HEIST code then works in tandem with BREACH to ferret pieces of plaintext out of the encrypted response by adding thousands of guesses to requests and analyzing the size of each resulting response.

[...] Van Goethem said the only mitigation he 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.

HEIST is also effective against HTTP/2, the drop-in replacement for the older HTTP standard that encrypts all Web traffic. In some cases, HEIST can abuse new features of HTTP/2 to increase the damaging effects.

"If we know that HTTP/2 is used, we can let the browser simultaneously request the targeted resource, and another resource that contains reflected content," Vanhoef and Van Goethem wrote in a research paper that has not yet been published. "Since HTTP/2 is used, both requests are sent in parallel to the server, and the server replies to them in parallel as well."

[...] "Regardless of the typical security measures taken by websites, most of them will remain vulnerable to BREACH (the attack has been around for three years, and nothing has been done to mitigate it—most likely because it's far from trivial to do so)," he wrote in an e-mail. "Combined with the fact that the only requirement for HEIST is that a victim simply has to visit a (malicious) website, we consider it likely that attacks such as BREACH over HEIST will become the easiest way to compromise accounts."


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Friday August 05 2016, @02:21AM

    by Anonymous Coward on Friday August 05 2016, @02:21AM (#384354)

    Is this a TCP window, or Windows TCP? In otherwords, is this a Microsoft only exploit?

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 1, Informative) by Anonymous Coward on Friday August 05 2016, @03:44AM

    by Anonymous Coward on Friday August 05 2016, @03:44AM (#384373)

    It is a TCP window, meaning every browser with the proper JS API support is vulnerable, regardless of platform.