 |
 |
 |
 |
SAM attacks v1.1
In the interest of avoiding confusion, I have corrected some mis-use of encryption terminology in the document. In addition, some additions have been made to both recommendations. Future updates will be kept on http://www.ntbugtraq.com/SAMAttack.htm and the list will only be notified in the event of major changes.
Recently, the algorithm for reversing the obfuscation (obscuring) step of hashing 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 hashed [not encrypted] form. The clear-text password is first hashed using the RSA MD4 hash function, it is then obscured again using an algorithm (which has now been published). Once obscured, it is stored within the NT registry. The hashed MD4 version of the password (generally accepted as not reversible to clear-text) 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 removing the obfuscation step has now been published, and since its possible to view the keys which store the hashed passwords, its possible that this could be done.
Q: But someone must compromise the Administrator accout 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 directory, by default, allows the group EVERYONE read access. It would be possible to retrieve the hashed passwords from this file rather than from the live registry. The live registry requires Administrator, Administrator Group, or Backup Operator priviledge in order to access the password keys. The backed up SAM in the \repair directory does not. It is considered good practice to not give unrestricted access to the root directory of your %systemroot% drive, as a precaution against having your system files manipulated. By default these directories are not available over the network by anyone other than the Administrator, members of the Administrators group, or the Backup Operator, so this only becomes a risk if you allow other users access either by allowing them to log on at the machine itself (log on locally) or by you creating a share at the root of your system drive granting others permission. Neither of these scenarios are recommended in the interest of security. See Recommendation #1 below for details on how to secure this file.
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). It should be noted, however, that nobody other than the Administrator or members of the Administrators group has the ability to submit a Schedule job. While it is possible for an Administrator to grant this ability to the Server Operators group, this is strongly discouraged. 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 similarily 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 abilties (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. 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 regularily 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 and \repair directory has the following permissions;
Administrators: Full Control
Everyone: Read
SYSTEM: Full Control
Power Users: Change
From within
Explorer, highlight the SAM._ file, right click, choose properties, security, permissions.
Remove all privilege from this file.
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. inheritted permissions from a share) can override the file permission.
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
.
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
First you
have to make sure auditing is enabled. Start User Manager, Policies, Audit, and click
"Audit These Events".
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.
Close the
dialog.
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.
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).
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. It is important to note that when running an applicatin as SYSTEM, it
does so attempting to use null session for credentials. Null session support has been
disabled by default in all versions of Windows NT after 3.1, therefore any attempt to
connect to non-local resources as this security context will fail. An Administrator could
enable null session support through the registry, but such a configuration is strongly
discouraged.
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.
Click on
the Add button and choose Show Users.
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"
Click the
Audit Permission on Existing Subkeys
Next, click
in the Success and Failure checkboxes for the following entries; - Query Value - Set Value
- Write DAC - Read Control
Choose OK,
and then Yes.
Repeat the
process for the Security tree.
Close REGEDT32, and stop the Schedule service. You will want to set the Schedule service to use a userID for startup which you create, rather than SYSTEM, in future. Take this opportunity to create such a user and change the startup for Schedule.
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. They are in no way responsible for any of the content herein, Russ Cooper is solely responsible for the entire contents. All are gratefully acknowledged for their efforts. This document has been provided to the members of the NTBugTraq mailing list (http://www.ntbugtraq.com/) 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 © 1997 by Russ Cooper, all rights reserved.
Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security
This page
has been viewed times sinceMonday, April 13, 1998
|
||
|
 |
 |
