[104] in Best-of-Security
BoS: Alert: Suggestions to safeguard against SAM attacks
daemon@ATHENA.MIT.EDU (Russ)
Fri Apr 4 19:24:18 1997
Date: Fri, 4 Apr 1997 01:20:52 -0500
Reply-To: Windows NT BugTraq Mailing List <NTBUGTRAQ@RC.ON.CA>,
Russ <Russ.Cooper@RC.ON.CA>
From: Russ <Russ.Cooper@RC.ON.CA>
Errors-To: best-of-security-request@suburbia.net
To: best-of-security@suburbia.net
Resent-From: best-of-security@suburbia.net
Recently, the algorithm for reversing the obfuscation step of encrypting
an NT user ID's password was published. This has resulted in a great
deal of discussion over the relative security of Windows NT systems.
This article intends on providing you, the NT Administrator, with
sufficient information and understanding to ensure you are able to
DETECT an attempt to exploit your systems using this algorithm.
Q: What's this all about?
A: When a password is stored on Windows NT, it is stored in encrypted
form. The clear-text password is first encrypted using keyed MD4, it is
then encrypted again using an obfuscation method. Once obfuscated, it is
stored within the NT registry. The keyed MD4 version of the password can
be used to create a valid challenge response for its user ID. Therefore,
should access to this value be obtained, it would be possible to connect
to an NT resource authenticating as that user ID despite not having the
clear-text password for that user. Since the method of de-obfuscating
has now been published, and since its possible to view the keys which
store the encrypted passwords, its possible that this could be done.
Q: But someone must compromise the Administrator account first, right?
A: Yes, but. as Les Landau quickly pointed out, the entire Security
Access Manager (SAM) database is backed up whenever the Emergency Repair
Disk (ERD) is updated. Since updating the ERD is good practice, its
likely that your SAM has been backed up. By default, the backed up SAM
is stored in the file %systemroot%\repair\sam._ , and this file, by
default, allows the group EVERYONE read access. It would be possible to
retrieve the encrypted passwords from this file rather than from the
live registry. The live registry requires Administrator, Administrator
Group, or Backup Operator privilege in order to access the password
keys. The backed up SAM in the \repair directory does not.
Q: Ok, so once I've protected the SAM._ file, then the only other way my
machine can be exploited is by fooling the Administrator, right?
A: The Administrator, members of the Administrators Group, the Backup
Operator, and anyone who has been granted the privilege to backup and
restore files, all have the ability to access this information.
Furthermore, anyone who can start the Scheduler Service also has the
ability to view these entries (this will be explained in detail below).
Finally, despite the amount of discussion that has been held on the
topic, there is still a community of people who do not appreciate the
threat of the Trojan program. Fooling the Administrator is becoming
easier as the web interface technology evolves. Double-clicking may not
be necessary to execute an application, and its possible for some
applications to launch themselves if reckless acceptance of Authenticode
certificates has taken place. Administrators may be logging into user's
workstations, and if that workstation has not had security controls in
place, it's possible that the owner has put programs in the "All Users"
Startup group, thereby making them execute as the Administrator when
he/she logs on to the workstation.
As Microsoft have already said, it cannot be emphasized enough that the
use of the Administrator user ID should be strictly controlled and
minimized in every way possible. So to the Backup Operator account.
Users who have been made members of the Administrators group should
similarly be tightly controlled. The most common reason for these types
of permissions is a lack of effort to properly configure user IDs which
can access the necessary resources as something other than members of
the Administrators group. As these accounts have virtually limitless
abilities (since that is their purpose and design), their use must be
controlled.
Q: Ok, but what if I want to have users of the Administrators group be
able to use those accounts for their everyday work?
A: Obviously this is a common situation in NT environments today. You
should change it. However, in the meantime, if you are willing to accept
the risks that are associated with having such powerful accounts using
untrusted programs, you can rely on auditing to alert you to attempts to
exploit your systems. Unfortunately, due to your acceptance of the
risks, you may not be able to prevent the exploits, but you will be able
to find out that they have taken place. Auditing, by default, is not
turned on in Windows NT. In order to record security events as they
occur, you have to enable it. Below you will find detailed instructions
on how to establish security auditing, and in particular, how to audit
access to the sensitive areas containing the passwords.
However, just auditing is not enough. Once enabled, you also have to
review the event logs regularly and be able to understand what those
events mean. In addition, it should be understood that audit events are
recorded on the machine at which they occur, they are not distributed
throughout a domain. So if you have a Backup Domain Controller in
Toronto, and your Primary Domain Controller is in Lindsay, you will need
to collect the event logs from both locations and review them to
determine if your passwords have been violated. Either of these machines
could be attacked and pose an equal risk, but only the machine which is
attacked will record the security audit event. There are a variety of
programs available for NT which can do event monitoring, collection, and
alert notification. If you are seriously interested in such a tool,
contact me privately and I'll give you a list of currently available
products. Unfortunately none of them are inexpensive, but their costs
pale in comparison to the cost of trying to do this event work in a
large scale environment manually.
RECOMMENDATION #1 - How to secure the %systemroot%\repair\sam._ file
By default, the SAM._ file has the following permissions;
Administrators: Full Control
Everyone: Read
SYSTEM: Full Control
Power Users: Change
1. From within Explorer, highlight the SAM._ file, right click, choose
properties, security, permissions. Remove all privilege from this file.
2. From a DOS prompt, execute the following;
cacls %systemroot%\repair\sam._ /D Everyone
This will deny the group Everyone permission to the file, ensuring that
no other permission (i.e. inherited permissions from a share) can
override the file permission.
2. Whenever you need to update your ERD, first execute the following
from a DOS prompt;
cacls %systemroot%\repair\sam._ /T /G Administrators:C
This will grant Administrators change permission to update it during the
ERD update.
3. Once the ERD has been updated, execute the following from a DOS
prompt;
cacls %systemroot%\repair\sam._ /E /R Administrators
This will once again remove the permissions for Administrator
RECOMMENDATION #2 - How to enable auditing on password registry keys
1. First you have to make sure auditing is enabled. Start User Manager,
Policies, Audit, and click "Audit These Events".
2. By default, Windows NT does not identify any users or groups to audit
on any objects within the system. Auditing can add performance overhead
to your system depending on the available resources, so care should be
taken in determining what and whom to audit. For a full description of
auditing in Windows NT, I recommend the Microsoft Press book "Windows NT
3.5 - Guidelines for Security, Audit, and Control", ISBN 1-55615-814-9.
Despite its title it is still the most comprehensive coverage of
auditing that I have read. For the sake of this example, we will simply
check every Success and Failure checkbox.
3. Close the dialog.
4. Now for a little known trick. While logged on as Administrator,
ensure that the Schedule service is set to start up as the System
account. Once set, start the Schedule service.
5. Check the time, and then open a DOS prompt. At the DOS prompt, type
in the following;
at 22:48 /interactive "regedt32.exe"
where 22:48 gets replaced with the current time plus 1 minute (or 2 or
whatever amount of time you think it will take you to type in the
command).
6. At the designated time, regedt32.exe will fire up and appear on your
desktop. This incarnation of regedt32.exe will be running in the
security context of the user SYSTEM. As such, you will be able to see
the entire registry, every key within the SAM or Security trees. BE VERY
CAREFUL HERE.
7. All we want to do is enable auditing on the designated keys, nothing
else. To this end, we highlight the HKEY_LOCAL_MACHINE windows within
regedt32. Next highlight the SAM tree. Choose the Security menu item,
then Auditing.
8. Click on the Add button and choose Show Users.
9. I'm going to recommend that you add the SYSTEM user, the group Domain
Admins, and the user Administrator. You want to cover any account which
has the right to;
- "Take ownership of files or other objects"
- "Back up files and directories"
- "Manage auditing and security log"
- "Restore files and directories"
- "Add workstations to domain"
- "Replace a process level token"
10. Click the Audit Permission on Existing Subkeys
11. Next, click in the Success and Failure checkboxes for the following
entries;
- Query Value
- Set Value
- Write DAC
- Read Control
12. Choose OK, and then Yes.
13. Repeat the process for the Security tree.
14. Close regedt32.exe and stop the Schedule service. I'd recommend that
you not leave this service configured to start up as System, but instead
change it to run as some other user with less privilege.
You will now have applied auditing to the entire SAM ensuring you'll be
notified via the Event Logger of any failed or successful access to your
sensitive information by the only accounts which have the ability to
access such information.
The issue of what to do when/if you discover event notifications is
beyond the scope of this document. Part of a good security policy is an
appropriate audit policy which would dictate how the event logs are
reviewed, how the information is verified, and what actions should be
taken for each possible event. Refer to the book I've recommended above
for information on how to establish such a policy, or contact a
consultant capable of defining and implementing such a policy within
your organization (not me, my plate's full thanks).
Contributions to this document have come from Scott Field and Paul Leach
of Microsoft, as well as input from Jeremy Allison and Les Landau. All
are gratefully acknowledged for their efforts. This document has been
provide to the members of the NTBugTraq mailing list
(http://ntbugtraq.rc.on.ca/) as a service. Permission to redistribute
this information for your internal use is granted by the author.
Publication in public form beyond the NTBugtraq mailing list is strictly
prohibited.
Copyright (c) 1997 by Russ Cooper, all rights reserved.
Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security
owner of the NTBugTraq mailing list:
Send SUBSCRIBE NTBUGTRAQ Yourname to Listserv@rc.on.ca
