Security Hole: Microsoft NT 4.0 DNS Implicit Search Path

The following is the text of an email I posted to the NTBugTraq mailing list in August last year. This information was also passed onto AUSCERT, and Microsoft through several channels. No response has been forthcoming from Microsoft. No fix is in sight. 

From: Geoff.Halprin@SysAdmin.COM.AU
To: ntbugtraq@rc.on.ca
Date: Fri, 8 Aug 1997 11:04:13
Subject: NT DNS Implicit Search Order Hole

Morning all,

Here is one to be wary of:

	NT 4.0 implements an implicit DNS search order

Seems like a simple, harmless statement, but actually it creates
two major security holes...

1. Background

Old (deprecated) DNS client behaviour was to implement an implicit search
path for domain name lookups.

Basically, it will implicitly escalate an unsuccessful DNS request for
HOST.WG.SUB.DOMAIN.COM.AU to HOST.WG.DOMAIN.COM.AU then HOST.WG.COM.AU
and, maybe even, HOST.WG.AU before returning an error.

As you can see, this can lead to a name being resolved against entirely
the wrong host, and one which is in another company or even country.

This is deprecated behaviour, and should be disabled, or at least have a
registry setting which does disable it. For more on search paths, see the
O'Reilly DNS book, pp. 95 (2nd Ed).

Of course, being deprecated behaviour, that means NT implements it.
[Why, oh why, can't they learn from the world around them. :-( ]

The problem is made more subtle (hidden) by Microsoft - a blank "search
order" in the DNS config screens would imply no search order, rather than
'use an undocumented deprecated one'.

2. The Problems

Problem #A:
 If a site is not using WINS, but incorrectly sets the "Enable DNS for
 Windows" option. Configuring a machine HOSTA in in a workgroup WG and a
 DNS domain DOMAIN.COM.AU will result in netbios attempting to exchange
 browser lists (or similar - I am not sure exactly what it is doing) with
 HOSTA.WG.DOMAIN.COM.AU and, failing that, with HOSTA.WG.COM.AU,
 HOSTA.WG.AU, etc.

Problem #B:
 If a site does use WINS, but a machine is turned off (e.g. for the
 weekend) or crashes, then the client will escalate the query as
 previously described.

 This version of the problem is far more insideous. A site with good NT
 expertise, who has done everything right, is still susceptible should
 a box crash (or the network to it).

3. The Security Holes

In both cases, the potential to exchange classified information exists,
and most definitely a storm of NETBIOS traffic every 13 minutes results. I
am receiving just such a storm as I write this. :-(

This means that by turning a machine off (or it BSODing) your private
internal company traffic may be suddenly heading out over the Internet!
No authorisation, no logging, silently. The only way to stop it is with
a firewall (filtering router), which is also the only way to detect it.

Someone less scrupulous could easily craft a fake NETBIOS server to
exchange false lists and extract this information. As Jason suggested when
I posted this to the SAGE-AU list, it would be interesting if someone went
out and registered "workgroup.com.au" or similar. They could just sit back
and collect privileged information.

As a lesser hole, the amount of erroneous traffic that NT 4 machines are
generating across the Internet is massive - every 13 minutes, most of it
entirely undetected, and dropped because the (non NT) machine at the other
end isn't listening to that port. Maybe we should sent MS our traffic
bills? :-)

4. The Symptoms

The problem relates to name resolution, and the effect is a whole lot of
unauthorised NETBIOS traffic to your site from random sites across the
world.  (Actual symptom: attempts from foreign site to connect to port
UDP/137 [netbios-ns] on one of your (probably not even NT) hosts.)

The upshot of this is that sites all across the Internet are being blasted
with NETBIOS packets every thirteen minutes because their registered
domain name happens to coincide with a mis-formation of a random NT
workgroup name.

As the registered owner of 'sysadmin.com.au' and 'is.com.au', I get more
of these because 'sysadmin' and 'is' are common host and workgroup names.
I suspect that the implementation of the search path means that non-US
sites (with a top level domain other than .com etc) are more likely to
see this bug (the top level domain side-steps the built in limit in the
implicit search path).

5. The Workaround

A. Many organisations do not use WINS, and certainly don't use WINS through
   DNS. So it is important to make sure that the "Enable DNS for Windows"
   option (very badly named) on the WINS configuration screen is disabled.
   This stops problem A dead.

B. If you have control over the router which connects your company to the
   Internet, and do not need to exchange NETBIOS traffic with another
   site (very ill-advised anyway), then BLOCK ALL NETBIOS TRAFFIC
   (in both directions). Block ports 137, 138 and 139 (both UDP and TCP)
   in-bound and out-bound. (Why were they open in the first place? :-)

6. The Solution

The solution is simple; either (a) remove this deprecated functionality,
or (b) create a registry setting to disable it (which should default to
disabled).


Warm regards to all,

Geoff

----------------------------------------------------------------------------
Geoff Halprin                                  Geoff.Halprin@sysadmin.com.au
Managing Director                                 http://www.sysadmin.com.au
The SysAdmin Group Pty Ltd                            Phone: +61-3-9686-3233
238 Richardson Street, Middle Park, VIC 3206          Fax:   +61-3-9686-3399
PGP Fingerprint: (FE349AAD) 05 93 68 35 B2 09 8E 6F  79 8C 16 F8 8F BC 2E CB
----------------------------------------------------------------------------