Possible DoS Scenario in NT4 Domain with DDNS
From: JKlemenc@fnal.govDate: 07/27/01
- Previous message: DNT: "Re: Win32.Sircam.Worm Alert....."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Subject: Possible DoS Scenario in NT4 Domain with DDNS To: SECURITY-BASICS@securityfocus.com Message-ID: <OF25ECAC89.FED4A2A1-ON86256A96.0054D6E1@fnal.gov> From: JKlemenc@fnal.gov Date: Fri, 27 Jul 2001 10:53:22 -0500
Here is something interesting I came across which can cause great woes for
NT4 system administrators. This is yet another reason to always use fully
qualified domain names and why thought should go into DNS hierarchy,
especially when using dynamic DNS.
Take the following DNS strategy:
MYCOMPANY.COM <-- main DNS domain with NT4 servers defined
NT4PDC.MYCOMPANY.COM <-- NT4 PDC host entry
USERS.MYCOMPANY.COM <-- child domain of mycompany.com for DDNS of
DHCP users
DHCP assigned DNS domain search order:
USERS.MYCOMPANY.COM
MYCOMPANY.COM
PC1 obtains a DHCP address, which is part of the USERS.MYCOMPANY.COM
domain. PC1 uses DDNS to update its host entry to PC1.MYCOMPANY.COM. Life
is good at this point. User changes his PC name to NT4PDC and reboots. A
DHCP address is assigned and his machine updates DDNS to
NT4PDC.USERS.MYCOMPANY.COM. Now, since NetBios (NT Network Browsing)
appends the users default domain name (in this case USERS.MYCOMPANY.COM) to
the NetBios name. User tries to browse the network or use resources from
NT4PDC (which gets mapped to NT4PDC.USERS.MYCOMPANY.COM). These requests
now go to the users machine instead of the PDC. This user is not able to
browse the network, but can still map drives and use resources via the FQDN
(NT4PDC.MYCOMPANY.COM). Lets say that the user turns off their machine or
discovers their error and changes the machine name back. The entry is still
probably in the DDNS table until that IP address is re-used and a new DDNS
request updates it. Now, the NT master browser for the NT network reboots
or flushes it's browse list. The master browser resolves NT4PDC
incorrectly, and ALL machines on the NT network are now affected. Every one
of them (at least ones that have rebooted or had their browse list flushed)
try to resolve NT4PDC to the NT4PDC.USERS.MYCOMPANY.COM.
This scenario does require a specific DNS and DDNS architecture, and users
may not intentionally name their PC's to the PDC name, but a few scenarios
are more likely:
A second NIC card is installed in the NT4PDC server and plugged into the
network and obtains a DHCP address (you should always enter the appropriate
IP information BEFORE plugging into the network)
- A malicious users releases a Trojan to discover a users PDC (trivial to
find), then changes the computer name via the registry (as long as the user
has local admin privileges). Upon next reboot, at the very least, a message
will popup or an event is logged that there is a duplicate name on the
network. Worst case scenario is the exploit listed above.
How to catch this:
From a workstation that is not able to connect to the resource, or browse
other domains, simply type NSLOOKUP NT4PDC and see if it resolves to the
correct IP address. If it resolves to an address in the DHCP range, or any
other IP other than the servers IP address, try to find the culprit. Also,
manually remove the entry from the DDNS tables and restart DNS.
Some ways to mitigate this:
- Always use fully qualified domain names. This includes the logon scripts,
NT drive mappings, telnet, ping, nslookup, 'net use', etc
- Think long and hard about the search order of child domains vs. which
domain the desired destination hosts are in
- Don't use DHCP on the same networks where servers are placed (computer
rooms, etc) or at least have designated network ports clearly labeled as
DHCP use
- Pre-register a CNAME for NT4PDC.USERS.MYCOMPANY.COM to
NT4PDC.MYCOMPANY.COM and for other servers
- Don't use DDNS (not always an option)
I have not tested this with a Windows 2000 domain, but I suppose it would
still hold true to some extent. Windows 2000 uses DNS to resolve resources
first, and provides SRV records in DNS to support legacy operating systems.
I am also sure that one could exploit this against other devices, as long
as FQDN is not used and the DDNS domain is first in the search list.
Thanks,
Joe Klemencic
- Previous message: DNT: "Re: Win32.Sircam.Worm Alert....."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
