Tài liệu Protecting SAM and Security Hives phần 1 pptx

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