Corp.com is up for sale – check your Active Directory settings!

An old domain that has lain dormant for 26 years is going on sale – and the results could be catastrophic for enterprises with poorly configured Active Directory setups.

Brian Krebs reports that Mike O’Connor, a domain prospector who registered corp.com in 1994, wants to sell the domain for $1.7 million as he simplifies his estate. Most other domains would simply be a useful way to generate web traffic, but corp.com is different.

The problem lies with Microsoft’s Active Directory. This product, which provides identity management services across most of the world’s enterprises, handles internal URLs using its own domain naming system which is connected to but separate from the public domain naming system (DNS).

Because Active Directory is controlling what happens inside the company network, the company can host its services on whatever domains it likes. So, let’s say that your company hosts all of the services that its employees can access from inside the company network on the example.com domain.

The company HR portal might be accessible via a Fully Qualified Domain Name (FQDN) like hr-portal.example.com, for example, assuming that example.com was your company’s domain. Active Directory ensures that people inside the company network who type hr-portal.example.com into their browser are sent to the company HR portal.

No one wants to type in the full name for a server that they visit every day from inside the company network. So Windows makes that easier too, using a feature called DNS devolution. It works by appending portions of the Active Directory domain to an unqualified domain name. In our example, you could just type hr-portal, and Windows will try appending .example.com to see if it gets a hit.

Windows machines use a search list to tell them what to use during DNS devolution. The search list is either configured in the registry or sometimes declared explicitly in a file. As section 3.1 of this ICAAN Security and Stability Advisor Committee document on DNS search list processing points out, search list processing is affected by factors including the computer’s hostname (which you’ll be asked for when setting up business versions of Windows).

If you try to access hr-portalfrom outside the company network and your computer has the hostname example.com, your computer will probably contact an external DNS resolver, which will look up the public records for example.com.

That’s fine, so long as your hostname is a domain that your company owns. If your company controls the public DNS records for example.com, it can direct your request somewhere useful, or at least harmless, when you’re outside the company network.

But what if the company used a domain that it doesn’t own for its Active Directory?

That’s a problem called namespace collision, and it can spell trouble. If an attacker registers example.com, they can direct unsuspecting users to phishing sites, collect their emails, and worse.

No one would be daft enough to use an Active Directory domain that they didn’t own, right? Unfortunately, early versions of Windows that ran Active Directory used corp as the default Active Directory domain. Companies that didn’t reset it to a subdomain they owned now have an Active Directory implementation using corp. Active Directory’s technical architecture makes that very hard to change, according to Jeff Schmidt. He’s the CEO of JAS Advisors, a security consultancy that evaluated namespace collision dangers for ICAAN.

If that corp domain lies at the end of your Active Directory, you have a problem. An Active Directory-registered machine logging on from outside the network will try a variety of things in its search list until it finds a match. It will eventually hit your hostname (example.com). If you don’t have control of the hostname domain and can’t guarantee that it will resolve, Windows starts trying to find a match in portions of the hostname, up to and including the top level domain of the hostname, which in many cases will be .com.

So if you have corp at the end of your Active Directory domain (as was the default for early versions of the product) and you look up hr-portal.corp on your company network, your Active Directory controller will recognise it and resolve it. When outside your network, though, that query will fail because the Active Directory controller isn’t there to handle the corp part.

The computer will start trying to resolve DNS queries using its search list, gradually devolving the list – including the hostname on the list. If your computer has .com in its search list, or a hostname ending in .com that won’t resolve, it will eventually try to resolve the partial URL against the .com top-level directory alone. hr-portal.corp.example.com? Nope. hr-portal.example.com? Nope. How about hr-portal.corp.com? Or corp.com?

Admins will often misconfigure explicit search lists just to get things to work, warns Schmidt:

Your admin through group policy can actually create a search list manually. That happens a lot, particularly in enterprises that have glued together a bunch of things over the years.

He has also seen admins configure .com directly into search lists as a catch-all to ensure that queries resolve.

The danger of a computer resolving to corp.com wasn’t an issue as long as O’Connor owned the corp.com domain, but now that he’s selling it off, it creates a potential problem. An unscrupulous buyer could potentially use that domain as a watering hole for anyone whose company still uses corp at the end of its Active Directory domain suffix list.

This isn’t just hypothetical, says Schmidt. JAS Advisors conducted an experiment with O’Connor to see what kinds of traffic were hitting the dormant corp.com domain. They saw a river of sensitive data including logins and emails. “I know, I’ve seen the data,” he says. “I have the 30+ queries/second to show it.” Luckily, they were able to destroy the data and discontinue the experiment.

If the domain falls into less benevolent hands, someone could use it to mount attacks on companies that haven’t switched out their corp Active Directory domains or installed updates.

What to do

What should companies do about this? Unfortunately, explains Schmidt, it’s very difficult to get rid of the corp domain once it’s in your Active Directory. “Never ever in any context but in Active Directory especially never use a namespace you don’t control. Because you never know who will,” he says.

Instead, use a domain that you own for your Windows hostnames, and name your internal machines and services using subdomains of it.

You should also take a corporate laptop to the local coffee shop and then check its DNS query logs to see how it’s resolving its domains outside the company network, and adjust your configuration accordingly, Schmidt concludes.

Latest Naked Security podcast