1. 7

  2. 10

    All aboard the pre Blackhat hype train! Every year, the same story. Tantalizing tales of dire destruction! Just enough detail to poop your pants, but not so much information that you can do anything more reasonable.

    1. 2

      New attack that cripples HTTPS crypto works on Macs, Windows, and Linux

      At least it doesn’t (yet) have a catchy name, website and logo.

      1. 2

        Without branding, who will we venerate?

    2. 4

      So if I run OpenBSD, am I safe?

      1. 5

        I think so… dhclient doesn’t do anything about proxy settings. Of course, there’s just enough information presented here for a motivated attacker to recreate the attack, but not enough detail to determine who’s safe. I have no idea what Firefox (et al) may do to find proxies all on their own.

        1. 3

          I meant it in a facetious manner, but I’m pleased with this information.

          1. 4

            It gave me another chance to complain, so happy to answer. :)

      2. 4

        This is not a novel attack, nor is it really a concern. URLs have never been considered secure in this decade, and that’s all this shitty attack gets, the URL for the web request.

        This poorly written article is in line with a slew of overblown and ridiculous so-called vulnerabilities these past few months. Whoever wrote that article knows nothing about the tech they’re writing about, and they’re simply spreading fear and lies. This “attack” does not “cripple HTTPS crypto” – it’s not even a cryptographic attack!

        Move along, nothing to see here.

        1. 3

          Well. I partly agree. It seems the attack makes it possible to get to the full request URL, not just the host of the site that is being visited, that was always possible by sniffing DNS or watching for SNI in the HTTPS request.

          If it is possible to see the full URL, and not just the request URL, but also redirects etc. sent by web servers then you can potentially steal e.g. OAuth access tokens. It is a bit hard to judge the impact, but at least it does seem to be a bit of a concern. Especially if one is able to trigger an automatic proxy configuration in Firefox or using DHCP…

          1. 1

            Ah, I’ve just re-read the article and the answer is there - a malicious proxy.pac/wpad.dat file does all the work. Remember that a browser uses the proxy.pac file (which is just Javascript that must contain a FindProxyForURL(url, host) function called by the browser) to determine which proxy to use for each and every URL it wants to visit - it passes in the full URL and the script returns the proxy address(es) to use for that URL. All the malicious script has to do is persist the URL somewhere…

            There are multiple, fairly simple, ways to prevent the attack (not least of which is restricting the subset of Javascript that can be used in a proxy.pac file).

        2. 2

          Here are the presentation and PoC exploit.

          TL;DR - Once the malicious proxy.pac is being used, harvesting of URLs is done with a malicious DNS server (that’s how they get the data out of the sandbox the code is executed in).