U.S. Department of Homeland Security US-CERT   
      
   National Cyber Awareness System:   
      
      
      
   TA16-144A: WPAD Name Collision Vulnerability   
   05/23/2016 07:38 AM EDT   
      
      
   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) program’s 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/hel   
   /name-collision/report-problems.   
   References   
   [1] Verisign – MitM Attack by Name Collision: Cause Analysis and Vulnerability   
   Assessment in the New gTLD Era   
   [2] ICANN – Name Collision Resources & Information   
   [3] ICANN – New gTLDs   
   [4] US-CERT – Controlling Outbound DNS Access   
   [5] ICANN – gTLD Applicant Guidebook   
   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.   
      
      
   ----------------------------------------------------------------   
   -------------- -   
   A copy of this publication is available at www.us-cert.gov. If you need help   
   or have questions, please send an email to info@us-cert.gov. Do not reply to   
   this message since this email was sent from a notification-only address that   
   is not monitored. To ensure you receive future US-CERT products, please add   
   US-CERT@ncas.us-cert.gov to your address book.   
   OTHER RESOURCES:   
   Contact Us | Security Publications | Alerts and Tips | Related Resources   
   STAY CONNECTED:   
   Sign up for email updates   
      
   SUBSCRIBER SERVICES:   
   Manage Preferences  |  Unsubscribe  |  Help   
      
      
   ----------------------------------------------------------------   
   -------------- -   
   This email was sent to Fido4cmech@lusfiber.net using GovDelivery, on behalf   
   of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray   
   Lane SW Bldg 410 · Washington, DC 20598 · (888) 282-0870  Powered by   
   GovDelivery   
      
   === Cut ===   
      
      
   --   
   Keep the faith   :^)   
      
      Ben  aka cMech  Web: http|ftp|telnet://cmech.dynip.com   
                    Email: fido4cmech(at)lusfiber.net   
                 Home page: http://cmech.dynip.com/homepage/   
              WildCat! Board 24/7  +1-337-984-4794  any BAUD 8,N,1   
      
   --- GoldED+/W32-MSVC   
    * Origin: FIDONet - The Positronium Repository (1:393/68)