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.

Note 

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.

Note 

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).

click to expand
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.

Note 

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". NTFSDOS, 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.

Note 

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).

click to expand
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).

click to expand
Figure 9.20: Weak passwords are cracked by LC4 within a matter of minutes

Note 

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).

    click to expand
    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).

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 letters, numbers, and keyboard special characters.

Enabled.

 

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.

Table 9.3: Recommended Settings for the Account Lockout Policy

Setting

Description

Recommended setting


Account lockout duration

The number of minutes a locked-out account will stay locked out. If this is set to 0, the account will have to be unlocked by an administrator or someone who has been given the right to do so.

30 minutes

Account lockout threshold

The number of incorrect attempts at guessing a password that can be made before the account is locked out.

5 invalid logons

Reset account lockout counter after

The number of minutes after which the count of invalid logon attempts will be reset. If the number of minutes between one invalid logon and another is greater than the number of minutes to which this setting is configured, the previous invalid logon attempts won't matter.

10 minutes

Note 

A good password policy is essential to network security, but, unfortunately, it is often overlooked. Here are several tips about the worst practices that you should avoid under all circumstances:

  • Do not create local Administrator accounts (or common domain-level administrator accounts) using a variation of the company name, computer name, advertising tag lines or dictionary words, such as %companyname%#1, win2k%companyname%, etc.

  • Do not create new user accounts with simple passwords that aren't required to change the password after the first logon.

Be aware that none of the above-described settings can force your end users to create strong passwords. Similarly, even the strongest password policy can prevent users from writing down their passwords and attaching a note to their monitors, sharing passwords with other users, or complaining to management when they have to get help to reset a password they have forgotten.

Protecting the Local Administrator Account

