In this tutorial, we’ll take a look at how we can hack clients in local network by using WPAD (Web Proxy Auto-Discovery). The WPAD protocol allows automatic discovery of web proxy configuration and is primarily used in networks where clients are only allowed to communicate to the outside world through a proxy. This is true for most enterprise networks where the security is primary concern. Usually, the internal networks are configured so that Internet traffic from clients is disallowed, because such traffic is hard to control. By forcing the users to connect through a proxy, all HTTP traffic can be inspected on application layers for arbitrary attacks, and detected threats can be easily blocked. Since attackers often use HTTPS traffic to circumvent IDS/IPS in such configurations, HTTPS traffic can also be inspected, but that forces the HTTPS sessions to be established from client to proxy and then from proxy to actual HTTPS web server – clients cannot establish an HTTPS session directly to an HTTPS web server.

If we don’t have a web proxy in our internal network and we would like to set it up in order to enhance security, we usually have to setup Squid or some other proxy and then configure every client to use it. If we have many clients, that can be tedious and require a lot of work, which is why WPAD can be used to automate the proxy discovery process, which makes proxy integration into the local network a breeze. Note that the auto discovery option still needs to be turned on in the web browser to enable proxy auto discovery, but using WPAD is still beneficial in case we want to change the IP of the Squid server, which wouldn’t require any additional work for an IT administrator.

Nevertheless, a WPAD protocol is used to enable clients to auto discover the proxy settings, so manual configuration is not needed. All that needs to be done on the clients themselves is enabling the auto-detection of proxy settings. The first part of automatic proxy detection is getting our hands on the wpad.dat file, which contains the proxy settings. There are different methods of how we can discover the wpad.dat file:

Local File: the wpad.dat file can be stored on a local computer, so the applications only need to be configured to use that file.

DNS: usually a wpad string is prepended to the existing FQDN local domain. For example, if a local domain is infosec.local, the actual wpad domain will be wpad.infosec.local, where a GET request for /wpad.dat file will be sent.

DHCP: a DHCP server itself can provide information where the wpad.dat file is stored.

Setting Up Squid

First we have to set up Squid, which will perform the function of proxying the requests from Pfsense to the Internet. In the Pfsense web interface, we first have to go to Packages – Available Packages and locate the Squid packages as presented below. Notice that there are many Squid-related packages available, but we will only install the Squid package (the first one below), since we don’t need advanced features that are offered by the rest of the Squid packages.

After the installation, the Squid proxy configuration is available at Services – Proxy Server. In the General tab, we have to configure Squid appropriately. We have to select the interface on which the proxy will listen, as well as allow users on the interface by checking the checkbox.

For our testing, we have to set up a non-transparent proxy, so the outbound http traffic won’t be automatically passed through the proxy. Since we want to use WPAD, we have to be able to specify our own proxy settings, which is why the transparent proxy mustn’t be enabled. We can also change the proxy port from default port 3128 to 8080 in case we don’t like the default port (or to use security through obscurity to prevent attackers from immediately knowing that a Squid proxy is being used).

Setting up WPAD

The first thing we need to do is create the wpad.dat file, which contains a JavaScript code that tells the web browser the proxy hostname and port. Each web browser that supports WPAD provides the following functions in a secure sandbox environment – all the other functions are prohibited [3].

Let’s write a simple wpad.dat file, which contains the following code that checks whether the requested hostname matches google.com and sends the request to Google directly (without proxying it through the proxy). All the other hostnames will be sent through a proxy available at 192.168.1.0:8080.

That file then needs to be sent to any web server in the internal network and copied to the DocumentRoot of the web server so it will be accessible over HTTP. This can be done with a simple ssh command, but we can also ssh to the box and create the file manually.

# scp wpad.dat myserver:/var/www/

If we’re using Nginx, we also need to create the /etc/nginx/sites-enabled/wpad configuration and tell Nginx where the DocumentRoot of the wpad.infosec.local domain is. Such a configuration file can be seen below and also contains a few logging options in order to simplify the debugging if something goes wrong.

After that we need to create the appropriate DNS entry in the Pfsense, so the wpad.infosec.local domain will resolve to the same web server, where the wpad.dat is contained. We can add the DNS entry by selecting Services – DNS Forwarder in the menu. Then we can add a DNS entry by editing the fields presented below, which are self-explanatory.

