Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 10 submissions in the queue.
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, Troll) by Ethanol-fueled on Friday August 05 2016, @01:43AM

    by Ethanol-fueled (2792) on Friday August 05 2016, @01:43AM (#384336) Homepage

    Saying the word "nigger" is good. Because when you're compromised, who knows what kind of Russians have already sullied your name. That's why you say the word "nigger," to throw them all off. It's a salted hash function.

    It was always the Russian niggers' fault. And they will pay for their crimes with a nuke to the face.

    (Hillary, can I get into your foundation now?)

    • (Score: 0, Offtopic) by Subsentient on Friday August 05 2016, @02:09AM

      by Subsentient (1111) on Friday August 05 2016, @02:09AM (#384351) Homepage Journal

      How many felched cat rectums does it take to puke the gerbil intestines?

      --
      "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
  • (Score: 5, Insightful) by Arik on Friday August 05 2016, @02:03AM

    by Arik (4543) on Friday August 05 2016, @02:03AM (#384348) Journal
    Can anyone remind me the last time there was a known exploit using HTML?

    Or remind me why we gave up the World Wide Web? That was such a promising concept.
    --
    If laughter is the best medicine, who are the best doctors?
    • (Score: 0) by Anonymous Coward on Friday August 05 2016, @03:38AM

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

      Firefox has patched some as late as last month in https://www.mozilla.org/en-US/security/advisories/mfsa2016-50/ [mozilla.org] and all the major browsers have patched at least two this year that allowed arbitrary code to be executed. There have also been major vulnerabilities in the various image parsers as well.

    • (Score: 0) by Anonymous Coward on Friday August 05 2016, @06:22AM

      by Anonymous Coward on Friday August 05 2016, @06:22AM (#384395)

      https://noscript.net/ [noscript.net]

  • (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?

    • (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.

  • (Score: 2) by arslan on Friday August 05 2016, @03:20AM

    by arslan (3462) on Friday August 05 2016, @03:20AM (#384362)

    Am I misreading this? It says HEIST is notable as it does not rely on MITM. All it does is allows the attack to guess the size of payments in the encrypted stream.

    But becomes problematic when used with BREACH which is a MITM attack. So for it to be problematic you have to be able to execute a MITM attack first, in on itself is kinda useless?

    • (Score: 2, Informative) by Anonymous Coward on Friday August 05 2016, @03:50AM

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

      No, it allows you to figure out information in secure connections to server A, but all you need to do it is JS from server B. This JS can come from anywhere, including malvertizing on a completely different tab, with no need for a MITM.

    • (Score: 3, Informative) by Bot on Friday August 05 2016, @07:02PM

      by Bot (3902) on Friday August 05 2016, @07:02PM (#384592) Journal

      The man in the middle is javascript.

      --
      Account abandoned.
  • (Score: 2) by zeigerpuppy on Friday August 05 2016, @04:27AM

    by zeigerpuppy (1298) on Friday August 05 2016, @04:27AM (#384379)

    This seems solvable at the browser level.
    Surely data from each tab should be sandboxed.
    Hopefully it'll prompt browser makers to finally deny 3rd party scripts by default.

    • (Score: 1) by anubi on Friday August 05 2016, @08:03AM

      by anubi (2828) on Friday August 05 2016, @08:03AM (#384415) Journal

      Instead, an end user need only encounter an innocuous-looking JavaScript file hidden in an Web advertisement or hosted directly on a webpage.

      Above documents a glaring omission in the DMCA.

      Along with granting rights to protect content from unauthorized disassembly, along with that should have also assigned liability for what the code does.

      That way, any webmaster insisting on JavaScript being enabled has also agreed to take full liability for it.

      I believe if our Congressmen had the guts to sign such a thing into law, we would see these holes patched damned fast.

      I believe a whittled down JavaScript could be useful, but what we have now is way too powerful to be put in the hands of the general webmaster, some of which have nefarious intention.

      --
      "Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
      • (Score: 4, Interesting) by NCommander on Friday August 05 2016, @11:15AM

        by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Friday August 05 2016, @11:15AM (#384447) Homepage Journal

        It's sickening how much power there is in browser javascript. In a bit of common sense, ECMA decided having browsers open general sockets was a bad idea. They then reimplemented TCP over HTTP in the form of websockets. While WebSockets has its uses, I *really* dislike that someone can my browser to phone essentially any other WS server in existence.

        The WebRTC stuff is even worse since you can get it to leak network configuration information if you know how the specification works. Browsers only request access for mic/webcam, but you can request a data channel without user input, then walk the SIP to get every IP address a machine is associated with, bypassing protections VPNs provide.

        Even SN is not completely immune. While we went through the trouble to make the site work for regular users w/o JS, our admin code is pretty much tied to jQuery for no real good reason. None of us can work up enough damn to strip it out though since it only impacts a grand total of about 10 users.

        --
        Still always moving
    • (Score: 0) by Anonymous Coward on Friday August 05 2016, @04:45PM

      by Anonymous Coward on Friday August 05 2016, @04:45PM (#384527)

      I've been using a different browser for my bank stuff, running as a different user. The browser I use for "normal" browsing also runs as yet another user.

      Neither of these two users are the same as my main desktop user account. My desktop user account has rights to access the files and folders those two browser users own.

      I don't use real-time AV (AV software runs with high privileges but is too bug ridden and exploitable: http://www.theinquirer.net/inquirer/news/2357943/security-researcher-finds-exploitable-flaws-in-14-major-anti-virus-engines [theinquirer.net] http://www.scmagazine.com/vulnerability-found-in-mcafee-kaspersky-and-avg-anti-virus-softwares/article/459241/ [scmagazine.com] http://googleprojectzero.blogspot.my/2016/06/how-to-compromise-enterprise-endpoint.html [blogspot.my] ), I use virustotal if I need to scan stuff.

      Works for me.

      Privilege escalation exploits or other advanced stuff could break through all this, or Microsoft could pwn me, but as the joke/saying goes, I don't have to outrun the bear, I just have to outrun you and millions of other users. If someone really targets me, I'd be pwned anyway, and it might not even be my fault or my security setup but other people's fault:
      https://www.youtube.com/watch?v=bjYhmX_OUQQ&feature=youtu.be&t=2m13s [youtube.com]
      (more here: http://fusion.net/story/281543/real-future-episode-8-hack-attack/ [fusion.net] )

  • (Score: 2) by cockroach on Friday August 05 2016, @11:49AM

    by cockroach (2266) on Friday August 05 2016, @11:49AM (#384456)

    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.

    Does that mean that disabling SSL compression prevents this type of attack?

    • (Score: 0) by Anonymous Coward on Friday August 05 2016, @02:50PM

      by Anonymous Coward on Friday August 05 2016, @02:50PM (#384491)

      if that's the only way to extract the info, then yes. i haven't confirmed that there aren't other ways though. maybe someone else can confirm that?

    • (Score: 0) by Anonymous Coward on Friday August 05 2016, @04:55PM

      by Anonymous Coward on Friday August 05 2016, @04:55PM (#384534)
      Disabling compression should prevent the attack.

      What I wondered was whether adding dummy strings for them to guess could help make things hard enough. But I suppose that just multiplies the difficulty. e.g. three strings = 3x more difficult. So that doesn't really help.
      • (Score: 0) by Anonymous Coward on Friday August 05 2016, @05:33PM

        by Anonymous Coward on Friday August 05 2016, @05:33PM (#384562)

        If you are targeting particular websites, then dummy strings aren't much help. They already know part of the plaintext they want so adding fakes doesn't really help.

    • (Score: 2, Informative) by chair on Friday August 05 2016, @11:58PM

      by chair (6194) on Friday August 05 2016, @11:58PM (#384656)

      In the PDF page 23 they mention disabling compression as a counter-measure, but dismiss it as an incomplete counter measure:

      4.2.2 Disable compression (incomplete)
      HTTP responses are often served with compression (either at SSL level, or using gzip) to
      reduce the required bandwidth. It is a well-known fact that this leads to compression-
      based attack such as CRIME (SSL compression) and BREACH (gzip). Preventing these
      attack from being exploited in the browser can be done in the same way as preventing the
      generic attack, namely by disabling compression. Unfortunately, this does not prevent
      any of the other length-based attacks discussed in this report.

      The same section notes that the only complete counter-measure is disabling of 3rd-party cookies.

  • (Score: 2) by janrinok on Friday August 05 2016, @01:13PM

    by janrinok (52) Subscriber Badge on Friday August 05 2016, @01:13PM (#384469) Journal

    For those that are interested, I found much more information here:

    https://tom.vg/papers/heist_blackhat2016.pdf [tom.vg]

    • (Score: 0) by Anonymous Coward on Friday August 05 2016, @04:25PM

      by Anonymous Coward on Friday August 05 2016, @04:25PM (#384521)
      For those of you for whom that connection failed: directly from blackhat [blackhat.com] and slides [regmedia.co.uk] (aka funny pics), courtesy El Reg. This is big news, people -- comparable to OpenSSL's f*ck*p of 2014.
  • (Score: 1, Informative) by Anonymous Coward on Friday August 05 2016, @01:27PM

    by Anonymous Coward on Friday August 05 2016, @01:27PM (#384472)
    The real issue is a flaw in the design of browser storage mechanisms -- the paper, to be presented at USENIX 2016, will provide a improved design for that, along with viable solutions that can thwart size-exposing attack methods. Both authors, Tom Van Goethem [kuleuven.be] and Mathy Vanhoef [kuleuven.be] have published a couple of other interesting [security] articles (see linky's), like this one [kuleuven.be] around Cloudpiercer [cloudpiercer.org].