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.. I
Trang 1Protecting 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
Trang 2Windows 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
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,
Trang 3Print 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
Trang 4 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
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
Trang 5An 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
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)
Trang 6Table 9.2: Recommended Settings for the Password Policy
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
Trang 7Table 9.2: Recommended Settings for the Password Policy
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