When your Windows NT-based system is joined to a domain, the local Administrator account is still present (as was already mentioned, it resides in (%SystemRoot%\System32\Config\SAM). Actually, members of the Domain Admins group can administer the local system only because this group is added to the local Administrators group. Hence, it is necessary to protect the local Administrator's account from unauthorized use or misuse. This goal could be achieved by taking the following protective steps:

  • As aforementioned, physical security is essential. Although this recommendation might seem elementary, you must not overlook such obvious things. As statistics have shown, most security incidents in corporate environments occur from the inside. Therefore, it is necessary to physically secure all servers (they should be placed in a physically secure room with monitored access) and critical workstations (consider locking the cases or using removable hard drives that are locked up at night). On physically unsecured systems, disable the ability to boot from a CD or floppy. Also, for extra security, disable AutoRun functionality for CD-ROM drives on physically insecure systems. Finally, when considering physical security, do not forget about securing your backup media.

  • Use NTFS on all partitions. For Windows 2000, Windows XP, and Windows Server 2003, enable EFS (Encrypting File System)—a built-in powerful encryption system, which adds an extra layer of security to drives, folders, or files. Be sure to enable encryption on folders, not just files. All files that are placed in that folder will be encrypted. In particular, it is recommended that the user encrypt the TEMP folder, which is used by applications to temporarily store copies of files being modified (notice that applications do not always clean that folder after closing the files).

  • Restrict the number of unnecessary user accounts, such as any duplicate user accounts, accounts created for testing purposes, shared accounts, etc. Most generic accounts have weak passwords and provide lots of unnecessary access rights. In Windows NT 4.0, disable the Guest account. Although Windows 2000 and its successors disable the Guest account by default, it is still recommended that you make sure that someone has not enabled it. For additional security, assign a complex password to the account anyway, and restrict its logon hours.

  • Restrict the addition of local accounts to the local Administrators group, and require a strong password for the local Administrator account. Rename the Administrator account. Although this won't stop qualified intruders (they will use the SID to find out what is the name of the Administrator account), it will still result in a time delay. When renaming the local Administrator account, try to avoid using the word "Admin" in its name. Also, consider creating a dummy account named "Administrator", having a long, rather complex password and no privileges. Enable auditing on this account to get information when someone is tampering with it.

  • Shut down and disable unnecessary services, since they take up system resources and can open holes into your operating system. IIS, RAS, and Terminal Services have security and configuration issues of their own, and should be implemented carefully if required. You should be aware of all the services that run on your servers and audit them periodically. Also, on Windows 2000 systems, it is recommended that you remove OS/2 and POSIX subsystems if you do not use them (and, in fact, they are used quite rarely). Removing these subsystems will improve performance and reduce potential security risks. To remove the OS/2 and POSIX subsystems, delete the \%SystemRoot%\system32\os2 directory and all of its subdirectories, then use the Registry Editor to remove the following registry entries: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for NT key with all its subkeys, the Os2LibPath entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, the Optional entry and all entries for OS2 and POSIX under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems. The changes take effect the next time the computer is started. You might want to update the emergency repair disk to reflect these changes.

  • Disable DirectDraw. Here one should notice that disabling DirectDraw will impact the programs that actually require it (mainly, these are modern games), but it will not influence most business applications. Furthermore, this will prevent direct access to video hardware and memory, which is required by the basic C2 security. To do this, go to the HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\DCI registry key and set the Timeout value (REG_DWORD data type) to 0.

  • Disable the default hidden shares. Windows NT-based systems create hidden shares that are used by the SYSTEM account (also hidden). All Windows NT-based operating systems open hidden shares on each installation for use by the system account. However, you can view all shared folders on your computer by typing the net share command from a command prompt. There are two methods of disabling the default shares—first, you can stop or disable the Server service, which removes the ability to share folders on your computer. To use the second approach, edit the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters registry key. For server platforms, create the AutoShareServer value (REG_DWORD) and set it to 0. For workstations, create the REG_DWORD value named AutoShareWks and set it to 0. Keep in mind, however, that this security measure might cause problems with applications.

  • Restrict anonymous access to the computer. Anonymous users or services that log on anonymously are automatically added to the Anonymous Logon built-in security group (S-1-5-7). In earlier versions of Windows NT, such users or services were able to access many resources (sometimes in cases where access should have only been granted to authenticated users). Starting with Windows 2000, Microsoft introduced stricter security settings which prevent anonymous access to all resources, except for those who have been explicitly assigned access. You can do this by using the Local Security Policy MMC snap-in or by editing the registry directly. To achieve this purpose using Local Security Policy, one had to select the Additional restrictions for anonymous connections option under Security Settings | Local Policies | Security Options, and then setting the No access without explicit anonymous permissions option. To do the same thing by editing the registry directly, it was necessary to create the REG_DWORD value named RestrictAnonymous under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA registry key and set this value to 0x2 (Hex).

In addition to these standard protective measures, Windows XP and Windows Server 2003 include a set of powerful new security features, which will be briefly considered in the following few sections.

Windows XP and Windows Server 2003 Enhancements and Compatibility Issues

Windows XP and Windows Server 2003 have gone even further than Windows 2000 in tightening the security system, and introduced a range of additional protective steps. However, it is necessary to mention that if you decide to use them, this might cause some administrative inconvenience, especially in mixed environments. Therefore, you must test them carefully before deploying them.

Restricting Anonymous Access

In contrast to previous versions of Windows, the access token for anonymous users no longer includes the Everyone security group. Therefore, the access token for anonymous users contains SIDs for:

  • Anonymous Logon

  • The logon type (usually Network)

When an anonymous user tries to access a resource on a computer that is running Windows XP, he or she is not granted permissions or group memberships that are available to the Everyone security group. The SID for the Everyone security group is present in the anonymous user's access token. It should be noted that in most cases this restriction is desirable and appropriate. However, in some situations, for the sake of backward compatibility, you may need to include the Anonymous Logon security group into the Everyone group. For this very purpose, Windows XP and Windows Server 2003 have introduced a new registry value, EveryoneIncludesAnonymous, which can be set using the methods described below.

To enable anonymous access via MMC, proceed as follows:

  1. Start the Local Security Policy MMC snap-in, expand the Security Settings tree, then select Local Policies | Security Options.

  2. Double-click Network access: Let Everyone permissions apply to anonymous users. By default, this policy setting is disabled (Fig. 9.22).

    click to expand
    Figure 9.22: Setting EveryoneIncludesAnonymous registry value via Local Security Policy

  3. To enable anonymous users to be members of the Everyone security group, click Enabled. To prevent the inclusion of the Everyone security group SID in the anonymous user's access token (the Windows XP and Windows Server 2003 default), click Disabled.

To set the EveryoneIncludesAnonymous registry value by using Registry Editor, proceed as follows:

  1. Start Regedit.exe and locate the following registry key:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  2. Right-click EveryoneIncludesAnonymous, and then click Modify.

  3. To enable anonymous users to be members of the Everyone security group, in the Value data box, type 1. To prevent the inclusion of the Everyone security group SID in the anonymous user's access token, type 0.

  4. Quit Registry Editor.

Disabling the Administrator Account

This security option is only available in Windows XP and Windows Server 2003 and lets you disable the local Administrator account. To do so, simply right-click the local Administrator account, and select the Disable account command from the context menu. In contrast to previous Windows NT-based systems, where local Administrator accounts could not be disabled, Windows XP and Windows Server 2003 will allow you to do this (Fig. 9.23). This option is rather useful, since it eliminates the possibility of misusing the Administrator password.

click to expand
Figure 9.23: Disabling the local Administrator account

Note 

Because members of the Domain Admins group have administrative authority on computers joined in their domain, you still maintain the ability to administer the system. Also, the Administrator account will remain enabled when booting in safe mode.

Selecting this feature, however, can have some interesting side effects. For example, if you change the password policy after disabling the Administrator account, and this account no longer meets the policy requirements, your attempt at reenabling it will fail. In this case, another administrator must log on and reset the Administrator account password. If there are no other administrative accounts, you will have to reboot to the safe mode to fix the problem.

Limiting Local Account Use of Blank Passwords to Console-Logon Only

Admittedly, the password policy should prevent the use of blank passwords entirely. However, you should recall that someone who has the password to the local Administrator's account (or other account with membership in the local Administrators group) could modify the local account and password policy to permit blank passwords and modify an account in order to use it. When the use of blank passwords is limited to console logon only (an option for only Windows XP and Windows Server 2003 systems), an account with a blank password cannot be used for network logon. The user must work on the Windows XP or Windows Server 2003 system in which the account exists. You have effectively prevented an intruder from using the local Administrator account (or any other privileged account) to access files, folders, registry keys, and so on, on this machine. This configuration also prevents applications such as FTP, Telnet, and terminal services from using an account with a blank password. However, Microsoft advises that applications requiring remote access be written to bypass this setting.

Security Through Obscurity

Of course, security through obscurity will not work, if obscurity is your only line of defense. However, making things more difficult for attackers is a useful practice, especially when it comes to protecting the local Administrator account. The option allowing one to rename this account existed already in Windows 2000, and remains a part of Windows XP and Windows Server 2003. However, as was mentioned earlier, it won't stop a qualified intruder, since the task of determining which of the accounts is the local Administrator's account would not be too difficult. Being well aware of this weak point, Microsoft has introduced several new protective measures, intended to make this harder. They can be enforced via Group Policy (under Local Policy | Security Options). The list of these new policies includes:

  • Network access: Allow Anonymous SID and Name Translation. When this setting is enabled, the system will answer anonymous requests for the name of the account associated with SID belonging to the local Administrator account. Since the local Administrator account is associated with the well-known SID, the task of determining the new name of this account becomes trivial. If you disable this setting, such an anonymous request will be denied. It is recommended that the user enable this setting for all domain-level accounts via the Default Domain Group Policy MMC snap-in. Local account settings can be different and may be set by changing this security option within a group policy linked to the specific organizational unit within which the machine account resides.

  • Network access: Do Not Allow Anonymous Enumeration of SAM Accounts. This Windows XP and Windows Server 2003 security option prevents anonymous access to a listing of Security Accounts Manager (SAM) accounts.

Note 

This option is useful in obscuring information about the domain, especially if your organization uses naming conventions for user accounts. If the attacker knows that your organization uses naming conventions, he or she can deduce the rules used in these conventions, and thus easily guess the correct account name for some employees. On the other hand, it has implications for trusts, because some functions require the ability to anonymously list accounts. For example, the administrator of a trusting domain must be an authenticated user of a trusted domain in order to perform administrative tasks such as accessing the list of accounts of the trusted domain when assigning access to resources to trusted domain users. Actually, when performing such tasks, Windows Server 2003 prompts for and account and password for the trusted domain.



Windows Server 2003 Registry
Unicode Explained
ISBN: 1931769214
EAN: 2147483647
Year: 2005
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net