Alternatively, you can use Windows Explorer to perform the same steps:
1.Open Windows Explorer.
2.Locate the repair directory (usually C:\winnt\repair), right-click the repair folder, and select Properties.
3.Select the Security tab.
4.Select Permissions.
5.Enable Replace Permissions on Subdirectories and Replace Permissions on Existing Files.
6.Remove all users except Administrators and SYSTEM.
7.Verify that Administrators and SYSTEM both have Full Control.
8.Click OK.
You've now granted administrators and the system user full control to that subdirectory and all the files stored in it. Because you didn't choose to edit the ACL, NT has removed all other users' permissions.
In addition to the \repair and \config directories, NT is likely to write SAM-derived information in one of the following files, depending on your system configuration: pagefile.sys, memory.dmp, or user.dmp. NT uses pagefile.sys as an additional virtual memory space that adds to the system's installed hardware-based RAM. NT creates memory.dmp when it crashes and you have your system configured to write a memory dump to disk. NT creates user.dmp when a desktop application crashes and you have Dr. Watson configured to write a memory dump file.
When NT uses any of these files, it writes a considerable amount of memory to disk. In some cases, this information includes passwords that might have been memory-resident. Therefore, gaining access to these three files can become an easy way for an attacker to retrieve sensitive information that can lead to a system security breach.
Minimizing the risk the user.dmp and memory.dmp files present requires you to take one of the following actions:
- Write a batch file to erase the files when you log on.
- Set permissions on the files so that only administrators can access them.
- Set a Registry key to erase the system's pagefile at shutdown.
- Configure your system and Dr. Watson so that they don't create the files.
Configuring the system so that it doesn't create these two files is your best bet. However, this method creates a situation in which programmers who must debug a crash problem won't have any data to work with.
To configure Dr. Watson to not write user.dmp files, run drwtsn32.exe, clear the Create Crash Dump File check box, and close the program. To configure NT to not write a memory.dmp file, open the System applet in Control Panel and choose the Startup/Shutdown tab. Next, clear the Write debugging information to check box. If you must have the memory dumps from NT system crashes, consider configuring the system and Dr. Watson to store the dump files in a secure directory that only administrators can access.
As for pagefile.sys, only the OS opens this file and protects it against direct-access attacks. However, you might recall the incident last year in which the bundled NT-based Client Service for NetWare service was writing users' clear-text NetWare passwords directly into memory, and the passwords could've been written to pagefile.sys when NT paged memory space to disk. Anyone with a copy of the pagefile.sys file and a text editor could readily glean the passwords. Novell corrected this problem by having the service use an undocumented API call that encrypts the passwords before the service places them in the pagefile. But attackers can defeat that encryption—a savvy programmer from Russia discovered a way to decrypt the information after you retrieve it from the pagefile. To protect yourself from this type of attack, configure NT to erase the pagefile during system shutdown. (We'll explain this process later in the article.) Also, don't overlook the need for physical security to protect against unwanted access of pagefile.sys.
Although you can configure NT to erase the pagefile during a clean system shutdown, you guard against only intruders copying or corrupting the file when they boot another OS on that system (e.g., when an attacker uses a bootable disk or an alternative install of NT to boot the system). In those cases, most attackers will have already learned about gaining direct entry to your network by copying or moving the SAM database, so attacking the pagefile is essentially pointless.
Nonetheless, in situations in which a network requires you to have multiple OSs installed for legitimate use, erasing the pagefile during a clean system shutdown is a good safeguard to practice. Keep in mind that configuring NT to automatically erase the pagefile during system shutdown will introduce a lag in the system's startup and shutdown time, but this lag is inconsequential if you consider the security you'll gain by doing so. To configure NT to erase the pagefile during a clean shutdown, modify (or create) the ClearPageFileAtShutdown entry (type REG_SZ, value 1) in the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\Session Manager\Memory Management Registry key.
Password Hashes in Memory
By default, NT caches the logon credentials for the past 10 users who logged on interactively. The purpose of this functionality is to let a user still log on to the system even if you disconnect the system from the network or if the domain controllers are unavailable. NT provides some protection for the logon credential cache, but if your environment requires a higher level of security, you might want to disable the caching completely because someone could attack it. Keep in mind that the logon cache credentials contain password hashes of other hashes, which makes this data difficult to crack or use for an unauthorized logon attempt. To date, no publicly known exploit of this cache has occurred. To disable credential caching, change the CachedLogonsCount entry (type REG_DWORD, value 0) in the HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersionWinlogon Registry key.
SAM on the Network
NT uses the Server Message Block (SMB) protocol, which Microsoft, IBM, and Intel jointly developed. SMB defines a series of program-level commands that obtain or provide remote file services in a network environment. As you might suspect, an SMB session requires the transmission of sensitive packets of information over the network. Among other information, these packets typically contain an encrypted version of the NTLM challenge when NT transmits the packets during the authentication phase of an SMB session.
Attackers using a readily available packet sniffer can easily grab data sent across the network. Although the task of grabbing the right packets and extracting password information from them hasn't always been straightforward work, this situation changed dramatically with L0pht Heavy Industries release of SMB Packet Capture, an SMB sniffer tool that the company now tightly integrates into L0phtCrack. With L0phtCrack at your disposal, grabbing SMB-based password hashes off the network is easy.
L0phtCrack's built-in sniffer utility silently grabs SMB password hashes and stores them for cracking. Once cracked, these passwords provide easy access to whatever network resources the user account had access to—ouch! The risk here is obvious, and the prevention is simple.
To protect against such an attack, you'll need to use NTLMv2, which shipped with SP4 and SP5, or a VPN tool, such as Microsoft's PPTP. NTLMv2 should be sufficient to protect data as it travels over your internal LAN, and PPTP will help guard your information as it travels over untrusted networks (e.g., the Internet). If you implement PPTP, be certain to load the latest service pack and all the post-service pack hotfixes. We give you this warning because, at one time, compromising a PPTP connection was very easy. Microsoft has long since remedied those shortcomings, but you won't have these remedies in place unless you load the post-SP3 hotfixes or a later service pack.
Also, keep in mind that without a VPN and Microsoft's SMB signing technology in use on your network, a man-in-the-middle attack could potentially hijack an SMB session. Microsoft introduced SMB signing in SP3 and also includes it in later service packs. SMB signing causes the OS to authenticate each SMB packet before acting on it. However, implementing SMB signing has some far-reaching effects on network functionality, so be sure to see the Microsoft article "How to Enable SMB Signing in Windows NT" (http://support.microsoft.com/ support/kb/articles/ q161/
3/72.asp) for complete details.
To help thwart tools such as L0phtCrack, you might want to restrict NT from sending LanManager (LM) password hashes across the network. LM hashes are much easier to crack than NTLM challenge/response-based hashes because NTLM allows the use of case-sensitive passwords and can use extended keyboard characters, a feature that effectively expands the encryption key space by 26 characters. Remember that strong passwords are difficult for hackers to crack, even with tools such as L0phtCrack. Consider including a carriage return in your password because L0phtCrack doesn't handle this character very well. To insert a carriage return, press Alt+0+1+3 on your keyboard's numeric keypad.
Microsoft released a post-SP3 hotfix that implements a new Registry key for handling this problem. This fix is also present in service packs later than SP3. The new Registry entry is LMCompatibilityLevel (type REG_DWORD) in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\Lsa.
Using NTLMv2, you can set the value to 0, 1, 2, 3, 4, or 5. Setting the value to 0 causes NT to send both NTLM and LM password forms across the network when NT authenticates a network connection (NT's default method of authentication compatibility). Setting the value to 1 causes NT to send both password hashes only if the server requests this action. Setting a value of 2 never lets NT transmit the LM password hash over the network. Setting a value of 3 causes the system to use only NTLMv2 authentication. A value of 4 causes domain controllers to refuse LM authentication, and a value of 5 causes a domain controller to accept only NTLMv2 authentication. Setting this value to 2 is safest, but keep in mind that with this setting, systems that support only LM-style authentication (e.g., Windows 95 and Windows for Workgroups—WFW—systems) can't connect to that particular NT system because they support only the LM type of authentication. For complete details about this configuration setting, see the Microsoft article "How to Disable LM Authentication on Windows NT" (http://support.microsoft.com/ support/kb/articles/ q147/7/06.asp). Note that with the release of SP4, this Registry key value can have six possible settings.
Another type of attack exists if an intruder has physical access to a machine. Using a tool such as NT Locksmith or ERD Commander (you can find both at http://www.winternals.com), attackers can access a system under any user account. To protect against these attacks, make sure you guard the machine to prevent physical access.
Take a Load Off
In this article, we've presented ideas and configuration areas that you need to consider when you implement and manage your NT network and its security. We've also mentioned a few NT-based application password concerns (see the sidebars "BackOffice Security," page 91, and "Securing Custom Applications") that highlight potential problems and help you find ways to discover and watch over password protection issues.
This article should help take a load off your mind, but don't get too relaxed. You've still got a network to closely monitor. Keep watching those event logs!