JASBUG: Improper Use of the DNS for Authentication and Over-the-Internet Exploitation Scenarios

Wed Feb 18 12:55:18 UTC 2015

The bug we found in Microsoft Windows Group Policy and UNC mounts is, among other things, an example of a class of problem we call: Improper use of the DNS for Authentication.  We’re sure there are more of these to come.  Unfortunately, this may be one of the first serious “perpetual zero-days” as XP and Windows 2003 Server will be vulnerable to this sort of attack forever.

This class of problem was described so well by Robert Stucke in his DEFCON 21 presentation: DNS May Be Hazardous to Your Health.  Robert cleverly figured out DNS names to register on the open market that granted him some sort of trust in various situations. Similarly, we found situations where Windows clients rely only on the DNS lookup for remote server authentication – which is far too trusting.

It’s worth noting that we found this issue while researching “namespace collisions” in the DNS.  A namespace collision is a situation where a private DNS namespace overlaps (partially or fully) with the Internet DNS namespace.  But it’s not straightforward as opaque DNS search list processing by the local stub resolver effectively expands the DNS namespace that clients search in unanticipated and not well understood ways resulting in much larger potential for DNS namespace overlap than one might expect.

The amount of “iterative exploration” of the DNS namespace executed by local DNS stub resolvers during every query is surprising – even to technology experts.

As the largest Top Level Domain (TLD), .com winds-up appended to a sizable proportion of global DNS queries by the local stub resolver as a last-ditch effort to perform a successful lookup.  This behavior has nothing to do with the .com registry; rather, it’s a function of local configuration: often machines configured with fully qualified hostnames ending in .com helpfully deconstruct their own hostname and augment local DNS search path processing accordingly.  Local DNS stub resolvers try really hard (too hard) to succeed before giving-up with an NXDOMAIN.

While this behavior is not limited to Microsoft products, Microsoft refers to this concept as DNS Devolution and partially describes it in this Microsoft Knowledge Base article.  From that article: “Devolution is a behavior in Active Directory environments that allows client computers that are members of a child namespace to access resources in the parent namespace without the need to explicitly provide the fully qualified domain name (FQDN) of the resource.”

In many cases, all of this is actually helpful: typing website into your browser may result in an eventual lookup to website.com before giving-up, which may be what was intended.  However, attempting to mount a UNC share called \\sharename may result in an attempt to mount \\sharename.com, which is almost certainly not what was intended.  Many popular ccTLDs (Country-Code TLDs) are also appended to DNS queries during DNS search list processing, depending on local configuration settings.

An exacerbating factor: often machines don’t fully control their own hostnames if DHCP is in use.  While I’m sitting at a coffee shop in Paris, I may have a DHCP-assigned hostname ending in .fr provided by the local ISP.  While there, my local machine helpfully appends .fr to my DNS queries as a last-ditch effort to perform a successful lookup.  But when I travel to a hotel in Berlin the next day, I may be assigned a hostname ending in .de and my local DNS stub resolver starts helpfully appending .de.  All of this behavior is highly dependent on local configuration and it’s really, really messy.  To say it’s not well understood – even by IT professionals – is an understatement.  The DNS namespace my local machine searches may be dependent on locale and local network factors which change over time and physical location.  Sometimes DNS servers “in the middle” further meddle with my queries, particularly in hotels and similar locations, with varying levels of transparency and, um, “helpfulness”.  Said differently: my local machine may encounter a colliding DNS namespace when in location A but not when in location B.

How does this relate to the JASBUG?

The on-LAN part of this is getting all the attention, because that’s what Microsoft described in their example. But there are at least two ways to exploit this: there is a targeted way (I want to own that machine over there) and an un-targeted way (I want a bunch of bots). We actually found the latter first and developed the former weeks later. One fateful day last year, we had over 200,000 machines asking us for code to run over the Internet using these techniques.  That was what we went to Microsoft with – and obviously it got their attention.

The un-targeted way is all about finding domain-joined Windows machines spewing DNS queries to the Internet.  If the queries fail (NXDOMAIN), no harm done.  However, if they start succeeding, bad things can be made to happen.  Given the complexities discussed above, it’s not that hard to contrive colliding DNS namespaces – somewhat surprisingly so.  These impacted machines may be clients, servers, mobile, embedded, anything.

Microsoft Active Directory is a private DNS namespace, although this concept is not widely appreciated.  When the Active Directory namespace overlaps with the Internet DNS namespace – either directly or indirectly via local DNS search path processing – the opportunity to communicate with these machines in a trusted way exists.

So, un-targeted over-the-Internet exploitation looks generally like this:

1). Go buy colliding DNS registrations on the open market from your favorite registrar (ala Stucke);

2). Receive A/SRV DNS queries from Active Directory clients whose (private) namespaces overlap the Internet DNS namespace you just bought – either directly or as a result of local search path processing;

3). Respond to those queries by pointing the machines to servers of your own;

4). Observe the queries to learn about the local Active Directory topology;

5). Push Group Policy Objects, login scripts, alternate file system mount points, etc, of your choosing;

5a). Offering SYSVOL and NETLOGON are especially fun;

6). Enjoy your new botnet/Crypto-whatever victims/etc.

Misuse of DNS for authentication is the original sin, and the lesson to learn.