Hackers will be happy to note that the LanManager (LM) hash is stored by default on Win 2000 to provide backward compatibility with non-Windows NT/2000 clients. This pro- vides attackers the usual attack points that we discussed in Chapter 5, and the same solu- tions apply. However, in a small blow to attackers, standard password hash garnering techniques are limited by some new Win 2000 features, primarily SYSKEY. But only a lit- tle, as we shall see.
] Grabbing the SAM
Popularity: 8
Simplicity: 10
Impact: 10
Risk Rating: 9
On Win 2000 domain controllers, password hashes are kept in the Active Directory (%windir%\NTDS\ntds.dit). With the default set of installed objects, this file approaches 10 megabytes, and it is in a cryptic format, so attackers are unlikely to remove it for offline analysis.
On non-domain controllers (DCs), the Security Accounts Manager (SAM) file is still the target of choice, and grabbing the SAM is accomplished pretty much as it was under NT 4. The SAM file itself is still stored in %systemroot%\system32\config and is still locked by the OS. Booting to DOS and grabbing the SAM is still possible under the new NTFS v.5 file system by using the venerable NTFSDOS utility from http://
www.sysinternals.com/. A backup SAM file still appears in \%systemroot%\repair (it is just named “SAM” instead of “SAM._” as in NT 4), and this file contains all the users con- figured on a system at installation. The rdisk utility has been integrated into the Microsoft Backup v.5 application (ntbackup.exe), which has a Create Emergency Repair Disk function. When Create Emergency Repair Disk is selected, a dialog box asks if the in- formation should also be backed up to the repair directory, as shown next:
If this option is selected, the Registry, including the SAM hive, is backed up to the
%windir%\repair\RegBack folder. Members of the Users group have Read access to this folder, and members of Power Users have Modify access if the system drive is formatted NTFS—though only Power Users have additional access to this file, not users. Attacks against this backup SAM are also somewhat mitigated because this file is SYSKEYed, and mechanisms for decrypting a SYSKEYed file (as opposed topwdump2ing a live SAM) have not been released into the wild.
The Win 2000 SAM file is SYSKEYed by default (see next) and must be extracted withpwdump2.
U Keep a Clean Repair\RegBack Directory
Don’t take any chances—move these files to a removable disk or to an alternate secure lo- cation, and don’t leave them in RegBack. Better yet, don’t select the Backup Registry Locally option when running the Emergency Repair Disk Creation utility.
] Dumping the Hashes with pwdump2
Popularity: 8
Simplicity: 10
Impact: 10
Risk Rating: 9
SYSKEY is now the default configuration for Win 2000 (see KB Article Q143475 and Chapter 5 for more information about SYSKEY). Thus, thepwdumptool cannot properly extract password hashes from the Registry on out-of-the-box Win 2000 server products.
Pwdump2is required to perform this task (see Chapter 5 for discussions ofpwdumpand pwdump2and whypwdumpdoesn’t work against SYSKEY). Furthermore, the updated version of pwdump2 (available at http://razor.bindview.com) is required to dump hashes locally from domain controllers because they rely on Active Directory to store password hashes rather than the traditional SAM.
U pwdump2 Countermeasures
As long as DLL injection still works on Windows, there is no defense againstpwdump2.
Take some solace that it requires Administrator privileges to run and that it must be run locally. If attackers have already gained this advantage, there is little else they can accom- plish on the local system that they probably haven’t already done (using data from the SAM to attack trusted systems is another matter, however).
] Injecting Hashes into the SAM with chntpw
Popularity: 8
Simplicity: 10
Impact: 10
Risk Rating: 9
If attackers gain physical access to a system, plus adequate unobserved time to boot it to another operating system, they can perform the sophisticated attack described by Petter Nordahl-Hagen at http://home.eunet.no/~pnordahl/ntpasswd/. In a series of papers on this site, Petter documents several startling facts, including
Password hashes can be injected into the SAM while offline, allowing someone to change the password of any user on the system.
Catch your breath—Petter goes on to describe and provide the tools to create a Linux boot floppy that can be used to bootstrap an NT/2000 system, change the Administrator
password (even if it’s been renamed), reboot, and then log in with the new password.
Here comes an even more interesting twist:
Injection works even if SYSKEY has been applied, and even if the option to protect the SYSKEY with a password or store it on a floppy has been selected.
“Wait a second,” we hear someone saying. “SYSKEY applies a second, 128-bit strong round of encryption to the password hashes using a unique key that is either stored in the Registry, optionally protected by a password, or on a floppy disk (see Chapter 5). How in blazes can someone inject fraudulent hashes without knowing the system key used to create them?”
Petter figured out how to turn SYSKEY off. Even worse, he discovered that an at- tacker wouldn’t have to—old-style pre-SYSKEY hashes injected into the SAM will automati- cally be converted to SYSKEYed hashes upon reboot.You have to admire this feat of reverse engineering. Hats off to Petter!
For the record, here’s what Petter does to turn off SYSKEY (even though he doesn’t have to):
1. Set HKLM\System\CurrentControlSet\Control\Lsa\SecureBoot to 0 to disable SYSKEY (the possible values for this key are 0—Disabled; 1—Key stored unprotected in Registry; 2—Key protected with passphrase in Registry;
3—Key stored on floppy).
2. Change a specific flag within the HKLM\SAM\Domains\Account\F binary structure to the same mode as SecureBoot earlier. This key is not accessible while the system is running.
3. On Win 2000 only, the HKLM\security\Policy\PolSecretEncryptionKey\
<default> key will also need to be changed to the same value as the previous two keys.
According to Petter, changing only one of the first two values on NT 4 up to SP6 re- sults in a warning about inconsistencies between the SAM and system settings on com- pleted boot, and SYSKEY is re-invoked. On Win 2000, inconsistencies between the three keys seem to be silently reset to the most likely value on reboot.
Use of these techniques may result in a corrupt SAM, or worse. Test them only on expendable NT/2000 installations, as they may become unbootable. In particular, do not select the Disable SYSKEY option inchntpwon Win 2000. It has reportedly had extremely deleterious effects, often requiring a complete reinstall.
This technique as currently written will not change user account passwords on Win 2000 domain con- trollers because it only targets the legacy SAM file. Recall that on DCs, password hashes are stored in the Active Directory, not in the SAM.
U Chntpw Countermeasures
As long as attackers can gain unrestricted physical access to a system, there are few mea- sures that can counter this attack. One partial work-around is to set SYSKEY to require in- tervention at system boot, either by entering a password or by supplying a floppy with the system key (see Chapter 5 for a discussion on the three modes of SYSKEY). Thus, even if an attacker resets the Administrator password, he or she would still be required to enter the SYSKEY password to boot the system. Of course, attackers can still usechntpwto dis- able SYSKEY entirely, but they will risk crippling the target system if it is Win 2000.
Also consider that Petter has made disabling SYSKEY entirely the only option with thechntpwbinary—we wonder what would happen if it were set to 1 rather than 0, stor- ing the system key locally? This could disable password- or floppy-mode SYSKEY pro- tection, making this a totally useless countermeasure. The source code for chntpwis available on Petter’s site…or skillful use of the existingchntpwin Registry editing mode would also suffice.
Absent the incomplete protection provided by password- or floppy-mode SYSKEY, you must rely on traditional security best practices, such as making sure critical systems are physically secure and setting BIOS passwords or disabling floppy access to the system.
] Deleting the SAM Blanks the Administrator Password
Popularity: 4
Simplicity: 5
Impact: 10
Risk Rating: 6
On July 25, 1999, James J. Grace and Thomas S. V. Bartlett III released a stunning paper describing how to delete the Administrator password by booting to an alternative OS and deleting the SAM file (see http://www.deepquest.pf/win32/win2k_efs.txt). Granted un- supervised physical access to a machine and the availability of tools to write to NTFS vol- umes if needed (for example, NTFSDOS Pro from http://www.sysinternals.com), this technique basically made it trivial to bypass all local security on NT/2000.
Although the technique described in the paper mentions installation of a second copy of either NT or 2000 alongside the original, this is not necessary if the attacker is inter- ested solely in nullifying the Administrator account password. Simply deleting the SAM works straightaway.
There are serious implications of this attack for the Encrypting File System, explained in the next section.
Win 2000 domain controllers are not vulnerable to having the SAM deleted because they do not keep password hashes in the SAM. However, Grace and Bartlett’s paper describes a mechanism for achiev- ing essentially the same result on domain controllers by installing a second copy of Win 2000.
U Stopping Offline SAM Deletion
As discussed previously, the only OS-level method to partially blunt an attack of this na- ture is to configure Win 2000 to boot in SYSKEY password- or floppy-required mode.
Some other effective ways to stop offline password attacks are to keep servers physically secure, to remove or disable bootable removable media drives, or to set a BIOS password that must be entered before the system can be bootstrapped. We recommend using all of these mechanisms.