BlackHat2016: badWPAD – The Doubtful Legacy of the WPAD Protocol

WPAD is a protocol that allows computers to automatically discover Web proxy configurations and is primarily used in networks where clients are only allowed to communicate to the outside world through a proxy – which is the case in most enterprises. To easily configure proxy settings for different types of applications which require an internet connection, WPAD, also known as “autoproxy”, was first implemented and promoted by Netscape® 2.0 in 19961 for Netscape Navigator® 2.0. The tool can apply to any system that supports proxy auto-discovery, like most browsers, operating systems and some applications not working from operating systems.

Warnings of security issues have been around for many years. These risks have been recognized in the security community for years, but for some reason been left largely ignored. In fact it is relatively easy to exploit WPAD. In basic terms, the security issue with the WPAD protocol revolves around the idea that whenever the protocol makes a request to a proxy, anyone else can create a service that answers that request and can practically impersonate the real web proxy (Man-in-the-Middle attack).

Figure 1. Simple attack setup at the local level

The WPAD protocol has thus been around for almost 20 years but still bears inherent risks. This sparked our interest and prompted us to carry out a few experiments of our own to test the potential promise WPAD holds for an attacker. The results that our experiments yielded, did leave us quite surprised and make us firmly believe that WPAD is in fact badWPAD.

Our experiments involved testing the applicability of WPAD through different local and/or public networks. During our research period between October 2015 and January 2016, we collected data in the form of log files. In the course of analyzing the user-agent strings, we made a few interesting findings. We carried out a number of experiments with WPAD on several public and private (Trend Micro’s own domain) networks. In all cases, an empty wpad.dat file was served to any connection request, so no user connection was actually relayed or tampered with. The beneath graph shows the amount of requests that we got from different locations, including Wi-Fi access in public areas, conferences, business lounges, airports, aircrafts, offices, and at home:

Figure 2. Requests from various locations while travelling

The rationale behind our research was a simple thought: WPAD is a protocol that has been around for almost 20 years. But the environment and conditions under which it is being used have changed dramatically. End users today are more mobile, they travel a lot and are therefore more reliant on using public Wi- Fi access. Before, most people accessed the internet through a stationary PC, but now users can access the internet anywhere with various portable devices. This is especially ubiquitous in today’s workspace.

Even a typical employee may have multiple portable devices and indiscriminately connect to any available Wi-Fi network from the airport lounge, to the hotel Wi-Fi, and then to the coffee shop around the corner. These devices don’t only log on to closed, protected company networks. Each Wireless Local Area Network (WLAN) that a user logs on to for WiFi access, theoretically bears the risk of connecting to a system that resolves wpad.{domain name} requests. In the future, we will see more and more devices connecting to the internet. For instance with regard to internet of things (IoT) devices, the use of WPAD could potentially bring about a lot of problems, depending on how IoT devices will be configured to handle autoproxy configuration some of these devices might use this feature by default, or have the option for it, while some may not.

In our presentation this week at Black Hat USA we present our paper “badWPAD: The lasting menace of a bad protocol”, in which our threat researchers highlight once more the flaws inherent to WPAD and why it is a very problematic protocol that can still lead to some serious security concerns, especially under the altered conditions in today’s connected world. Our research explores how these new realities affect the already problematic WPAD protocol.

Figure 3. WPAD network requests

See our paper “badWPAD-The Lasting Menace of a Bad Protocol”  for details, results of our experiments and recommendations on how to protect your machine from the fallacy of WPAD.



Post from: Trendlabs Security Intelligence Blog – by Trend Micro

BlackHat2016: badWPAD – The Doubtful Legacy of the WPAD Protocol

Read more: BlackHat2016: badWPAD – The Doubtful Legacy of the WPAD Protocol

Story added 4. August 2016, content source with full text you can find at link above.