Protecting SAM and Security Hives Windows NT/2000, Windows XP, and Windows Server 2003 security information is stored in the SAM (Security Accounts Manager) and Security registry hives. N ote Although starting with Windows 2000, Microsoft has introduced the Active Directory (AD)—arguably the most complex of new technologies, which in some ways represents a further extension of the system registry, the SAM database has retained its importance. In contrast to Windows NT 4.0 domain controllers, where SAM used to be simply a registry hive, on native-mode Windows 2000 and Windows Server 2003 domain controllers, the directory services database is stored in the Ntds.dit file. The SAM is now part of the Active Directory, which serves as a kind of "super-registry", storing all user and machine information, as well as a whole host of other types of objects, including group policies and applications. However, the SAM database continues to store local accounts (required to log on locally). Furthermore, if your computer that is running Windows 2000, Windows XP or Windows Server 2003 does not participate in a domain, the SAM database remains the main storage of the user and group accounts information. Among other things, it is important to notice that the Directory Service Restore Mode Administrator password, which is separate from the Administrator password that is stored in the Active Directory, resides in the local SAM (%SystemRoot%\System32\Config\SAM). The SAM hive contains user passwords as a table of hash codes; the Security hive stores security information for the local system, including user rights and permissions, password policies and group membership. N ote The SAM information is encrypted. However, there are many utilities that allow you to crack the SAM hive. The most common examples are PWDUMP, NT Crack, and L0phtCrack (at the time of this writing, the latest version was LC4). How to Protect the SAM Hive Microsoft officially states that the best way to protect Windows NT/2000, Windows XP, and Windows Server 2003 is to protect administrative passwords. This, however, isn't enough. Many users can access the SAM and Security hives, including members of the Backup Operators group, whose responsibility is registry backup. By default, no user (not even the Administrator) has the necessary access rights that would allow them to access or view the SAM database using the registry editor. However, the SAM and Security hives are stored on the hard disk, the same as all the other files. All you need to do is to get the copies of these files. Of course, you can't do this by simply copying the registry of the running Windows NT/2000, Windows XP, or Windows Server 2003 system. If you make such an attempt, you'll get an error message (Fig. 9.18 ). Figure 9.18: When an attempt to copy the registry of the running Windows NT/2000, Windows XP, or Windows Server 2003 operating system is made, the system displays an error message However, there are tools such as Regback included with Windows NT 4.0 Resource Kit and REG included with newer releases of the Resource Kit. By using these tools, members of Administrators or Backup Operators groups can obtain copies of the registry even if the system is up and running. If Windows NT-based operating system is installed on the FAT volume, then anyone who can reboot the system and has physical access to the computer can copy the system registry. They need only to reboot the system, start MS-DOS or Windows 9x/ME, and copy the SAM and Security hives from the %SystemRoot%\System32\Config folder. N ote If Windows NT/2000, Windows XP or Windows Server 2003 is installed on NTFS volume, you can use the NTFSDOS utility for copying the SAM and Security hives (you can download it from http://www.sysinternals.com/ntfs30.htm ). NTFSDOS mounts NTFS volumes under DOS. This utility and its clones (for example, NTFS for Windows 98) cause different, and sometimes negative, reactions (because of the potential risk to the security subsystem). When the first version of NTFSDOS appeared, Microsoft had to state officially that "true security is physical security". N TFSDOS, though, is one of the most useful tools for registry backup and recovery and may be very helpful when performing emergency recovery (especially if this has to be done very quickly). After all, whatever can be used for good, can also be used for evil. To summarize, in order to protect the SAM and Security files from unauthorized copying, you need to provide true physical security for the computers you need to protect. Also, don't assign every user the right to reboot the system. N o t e By default, this privilege is assigned to Administrators, Backup Operators, Power Users, and Users on Windows 2000/XP workstations. On member servers, it is assigned to Administrators, Power Users, and Backup Operators. On domain controllers, it is assigned to Administrators, Account Operators, Backup Operators, Print Operators, and Server Operators. To edit the user permissions in Windows 2000, Windows XP, or Windows Server 2003, log onto the system as a member of the Administrators group, open the Control Panel windows, start Administrative Tools and select the Local Security Policy option. Expand the MMC tree and select the User Rights Assignment option. The list of user rights will appear in the right pane of this window (Fig. 9.19 ). Figure 9.19: The list of user groups allowed to reboot the system (Windows Server 2003 domain controller) Now, can we say that the Windows NT-based system is secure? No, we can't, because there are backup copies of the registry. In Windows NT 4.0, backup copies of the registry are created immediately after a successful setup or whenever you start the Rdisk/s command. The backup copies of the registry are stored in the %SystemRoot%\Repair directory. Backup copies of the Windows 2000/XP/ Windows Server 2003 registry are created whenever you backup the System State Data. As you may recall, all this information is stored in the %SystemRoot%\ Repair\Regback folder. These files aren't in use by the system, and any user who has appropriate access rights can copy them. In Windows NT 4.0, system's NTFS access rights don't protect the %SystemRoot%\Repair directory. Every user has Read access to this directory, and that's enough to copy the files. In Windows 2000, Windows XP and Windows Server 2003, the Users group by default only has the List permission for this directory, and this permission doesn't allow you to copy the files. If you installed your system as an upgrade from earlier versions of Windows NT, though, access rights to the registry and file system objects might be inherited from the previous system. Thus, to prevent unauthorized copying of the SAM and Security files, you need to do the following:  Don't assign end users permission to log on locally on the servers.  Whenever possible, use NTFS file system.  Provide physical security for all servers.  In Windows NT 4.0 and in Windows 2000/XP systems upgraded from earlier Windows NT versions, restrict access rights to the %SystemRoot%\Repair folder.  Secure the backup copies of the registry and emergency repair disks (Windows NT 4.0) or System State Data (Windows 2000, Windows XP, and Windows Server 2003). You may ask "But what happens if someone steals my SAM and Security hives?" The answer is very simple: You don't need serious hacking skills to crack the stolen SAM. If you have these files at your disposal, you can make any number of dictionary or brute- force attacks. And if you have LC4 at your disposal (which can be downloaded from http://www.atstake.com/lc4 and represents a new version of the well-known L0phtCrack password-auditing tool), your success mainly depends on the quality of the dictionary you use (Fig. 9.20 ). Figure 9.20: Weak passwords are cracked by LC4 within a matter of minutes N ote Imagine that you want to hack your own SAM hive (and then try to do it). Remember, your tasks are significantly easier than those of a hacker, because you don't need to plan a remote attack to steal the SAM and Security hives. If you can crack some passwords automatically, explain to the users who've specified these passwords that they're compromising system security. Thus, to protect the system, you need to:  Ensure a strong account policy (or, at least, prevent users from setting blank passwords and require that passwords be at least 8 characters long, use arbitrary combinations of letters and digits, and specify the system policy in relation to password complexity).  Pay special attention to protecting the local Administrator account from misuse. Ensuring Strong Account Policy in Windows Server 2003 An account policy is a collection of settings that influence user accounts and their ability to authenticate the system. In other words, the account policy sets the standards for initial access to the system and includes every setting that controls access in any form (including file permissions, system objects permissions, dial-up permissions, and so on). If account and password policies are set correctly, this will prevent many attempts of intrusions into your system. To create, examine, or set strong account and password policies in Windows Server 2003, proceed as follows: 1. Click Start, select Run, and type secpol.msc in the Open field, then click OK, or, alternately, open the Control Panel window, and select Administrative Tools | Local Security Policy. 2. Expand the console tree and navigate to the Account Policy container (Fig. 9.21 ). Figure 9.21: The default settings of the account policies in Windows Server 2003 Notice that default account policies are far from perfect, and most security professionals recommend that they be strengthened. The recommended settings are summarized in Tables 9.2 and 9.3. Table 9.2: Recommended Settings for the Password Policy Setting Description Recommended setting Enforce password history Unfortunately, most end users just hate having to remember their passwords. Even if the administrator encourages them to change passwords frequently, they try to bypass this limitation by changing the password and then immediately returning to an old and familiar one. Enforcing this policy will prevent them from reusing their passwords. Note that this policy alone won't work, because it must be supported by the Minimum password age policy. 13 passwords remembered (the default setting instructs the system to remember 3 passwords). Table 9.2: Recommended Settings for the Password Policy Setting Description Recommended setting Maximum password age Setting the Password never expires checkbox in the user account properties when creating or editing user accounts is not a good idea. In order to minimize chances that an intruder will use a password that has been guessed or cracked, it is necessary to have users periodically change their passwords. The default value is 42 days, but in sensitive environments it is recommended that users reduce this value. Minimum password age As was already mentioned, this setting supports the Enforce password history policy. If you don't change the default value (0), then the user will immediately be able to change the password in order to return to the original one. At least 5 days. Minimum password length As was shown by the example presented in Fig. 9.21, password-cracking tools crack weak passwords in a matter of minutes. Although there is no common opinion about what password length is best, it is still recommended that you make the password at least 8 characters long. Note that in Windows Server 2003 the default UI can handle more than 14 characters. Although with the original LAN Manager password hashing, a 14-character password was no harder to crack than two 7- character parts, the introduction of NTLMv2 and Kerberos management of password- hashing has eliminated this shortcoming. Also notice that recently published security reports state that most contemporary password crackers use the 8-eight character standard as a starting point. At least 8 characters. Password must meet complexity requirements Although this setting does not prevent users from using dictionary words as their passwords or including numbers at the end and upper-case letters at the beginning of the passwords (all these habits simplify brute-force attacks), it is recommended that the user enable this policy. When this setting is enabled, the newly-created password must satisfy three out of four of the following requirements: upper- and lower-case Enabled. Table 9.2: Recommended Settings for the Password Policy Setting Description Recommended setting letters, numbers, and keyboard special characters. This is important, since password-cracking utilities are gradually becoming more and more advanced. For example, the newest version of LOphtCrack, LC4, implements an improved hybrid cracking mode that can both append and prepend characters to dictionary words, and look for common substitutions — if the dictionary word is "password", it will also crack "password!", "!password", or even "#$p@$$wOrd^% ". Store password using reversible encryption If you want to tighten security on your server, don't turn this setting on. It is available for a single purpose — to provide compatibility with non-Microsoft clients that do not support newer Windows authentication process (therefore, such clients must be able to decrypt passwords). Use this setting only if necessary (i.e., if you have such clients in your network environment). Disabled. . Protecting SAM and Security Hives Windows NT/2000, Windows XP, and Windows Server 2003 security information is stored in the SAM (Security Accounts. to access or view the SAM database using the registry editor. However, the SAM and Security hives are stored on the hard disk, the same as all the other