COMMAND
SAM
SYSTEMS AFFECTED
Win NT (all versions up through 4.0)
PROBLEM
The following text is taken from CERT advisory H45.
Windows NT stores user information in the Security accounts
Manager (SAM) database. Specifically, encrypted passwords are
stored in the SAM._ file of the NT Registry, in the systemroot
directory (The NT Resgistry is a database of information
replacing the .ini files used in the Windows 3.X environment).
Passwords are encrypted by a two part process when stored in the
NT registry. First, passwords are hashed using the RSA MD4
scheme, then they are further obfuscated using DES encryption.
Typically, access to the NT Registry is limited to the
Administrator account. However, a back-up copy of the SAM._ file
is normally created whenever the Emergency Repair Disk is updated
and is stored in %systemroot%\repair\SAM._. The group "Everyone"
Paul, CIAC advisory bulletin H45 states that SAM_ (SECURITY_ and
the \repair folder too), allow EVERYONE READ access. Their has
Read permission by default on this back-up copy of SAM._ (. As a
result, "Everyone" has the potential to obtain or copy the
encrypted password file.
A utility which unscrambles the obfuscation scheme, revealing the
MD4 hashed password, has been released on the Internet. The
resulting RSA MD4 hashed password, along with a valid user-id,
can be used to log in to an account, without the plain-text
password. If the hashed password is deliberately placed on
another machine, the information could provide a valid value to
be used in the challenge-response authentication used with the
original NT resource where the hashed information came from. In
short, an intruder could use the information remotely to gain
unauthorized access to the NT resource.
A second possibility is that the clear-text password could be
determined if the hashed passwords are run through a password
cracker. Along with a valid user-id, an intruder could gain
unauthroized access.
SOLUTION
Check SAM #3 on this page (Security Bugware) for Microsoft
solution.
Although this vulnerability presents a serious threat,
appropriate security policy regarding configuration of NT
workstations can mitigate this type of attack. CIAC recommends
the following five configuration controls:
1. Disallow Remote Administrator capabilities
Configure the Administrator and Administrator Group accounts
so that access from the network is disallowed, allowing only
direct console access for Administrators. This can be
accomplished through the User Manager, Policies menu
selection. This eliminates attempts to remotely log in as
the Administrator. Physical access to the server console
would be necessary to conduct any administrative functions.
In addition, users should work with the least privileges
necessary to accomplish their work. Administrators should
not use Administrator accounts for non-administrative work.
2. Rename the Administrator account
The Administrator account should be renamed to something
other than Administrator to deter the casual "outsider"
looking for generically named accounts to compromise.
This has already been made useless, obtaining the name of the
Administrator account is trivial if access has already been
achieved. A renamed Administrator account can make "casual"
brute-force attempts weaker, but this alone is a false sense
of security.
What you should do is (and I give away a trick here) rename
the Administrator account, and then create a new account
called Administrator. Apply account lockout to every account
(including Administrator with the PASSPROP utility from the
Resource Kit), and then audit the hell out of the fake
Administrator account. I make sure that its a valid account,
with a strong password, and NOT disabled. This means that any
attempt to break into your system is almost certainly going
to result in an attempt to log on as Administrator. Since
that account serves no purpose (create a useless group and
add this fake account to it and set it as primary), any audit
notification that contains the user Administrator is an
intrusion, plain and simple.
3. Change the permissions on WINNT/repair/SAM._
The default permissions allow Full Control for Administrator
and SYSTEM, Read for Everyone, and Change for Power Users.
The permissions should be set so that no users or groups,
including Administrator, have any rights to this file. The
Administrator still has the authority to change these rights
if access is required to the file. If the Emergency Repair
Disk needs to be updated, the Administrator can temporarily
change the permissions to change the file. When the
Emergency Repair Disk is completed, the Administrator should
change the permissions back to no rights.
4. Audit Administrator account activities and Registry changes
Auditing will enable detection if a potential intruder is
launching this attack. Since this attack requires the
Administrator account privileges, the intruder will most
likely try to log in as Administrator. Therefore, the "logon
and logoff" failure should be enabled for the Administrator
account. In addition, auditing should be enabled for any
changes in permissions or modifications to the SAM. An alert
can be set to notify the Administrator if and when any of
these events occur.
5. Choose passwords at least 8 characters long that cannot be
found in any dictionary
As with any operating system, passwords are a common target.
This attack partially unscrambles the encrypted password,
then attempts to obtain a clear-text password through a
dictionary password cracking utility. To prevent this from
succeeding, passwords should be a combination of letters,
numbers and characters, at least 8 characters long and
"nonsensical". A good password is especially important on
the Administrator account. Since the Administrator account
cannot be locked out, a potential intruder can guess
passwords, or run a password cracking utility. A good method
for choosing passwords is to develop a phrase and take the
first letter of each word. For example, "Security is 4 the
good of all !" could result in the password, "S i 4 t g o a !".
Through limiting the Administrator account and privileges granted
to other user accounts, as well as enabling the described
auditing, the administrator can mitigate this attack.
David LeBlanc posted following script taht should help matters:
cacls %systemroot%\repair /t /g administrators:f /g system:f
cacls %systemroot%\system32\config /t /g administrators:f /g system:f
cacls %systemroot%\system32\BHSUPP.DLL /g administrators:f /g system:f
Note: bhsupp.dll is installed with the network monitor and
features an additional password which is obfuscated into it - if
that is present, this is a good thing to do - also, don't use
that password to allow access to anything else.