OIT Tech 32px

Security Self-Help Categories

Report a Security Incident:
Form Here

Information Security Issues?

Call
740.566.SAFE
Email: security@ohio.edu

Turn off Bluetooth if you are not using it on your computer or device. Not only does this make it more secure, but it also saves battery life.

Read More

SANS Institute Security Awareness Tip of the Day Jun 24

Original release date: May 23, 2016 | Last revised: June 01, 2016

Systems Affected

  • Windows, OS X, Linux systems, and web browsers with WPAD enabled
  • Networks using unregistered or unreserved TLDs

Overview

Web Proxy Auto-Discovery (WPAD) Domain Name System (DNS) queries that are intended for resolution on private or enterprise DNS servers have been observed reaching public DNS servers [1]. In combination with the new generic top level domain (gTLD) programs incorporation of previously undelegated gTLDs for public registration, leaked WPAD queries could result in domain name collisions with internal network naming schemes [2] [3]. Opportunistic domain registrants could abuse these collisions by configuring external proxies for network traffic and enabling man-in-the-middle (MitM) attacks across the Internet.

Description

WPAD is a protocol used to ensure all systems in an organization use the same web proxy configuration. Instead of individually modifying configurations on each device connected to a network, WPAD locates a proxy configuration file and applies the configuration automatically.

The use of WPAD is enabled by default on all Microsoft Windows operating systems and Internet Explorer browsers. WPAD is supported but not enabled by default on Mac OS X and Linux-based operating systems, as well as Safari, Chrome, and Firefox browsers.

With the New gTLD program, previously undelegated gTLD strings are now being delegated for public domain name registration [3]. These strings may be used by private or enterprise networks, and in certain circumstances, such as when a work computer is connected from a home or external network, WPAD DNS queries may be made in error to public DNS servers. Attackers may exploit such leaked WPAD queries by registering the leaked domain and setting up MitM proxy configuration files on the Internet.

Other services (e.g., mail and internal web sites) may also perform DNS queries and attempt to automatically connect to supposedly internal DNS names [4].

Impact

Leaked WPAD queries could result in domain name collisions with internal network naming schemes. If an attacker registers a domain to answer leaked WPAD queries and configures a valid proxy, there is potential to conduct man-in-the-middle (MitM) attacks across the Internet.

The WPAD vulnerability is significant to corporate assets such as laptops. In some cases, these assets are vulnerable even while at work, but observations indicate that most assets become vulnerable when used outside an internal network (e.g., home networks, public Wi-Fi networks).

The impact of other types of leaked DNS queries and connection attempts varies depending on the type of service and its configuration.

Solution

US-CERT encourages users and network administrators to implement the following recommendations to provide a more secure and efficient network infrastructure:

  • Consider disabling automatic proxy discovery/configuration in browsers and operating systems unless those systems will only be used on internal networks.
  • Consider using a registered and fully qualified domain name (FQDN) from global DNS as the root for enterprise and other internal namespace.
  • Consider using an internal TLD that is under your control and restricted from registration with the new gTLD program. Note that there is no assurance that the current list of Reserved Names from the new gTLD Applicant Guidebook (AGB) will remain reserved with subsequent rounds of new gTLDs [5].
  • Configure internal DNS servers to respond authoritatively to internal TLD queries.
  • Configure firewalls and proxies to log and block outbound requests for wpad.dat files.
  • Identify expected WPAD network traffic and monitor the public namespace or consider registering domains defensively to avoid future name collisions.
  • File a report with ICANN if your system is suffering demonstrable severe harm due to name collision by visiting https://forms.icann.org/en/help/name-collision/report-problems.

References

Revision History

  • May 23, 2016: Initial Release
  • June 1, 2016: Added information on using TLDs restricted from registration with the gTLD program

This product is provided subject to this Notification and this Privacy & Use policy.


Read More

US-CERT Alerts May 23

Internet Storm Center Infocon Status