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.SUB.DOMAIN.COM.AU then
HOST.DOMAIN.COM.AU then HOST.COM.AU and, maybe even, HOST.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.DOMAIN.COM.AU,
HOSTA.COM.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) my private
internal company traffic is 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
implied search path).
5. The Workaround
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.
I do not know of a workaround to problem B other than the correct
solution.
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 Phone: +61-3-9686-3233
The SysAdmin Group Pty Ltd Fax: +61-3-9686-3399
238 Richardson Street, Middle Park, VIC 3206 Pager: 03-9483-0355
PGP Fingerprint: (FE349AAD) 05 93 68 35 B2 09 8E 6F 79 8C 16 F8 8F BC 2E CB
----------------------------------------------------------------------------