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

   Previous  [1]  2  Next