After saving the options, we can also check whether the DNS resolution works in the internal network. We can do that with a simple nslookup command as presented below.

Alternatively, we could also specify the settings as follows, which is beneficial if something doesn’t work exactly as it should. This option verifies whether the WPAD works; if it does, then the problem is somewhere in the DNS resolution of the wpad.infosec.local.

After that we can execute the following command on the wpad.infosec.local server to verify whether Firefox is actually able to access the wpad.dat file. In the output we can see that the client from IP address 192.168.1.13 is accessing the wpad.dat file, which is our Firefox browser.

When browsing with the browser after all the configured settings, we can see the logs of the proxy server to check whether the proxy is actually serving the web sites. We can visit www.wikipedia.com and execute the tail command in the Pfsense firewall upon which the following will be displayed, which verifies that www.wikipedia.com is actually being queried by the proxy server.

This verifies that we’ve successfully configured the WPAD protocol, but we haven’t really talked about how to actually use that for the attack. In order to attack the clients on the network, we first have to rely on auto-configuration being enabled in their browsers, which by default is not. Nevertheless, this option is often enabled in enterprise environments, which makes it a possible attack vector. Whenever we’re doing a penetration test of an internal network, we have to check whether proxy auto-discovery is actually being used and setup the appropriate wpad.company.local domain on our laptop to advertise the existence of a proxy server, which is also being setup on our attacker machine. The web browsers resolving the wpad.company.local DNS domain name would then request our malicious wpad.dat, which would instruct the proxies to proxy all the requests through our proxy. At this time we’ll be able to save all the requests and save them into the appropriate file for later analysis.

Conclusion

WPAD auto discovery is often enabled in enterprise environments, which enables us to attack the DNS auto-discovery process. We can do that by setting up a proxy on our attacking machine and instruct all the clients to forward the requests through our proxy, which enables us to save all the requests in a .pcap file. We could also change the responses which are being returned to the user to present different content. There’s a tool that automatically does this and is called responder, so we don’t actually have to set up everything as presented in the tutorial, but it makes a great practice in order to truly understand how the attack vector works. The responder program can be downloaded from the Github page at [4], where the WPAD functionality is being presented as follows:

WPAD rogue transparent proxy server. This module will capture all HTTP requests from anyone launching Internet Explorer on the network. This module is highly effective. You can now send your custom Pac script to a victim and inject HTML into the server's responses. See Responder.conf. This module is now enabled by default.

To use a responder, we simply have to download it via git clone command and run with appropriate parameters. The -i parameter is specifying the proxy IP address, which should usually be our own IP address (in this case it’s 192.168.1.13) and the -w parameter enables the WPAD proxy server.

# ./Responder.py -i 192.168.1.13 -w

Remember that it’s always a good idea to spend a little time figuring how things work in order to gain deeper knowledge about the technology than blindly running the tools in question to execute the attack for us. This enables us to reconfigure the attack vector if responder program doesn’t work as expected, but there are still clients with the WPAD protocol enabled.

Dejan Lukan is a security researcher for InfoSec Institute and penetration tester from Slovenia. He is very interested in finding new bugs in real world software products with source code analysis, fuzzing and reverse engineering. He also has a great passion for developing his own simple scripts for security related problems and learning about new hacking techniques. He knows a great deal about programming languages, as he can write in couple of dozen of them. His passion is also Antivirus bypassing techniques, malware research and operating systems, mainly Linux, Windows and BSD. He also has his own blog available here: http://www.proteansec.com/.

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

− three =

About InfoSec

InfoSec Institute is the best source for high quality information security training. We have been training Information Security and IT Professionals since 1998 with a diverse lineup of relevant training courses. In the past 16 years, over 50,000 individuals have trusted InfoSec Institute for their professional development needs!

Join our newsletter

File download

First Name

Last Name

Work Phone Number

Work Email Address

Job Title

Why Take This Training?

How will you fund your training?

What is your training budget?

InfoSec institute respects your privacy and will never use your personal information for anything other than to notify you of your requested course pricing. We will never sell your information to third parties. You will not be spammed.

Comments

What is Skillset?

Skillset

Practice tests & assessments.

Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready to sit for the test. Along your journey to exam readiness, we will:

1. Determine which required skills your knowledge is sufficient
2. Which required skills you need to work on
3. Recommend specific skills to practice on next
4. Track your progress towards a certification exam