Microsoft Buys Corp.com So Bad Guys Can’t

In February, KrebsOnSecurity told the story of a private citizen auctioning off the dangerous domain corp.com for the starting price of $1.7 million. Domain experts called corp.com dangerous because years of testing showed whoever wields it would have access to an unending stream of passwords, email and other sensitive data from hundreds of thousands of Microsoft Windows PCs at major companies around the globe. This week, Microsoft Corp. agreed to buy the domain in a bid to keep it out of the hands of those who might abuse its awesome power.

Wisconsin native Mike O’Connor, who bought corp.com 26 years ago but has done very little with it since, said he hoped Microsoft would buy it because hundreds of thousands of confused Windows PCs are constantly trying to share sensitive data with corp.com. Also, early versions of Windows actually encouraged the adoption of insecure settings that made it more likely Windows computers might try to share sensitive data with corp.com.

From February’s piece:

At issue is a problem known as “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.

Windows computers on an internal corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” which is a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.

For instance, if a company runs an internal network with the name internalnetwork.example.com, and an employee on that network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; typing “drive1” alone will suffice, and Windows takes care of the rest.

But things can get far trickier with an internal Windows domain that does not map back to a second-level domain the organization actually owns and controls. And unfortunately, in early versions of Windows that supported Active Directory — Windows 2000 Server, for example — the default or example Active Directory path was given as “corp,” and many companies apparently adopted this setting without modifying it to include a domain they controlled.

Compounding things further, some companies then went on to build (and/or assimilate) vast networks of networks on top of this erroneous setting.

Now, none of this was much of a security concern back in the day when it was impractical for employees to lug their bulky desktop computers and monitors outside of the corporate network. But what happens when an employee working at a company with an Active Directory network path called “corp” takes a company laptop to the local Starbucks?

Chances are good that at least some resources on the employee’s laptop will still try to access that internal “corp” domain. And because of the way DNS name devolution works on Windows, that company laptop online via the Starbucks wireless connection is likely to then seek those same resources at “corp.com.”

In practical terms, this means that whoever controls corp.com can passively intercept private communications from hundreds of thousands of computers that end up being taken outside of a corporate environment which uses this “corp” designation for its Active Directory domain.

The story went on to describe how years of testing — some of which was subsidized by grants from the U.S. Department of Homeland Security — showed hundreds of thousands of Windows computers were constantly trying to send this domain information it had no business receiving, including attempts to log in to internal corporate networks and access specific file shares on those networks.

O’Connor told me he was selling the domain after doing basically nothing with it for 26 years because he was getting on in years and didn’t want his kids to inherit this mess. When he put the domain up for sale, I asked if he’d agree to let me know if and when he sold it.

On Monday evening, he wrote to say that Microsoft had agreed to purchase it. O’Connor said he could  not discuss the terms of the deal, nor could he offer further comment beyond acknowledging the sale of corp.com to Microsoft.

In a written statement, Microsoft said it acquired the domain to protect its customers.

“To help in keeping systems protected we encourage customers to practice safe security habits when planning for internal domain and network names,” the statement reads. “We released a security advisory in June of 2009 and a security update that helps keep customers safe. In our ongoing commitment to customer security, we also acquired the Corp.com domain.”

Over the years, Microsoft has shipped several software updates to help decrease the likelihood of namespace collisions that could create a security problem for companies that still rely on Active Directory domains that do not map to a domain they control.

However, experts say hardly any vulnerable organizations have deployed these fixes for two reasons. First, doing so requires the organization to take down its entire Active Directory network simultaneously for some period of time.

Second, according to Microsoft applying the patch(es) will likely break or at least slow down a number of applications that the affected organization relies upon for day-to-day operations. Faced with either or both of these scenarios, most affected companies probably decided the actual risk of not applying these updates was comparatively low.

It should be noted that while Microsoft’s purchase of corp.com will safeguard companies that built Active Directory infrastructures on top of “corp” or “corp.com,” any company that has tied their internal Active Directory network to a domain they do not control is opening itself to a similar potential security nightmare.

Further reading:

Mitigating the Risk of DNS Namespace Collisions (PDF)

DEFCON 21 – DNS May Be Hazardous to your Health (Robert Stucke)

Mitigating the Risk of Name Collision-Based Man-in-the-Middle Attacks (PDF)