Malicious DNS Namespace Collisions

Over the last few weeks, I've noticed a problem come up again in multiple places that I first saw many years ago and apparently is still very common - DNS Namespace Collisions. DNS namespace collisions occur when a private domain name is able to be resolved on the public Internet; whether it is intentional or not. ICANN has a lot of information on this if you are looking for a deep dive on the subject; instead I will be focusing on the potential security issues.

The Issue

Let's start with an example. Suppose you own the Internet domain example.org. This is your Internet presence - all your emails are @example.org, your web servers are in this domain, even your Active Directory domain is corp.example.org. All is well in the world.

When configuring hosts in your organization, one of the things you will do is set up your DNS suffix search list. This is the list of domains your systems will add to a host name if they can't initially resolve it. In our scenario, your DNS suffix search list is example.org and corp.example.org. So, if a host attempts to resolve mailserver, they might also try mailserver.example.org and mailserver.corp.example.org.

And let's also suppose that you follow good security practices and have split DNS so no one on the Internet can resolve your internal host names. You also do not allow internal hosts to directly resolve Internet host names.

Your happy domain.

Any issues so far? Nope. The computer gods are smiling upon us.

As your organization expands, you find the need to add a new internal domain so you choose example.com. Uh oh! You don't own that domain on the Internet, but you'll only be using it on the internal network. Not an issue, right? No, it is a problem.

The issue lies in that you do not own the domain example.com but are using it internally; this is a DNS name collision. The issue comes into play soon as a host accesses the Internet directly (from home, a client's network, etc.). When this happens, they won't be able to resolve hosts with the suffix example.org or corp.example.org - but as soon as they try to resolve with the suffix example.com (which you don't own) they will succeed.

So how is this an issue? In the best case, it isn't. If your hosts try to resolve something that example.com can't resolve then aside from some information leakage things should be OK. However, what if they try to resolve something that does exist in example.com and then try to start using it?

On the Internet, only example.com will resolve.

For example, our hosts are on the Internet and are trying to the internal mail server host name. The only one that is resolvable is mailserver.example.com, which we don't own. They then start to send emails - your private, internal-only emails - through a server you don't own. See the issue now?


This only happens if that host name already exists in the external domain, right? Wrong.

If DNS wildcards are used, now all of a sudden any host name is being resolved beyond your control and your hosts are sending data to potentially malicious servers. Think of how easy it would be to gain information on your organization or compromise your hosts if I could tell your hosts where their proxy, active directory, or mail servers were when they were outside your organization. And how would you ever know?

This is not a theoretical attack. In the last few weeks I have found multiple organizations where this is occurring. Specifically, they are using domains internally that they do not own, their hosts go outside their organization and are resolving these domains to malicious IP addresses.

And there are organizations that are squatting on multiple domains (including obviously internal ones) and setting up wildcard DNS to point them to their own IPs. For what purpose? I don't know, but I suspect it can't be good.

Detection, Prevention, and Response

So how can you detect this? A few ways:

1. Create a list from your DNS for all domains being used by your clients related to your organization. Make sure you own all those domains. If not, what IPs do they resolve to? Consider switching from them. (This is also a good threat hunting technique!)
2. Windows hosts like to resolve wpad/wpad.dat when browsing. The DNS search suffix tends to get added to that, so look for any HTTP requests to the Internet for wpad.dat, then look for what domains the requests are to. Even if they are not your own hosts (e.g. consultants), you should still be concerned as they could be used as a pivot point into your network.

By the way, wpad.dat is not something you want your hosts doing this with.

Prevention of this is actually pretty easy - just make sure you own any domain you use, or use ones that do not have Internet TLDs. (However, from my research there may be issues on this with some versions of Windows.)

If you do find this happening on your network, I would suggest immediately looking to see what your hosts are resolving, what data is going out, and more importantly, what is coming back in.

I would also recommend blocking the IP addresses and external domains on your Internet devices to prevent internal hosts from accessing them.

In the end, this is a big problem that I don't think many realize is going on. Fortunately, its fairly easy to detect and start investigating. Doing it now will probably save you a lot of hurt in the long run.