Shhh! Everyone loves a good secret, and in this tutorial, we will show you how to capture a few of them using Web Proxy Auto-Discovery (WPAD). WPAD is a proposed Internet protocol which allows a client (in this case we use a Web browser) to automatically locate and interface with cache services in a network.
The Set Up
For this session, we will work with a typical Windows 10 installation. As it’s an enterprise environment it is very likely that auto-proxy discovery is enabled even if the actual proxy is not deployed.
This is a very common configuration, which we can verify by going through internet settings into internet options, then connection LAN settings, and checking if the ‘automatically detect settings’ checkbox is ticked.
If the checkbox is ticked, then software which supports proxies (so all modern browsers) will use those settings unless they are explicitly overwritten in browser settings. This means that WPAD (Web Proxy Auto-Discovery Protocol) will be used to determine proxy settings.
The settings are stored in a special file and the location of that file is automatically determined. You could also specify the location manually by checking the option ‘Use automatic configuration script’ or by using the proxy server explicitly.
In this tutorial we want to pass the auto-configuration, so we will leave the ‘Automatically detect settings’ option on.
For this tutorial, we could use any browser, but we’ve chosen Google Chrome because it offers some nice features regarding network settings. We will be working with the real internals of the configuration so make sure you know what to do before you start editing something!
In the proxy, we can see the original proxy settings as well as the effective proxy settings. Currently, the direct connection is in use meaning no proxy was detected.
We will start by going to the Capture and selecting Reset. Then, we go into Proxy and click ‘Re-apply settings’ to ensure that from this point on, all new captures are recorded.
Now if we go to Capturing Events we can see that the WPAD event has recorded. There are an exact time and date for that event and we can see that no settings were found, and no PAC file was found so the event was canceled.
If we go to Proxy, we can see that no proxy settings were changed which is why the settings are listed as ‘Use DIRECT connections’.
Do I Smell a Network?
Now we are going to open Wireshark – a network sniffer which we will cover in detail in an upcoming episode of Hacks Weekly (so keep an eye out for that). In this tutorial, we will use Wireshark to capture the few requests for WPAD.
I will be listing on the ethernet interface. Come with me as we switch browsers back to Chrome and click on the ‘Re-apply settings’ button again in Proxy.
I’ve stopped the capture and you can see the 100.1 IP is this computer address. Keep this in mind as we will be using that IP later.
What Protocols are Involved?
There are several protocols involved:
- Multicast DNS
- LLMNR (Local Link Multicast Name Resolution Protocol)
- NBNS which stands for NetBIOS
Sometimes you can even find DNS query over here. What that means is that WPAD has a lot of backup options! There are even DHCP options to find out the proxy settings. These are the defaults but what you find in your configuration depends on system settings.
As we can see no-one is responding to those queries and no proxy settings are detected but what would happen if someone responded? To find out let’s switch to another machine with Kali Linux.
This Kali Linux is located on the same network. It could be a corporate network or just the same WIFI network, maybe free WIFI. It has a static IP and the same subnetwork.
Now I’m going to use a tool called Responder which is installed by default in the Kali Linux. I have already done some modifications to the conflict file: Only HTTP service in enabled because we are going to use that to serve our malicious WPAD file. Scroll down and in the same file below you will find the Custom WPAD Script itself.
Run Responder tool with minus A option which is a special mode in which messages are analyzed but no actual interruption of the traffic takes place. We have to specify the name of the interface.
Most of the services are disabled and we are already poisoning all the messages that we saw earlier. We could wait for new events to occur but let me speed things up and switch to Windows system.
In Windows, I could just click the ‘Re-apply Settings’ button again but instead, I am going to show you how relaunching the browser will also generate the result we want. Now the Kali should already see at least three requests, one for each protocol for WPAD server, and I can also show you that we currently have communication. If we try HTTP you can see we have a connection to an external webpage.
Now if you look at the Kali you will see a lot of queries and you can also see the WPAD in the DNS. There’s also LLMNAR requests for WPAD and so on. But still, we are not responding to those right? So, let’s change that.
Close the Responder and open up Burp Suite and set it up to capture the traffic on the interface that we are listening to (There is a Hacks Weekly episode on Burp Suite so make sure you watch that as well to find out what else you can do with Burp).
For now, we are going to change a configuration of the proxy because we need to specify the correct interface by defaulted listens on the local hosts only. This means that I want to go to the Proxy tab, and then the Options tab. We want to edit that and use a specific address in that network and that’s it. I don’t really want to intercept anything so let’s just switch to the HTTP history window and Burp is ready.
Next, we want to modify the common line and remove this minus A option. Now we are in the actual attack mode so let’s go the Windows again and go to our example com. It looks like nothing has happened because we got the same page, but let’s go to the Kali and see if we managed to capture some traffic.
What Really Happened?
In the Kali, you can see that Responder actually poisoned the answers for all of the requests. We can also see that there was an HTTP request for proxy configuration coming from the Chrome browser, and this is very likely our victim.
By looking at what Burp managed to capture we can see that these requests to example.com were actually recorded and we have a full view into what data was transferred. All the other requests generated by Chrome itself can be captured.
We could enable intercepting just to modify the traffic in some way but instead of playing with Burp itself let’s try to analyze the attack again.
Restart Responder and go into Windows so we can see what the Wireshark and the Google internet are showing. I’m going to open the browser and go back into the internals again where I’ll reset the capture and re-apply the proxy settings.
If we go to Capturing Events now we can look up the WPAD job. This time we have five entries and we can see that this time, the requests succeeded, and someone responded.
We are going to investigate the WPAD file manually using the files that the Kali will respond to – the WPAD hostname – and we can download the configuration script by just using a notepad to open that file. The problem is that this is a one-liner, so we need to fix the formatting here by creating new lines for each ‘if’.
The logic is that if the browser tries to access the local host or something that resembles the local host it will be “DIRECT”. If the browser tries to access something that is called proxy server – part of the configuration for Responder – it also goes direct. For anything else, there is a special proxy.
There is a backup option which means that if we disable the Burp, the browser will simply use the other option. The attack will not be easily detected because the browser will be smart enough to just go direct anyway and no loss of connection will occur.
There is a very handy reference to what you have available in case of the PAC script, and there are a bunch of functions available to use when you are creating your own configuration. I wanted to point out this function dnsResolve that you can use to resolve the hostname so that you can operate on the IP addresses instead of the host names.
The issue is that if there is a malicious WPAD in place and the attacker is also controlling the DNS server then by doing those requests some part of the information is leaked to the DNS server itself. So, keep in mind that there are some ways of stealing information using the WPAD file.
Also, there are some ways of limiting the days or dates when the proxies are actually working which is also interesting to know. If we go to Wireshark we can see that there were some requests to Multicast DNS and other protocols just as before, but this time someone actually responded. We can see by looking at the IP that this is our Kali system because of dot 5 IP. Kali was kind enough to hijack all of those requests and respond to every single query so that later when the browser asked for the WPAD script, it was served from our Kali system.
One of the things that are often misconfigured when serving a WPAD file is that it doesn’t have the valid content type. It has to be the content type ‘application/x-ns-proxy-autoconfigrn’ and nothing else. If your enterprise configuration is using the proxy but this particular thing is misconfigured, your proxy will not work anyway as someone still might be able to hijack your communications.
As you can see, playing with proxy might be dangerous so if you don’t need this feature then just use GPO or something similar to disable the setting across all the devices. If you need auto-discovery to make sure you understand where the system searches for WPAD configuration, which ones are preferred and so on.
It is also important to make sure that all the browsers in the environment are modern browsers because if the browser’s a few years old then there will be certain issues with the WPAD. For instance, one was able to recover the URL part of otherwise encrypted communication and also there was a pretty huge vulnerability in the old implementation for Internet Explorer so by using WPAD someone could actually own your own entire system.
Thank you for your attention. See you in the next episode of Hacks Weekly.