Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
NT Gatekeeper: Exploitation of DNS
Jan answers your Windows NT security questions about DNS security, making NTLM authentication more secure, protecting the Administrator account, influencing the choice of DC in a secure-channel setup, and more.
Jan De Clercq
March 5, 2001
9 Min Read
Get answers to your security-related NT questions
[Editor's Note: Do you have a security-related question about Windows NT 4.0? Send it to [email protected], and you might see the answer in this column!]
Intruders can exploit the DNS to launch attacks. What can I do at a DNS server level to protect against these intruder attempts?
First, restrict DNS zone transfers. If intruders can list the contents of your DNS zones, they can find the IP addresses of specific application servers they'd like to target (e.g., a mail server) and plenty of other interesting information about your hosts. To limit zone transfers to a set of IP addresses, add them to the zone's Notify List and select the check box Only Allow Access From Secondaries Included on Notify List. You can configure this list from the Notify tab in the Zone Properties dialog box, which Figure 1 shows.
Another attack you can protect your DNS servers against is DNS spoofing (aka cache pollution). In a DNS spoofing attack, an intruder inserts phony data in your DNS cache by querying your DNS server for information properly under its control. The intruder's query forces your DNS server to launch a request to the DNS server under the intruder's control. The DNS server returns the requested information and also any additional information of the intruder's choosing. This additional information can even include an entry for a DNS root server that would force your DNS server to make all requests for name resolutions through a machine under the intruder's control.
A basic measure to protect your DNS servers against DNS spoofing is to turn off all recursive queries. To do this, create the NoRecursion (REG_DWORD) entry and set the value to 1 in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters subkey.
Service Pack 4 (SP4) offers a better way to protect against DNS spoofing. On SP4 machines, you can create the entry SecureResponse (REG_DWORD) and set its value to 1 under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters subkey. If you set this entry, the DNS server caches only records in a subtree of the zone it initially queried.
A split-brain DNS is an efficient solution for limiting the exposure of internal host information to the public network (e.g., the Internet). In a split-brain DNS, a public DNS server (e.g., at the company's ISP) hosts a zone containing host information that's OK to publish on the public network. In the company's internal network, a private DNS server hosts a zone containing all internal host information that's not OK to publish to the public network. You shield the internal network from the public network with a firewall-based perimeter-security solution.
During a security seminar I attended, somebody mentioned that portions of the NT LAN Manager (NTLM) authentication protocol (e.g., the LM hash) are insecure. Is this true? What can I do to make NTLM authentication more secure?
Yes, this is true. Before I explain, let's look at the basic operation of the NTLM authentication protocol. NTLM is a Challenge/Response-based authentication protocol. To authenticate a user to a server, the client and the server run through four basic steps:
The client tells the server the user wants to access a resource on the server.
The server sends a challenge (i.e., a random string) to the client.
The response the client sends back to the server consists of the server's challenge, encrypted using the hashed version of the user password.
The server validates the response by encrypting the challenge it sent out with its local copy of the hashed user and compares the result to the response it received from the client. If they're identical, the server authenticates the user.
The NTLM authentication protocol consists of two subprotocols: NT and LM. Windows 9x, Windows 3.x, DOS, and OS/2 support only LM Challenge/Response authentication. For backward compatibility, NT supports both authentication flavors, so NT servers can authenticate requests coming from Win9x, Windows 3.x, DOS, and OS/2 clients. By default, every NT client responds to an NTLM challenge by sending back both an NT and an LM response. These responses let NT clients authenticate to Win9x, Windows 3.x, DOS, and OS/2 servers.
What makes portions of the NTLM authentication protocol insecure is the way the LM Challenge/Response subprotocol hashes the user password. Because of the way this LM hash works, the effective password length is limited to seven characters (even if the user uses a longer password), and all characters are stored in uppercase (even if the user uses a combination of uppercase and lowercase characters). This hash makes it easy for brute-force cracking tools such as L0pthCrack to break the LM response. For more details about the weaknesses of the LM hash, visit http://www.l0pht.com. The LM hash weaknesses don't mean the NT portion is unbreakable; it simply takes much more time to break it.
Before SP4, no easy way existed to disable the LM portion of the NTLM authentication protocol. However, with SP4 installed, an NT client can control the NTLM subprotocols it uses, and NT servers can set the NTLM subprotocols they'll accept. In addition, Microsoft included an enhanced version of NTLM—NTLMv2—in SP4. One of the advanced security features NTLMv2 provides is the sealing of a user's access control data in an NTLM pass-through message. NTLMv2 is available on any NT machine running SP4 or later, as well as on any Windows 2000 machine. Microsoft provides NTLMv2 support for Win9x with the Directory Services Client shipped with Win2K. For more information about NTLMv2, see "Inside SP4 NTLMv2 Security Enhancements" (http://www.win2000mag.com/articles/index.cfm?articleid=7072).
To control the NTLM subprotocols, use the LMCompatibilityLevel (REG_DWORD) entry under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa registry subkey. Table 1 shows the LMCompatibilityLevel values and their meanings.
The Administrator account has almost unlimited power. How can I protect the account from unauthorized use?
You're absolutely right. Administrators are the exception to some key NT security rules. For example, administrators aren't subject to the discretionary access control (DAC) principle: Even though the owner of an object determines that object's ACLs, an administrator can always take ownership and override those ACL settings. Another example is account lockout. By default in NT, you can't lock out an Administrator account. To protect this powerful account from unauthorized use, you can
Block brute-force cracking of the administrator password. Microsoft has provided a solution to apply the domain-lockout rules to the Administrator account for network logons. To set up domain-lockout rules for the Administrator account, run the Passprop utility (available in the Microsoft Windows NT Server 4.0 Resource Kit) with the /Adminlockout switch. This lockout applies only to network logons, not interactive logons.
An interesting side note from an auditing perspective is that on pre-SP4 systems, NT logs account lockouts only to the event log of the system where the event occurred. NT doesn't log account lockouts in a domain controller's (DC's) event log. This setup is bad. You should trace administrator account lockouts in a DC because people usually monitor a DC's event log more closely than a workstation's event log, so any attempt to misuse the Administrator account would be apparent to the correct person immediately. To enable logging of lockout events to the PDC event log and the event log of the DC that receives the authentication request, install SP4 and enable auditing of user and group management: Open User Manager for Domains, select Policies from the Audit menu, select the Audit these events check box, and select Success and Failure for the User and Group Management option. On pre-SP4 systems, install the LSA2 hotfix available at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp3/lsa2-fix. You must apply the fix to all DCs in the domain.
Rename the Administrator account to limit its visibility. However, even if you rename the Administrator account, an intruder can still examine the account SIDs to discover the Administrator account. In NT the Administrator account's SID always ends in 500. A well-known example of this trick is the Redbutton attack, in which an intruder uses the Anonymous account to access the registry of a remote machine and retrieve useful information (e.g., account names and share information). To block the Redbutton attack, Microsoft included a new registry hack in NT SP3. Setting the registry entry RestrictAnonymous (REG_DWORD) to 1 in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa registry subkey halts Redbutton. Enabling Restrict-Anonymous has an important downside, however: It disables a set of Win2K security features (for more information, see the Microsoft article "How to Use the RestrictAnonymous Registry Value in Windows 2000" at http://support.microsoft.com/support/kb/articles/q246/2/61.asp).
Ensure that users have strong passwords. Increase the required password length or implement a custom password-filtering DLL (e.g., passfilt.dll). Longer and more complex passwords oblige intruders to invest more time and effort in brute-force password-guessing attacks.
On my file servers, I want to prevent my users from seeing the ACL settings on the files and folders. How can I hide the Security tab in the Properties dialog box of NTFS files and folders?
To hide the Security tab from your users, change the access permissions on the rshx32.dll file on every user workstation, as follows:
Log on using an account that has local administrator rights.
Find rshx32.dll in the winntsystem32 directory.
Right-click the file and choose Properties. Click the Security tab, then the Permissions button.
Remove Read permission for the Everyone group. Leave Read permission for the appropriate users or groups you want to see the Security tab.
Restart the workstation.
By default, all users have Read access to this file, and administrators have Full Control access to it. The change I explain here affects all users logging on to the workstation, and it affects the display of the Security tab for local and remote NTFS files and folders. Although this change might have a positive impact on your Help desk's request load, it might be frustrating for security-aware users who can no longer set security on their files.
I'm the administrator of the NT infrastructure for a large, multinational company. We have users in Paris whom a DC in Milan, Italy, instead of the local DC, must authenticate. The network bandwidth between these two sites is limited, so remote authentication has a serious impact on the logon time for the Paris users. What can I do to remedy this situation?
You can influence the choice of DC in a secure-channel setup several ways. (For more information about the concept of secure channel, see the sidebar "What's a Secure Channel?") The problem with secure-channel setup is it has too many variables in the DC selection process, including the configuration of NetBIOS name resolution, bandwidth availability, and DC load. So you can end up with the situation you've encountered.
To influence the choice of DC
Change the NetBIOS node type to M-node. Because M-node first broadcasts on the local subnet, the chances of selecting a local DC are greater. If this first broadcast is unsuccessful, M-node queries a WINS server. To change the NetBIOS node type to M-node, set the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParametersNodeType subkey value to 4.
In the machine's LMHOSTS file, configure a preloaded 1C NetBIOS record for the local DC of the domain. The sample line below preloads a NetBIOS record for the CompaqDC1 DC of the domain Compaq in the machine's local NetBIOS cache.
104.57.86.95 CompaqDC1 #PRE #DOM:CompaqTo list the contents of the NetBIOS cache, type
nbtstat c
at the command prompt.
Use SP4's setprfdc.exe tool to set a list of preferred local DCs.
Table 2 lists tools for detecting and troubleshooting secure-channel problems in an NT environment. The Microsoft article "Secure Channel Manipulation with TCP/IP" (http://support.microsoft.com/support/kb/articles/q181/1/71.asp) documents most of these tools.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
