Where NT Stores Passwords

You probably know that passwords are the keys to most doors on a network, but do you realize where Windows NT 4.0 stores passwords? You can find them in many interesting places, so you'd be wise to become aware of these areas and provide adequate protection against prying eyes.

NT uses the SAM to store and retrieve user credentials such as passwords. Because the SAM stores its information in the SAM database, you can assume that NT is only as secure as its SAM data. And getting a handle on SAM security isn't easy unless you know all the places you might find a SAM database. This article will help you secure specific areas of your NT systems and find additional areas that need further configuration to strengthen security.

The SAM Registry Keys
NT stores a permanent working copy of the SAM database on your hard disk. You can access the database via the HKEY_LOCAL_MACHINE Registry hive under the SAM key by either writing a program or using a Registry editor (e.g., regedt32.exe). Ordinarily, users can't directly access the SAM key with a Registry editor because NT limits the permissions on the key to the built-in SYSTEM account, but administrative users can trick NT into providing SAM-key access under the user context of the SYSTEM account.

Disabling the NT Scheduler service. The trick involves using the NT Scheduler service to start the Registry editor and scheduling regedt32.exe to launch on the desktop at some predetermined time. By default, NT Scheduler runs under the user security context of the SYSTEM account. Thus, any program NT Scheduler launches has full system authority, including full access to the SAM database. Guarding against this risk is tough because you need to disable the service. Disabling NT Scheduler isn't always possible because a given system might require the service for routine tasks. If you can't disable the NT Scheduler service, consider configuring it to run under the user context of a user with only enough authority to perform any scheduled actions.

Using system key technology. Additionally, you can employ Microsoft's system key technology to further protect the SAM. This technology made its first appearance as part of a post-Service Pack 2 (SP2) hotfix, but system key technology made a bigger splash in SP3. (For information about SP3, see "Service Pack 3 Is Really Security Pack 3," August 1997.) In a nutshell, system key technology helps protect NT and its passwords by encrypting the SAM database and requiring the use of an encryption key to boot the OS.

You have three options for managing the system key:

• Use a machine-generated random key as the system key, and store the key on the local system using a complex obfuscation algorithm.
• Use a machine-generated random key, and store the key on a disk.
• Use an administrator-chosen password to derive the system key.

For more details about each of these options, see the Microsoft article "Windows NT System Key Permits Strong Encryption of the SAM" (http://support.microsoft.com/ support/kb/articles/q143/4/75.asp).

Although the system key helps protect the SAM, you need to understand several concepts before you dive in and install it. Be aware that after you apply syskey.exe to a machine, no uninstall process exists, so carefully consider which key storage method is best for your network. After you install syskey.exe on a system, you must immediately make a new Emergency Repair Disk (ERD)—if you don't, you won't be able to adequately recover the system if you need to.

One real benefit of the system key is that if attackers manage to obtain a copy of your SAM database, they won't be able to extract valid password hashes. Attackers won't be able to use tools such as L0pht Heavy Industries' L0phtCrack to crack the passwords. Be aware that the system key won't stop users logged on with administrative authority from dumping the SAM database into a crackable format for use with tools such as L0phtCrack, so assign administrative authority carefully. For example, the Pwdump2 utility correctly extracts password hashes out of the SAM database even with the system key applied. Be aware of the potential risk such tools present.

Another benefit of a system key is that it can let you detect a little-known form of system attack in which people use bootable disks to gain access to the system. Of course, the attack is possible only where you can boot an NT system disk. But if the system boots, an attacker can move the SAM database to another location, then reboot the machine. When the system reboots, NT finds no SAM database and subsequently creates a new one that contains only two accounts: Administrator and Guest—both with blank passwords. Obviously, the attacker can now log on as Administrator using a blank password, do whatever he or she wants, then reboot with the disk and return the original copy of the SAM database to where it belongs.

With the system key installed, detecting this attack later is easy. If you have a system key applied when the machine boots, NT won't present the regular Logon dialog box. Even the most distracted administrator needs to notice this abnormality and immediately begin researching the problem.

Auditing the SAM. In any case, the prudent administrator needs to enable auditing of the SAM database to detect any suspicious activity in a timely manner. Of course, auditing requires that you monitor your event logs regularly and carefully. To enable auditing of the SAM, follow the steps in the sidebar "Setting Up Security Auditing." The Microsoft article "Enable Auditing of Microsoft Windows NT Server Password Registry" (http://support.microsoft.com/ support/ kb/articles/q186/3/74.asp) also outlines these steps. Although you can enable auditing of the SAM database, auditing won't occur when someone boots the system from another OS.

At this point, you've applied the changes necessary to initiate auditing on the entire runtime SAM database. The event log will contain information revealing successful and failed access attempts on these SAM keys. But this information serves no purpose unless you monitor your logs carefully.

Enabling this level of auditing can generate a large number of log entries because the security subsystem accesses these keys repeatedly during normal system operation. Therefore, be sure to adjust your log settings to accommodate the larger number of entries and adjust any event log monitor tools you're using.

Programs running under the context of powerful accounts, such as Administrator or SYSTEM, can manipulate event logs and other items. Savvy intruders can easily remove traces of activity.

SAM on Storage Subsystems
NT can store the SAM database on a variety of storage subsystems, including disks, tapes, and hard disks. Copying the SAM database onto a disk or tape requires initial user intervention—this practice isn't ordinarily part of NT's operation. During day-to-day operations, NT is likely to store the SAM database in two places on a hard disk: the %systemroot% repair directory and the %systemroot%system32\config directory. Although the \config directory contains a working version of the SAM database that the live OS uses, programs such as Windows Explorer can't directly access the database for copying while the system is running. This inaccessibility results from the fact that the Local Security Authority (LSA) system process (lsass.exe) has locked the file for exclusive use.

But someone can still use an NT boot disk to copy the file. In such an instance, an intruder can shut down the system, reboot with a disk, and copy or move the SAM database. Here again, a system key can help protect the SAM against disk-based attacks because it has encrypted the SAM database. The same is true for backup tapes, in which any copy of a system key-encrypted SAM extracted from tape is basically useless to an attacker. Nonetheless, keep backup tapes under lock and key to safeguard against tape loss, tampering, and information extraction.

The \repair directory contains the same information as an ERD, which you create using rdisk.exe and use for system recovery. Both the \repair directory and the ERD contain copies of the SAM database and require ample protection. Protect your ERD with the same security as your backup tapes.

To protect the \repair directory, set the permissions to disallow unwanted users from accessing the directory and its files, especially the sam._ file, which contains a copy of the SAM database. To protect files in the \repair directory, carefully perform the following steps using cacls.exe from the Microsoft Windows NT Server 4.0 Resource Kit, or a similar tool.

Open a command prompt, navigate to %systemroot% (usually C:\winnt), and type

cacls repair /g administrators:F system:F /t

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!