COMMAND
SAM attacks
SYSTEMS AFFECTED
Win NT
PROBLEM
Russ Cooper made post about SAM tittled "Suggestions to safeguard
against SAM attacks" which is very good starting point so
following text is based on his post and includes it's parts.
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.
But be aware 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.
Be aware also that 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.
SOLUTION
Check SAM #3 on this page (Security Bugware).
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 Russ privately
(Russ.Cooper@rc.on.ca) and he'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.
3. 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.
4. 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. 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.
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.
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.