Analysis of Alleged Vulnerability in Windows 2000 Syskey and the Encrypting File System

Updated : July 18, 2001

We've received a number of reports from customers who are concerned about tools that are reputed to be able to bypass the protection provided by the Syskey feature in Microsoft® Windows® 2000 and enable unauthorized users to read files protected by the Encrypting File System (EFS). These customers wanted to know whether their traveling employees' data could be at risk if their laptops were stolen.

We've conducted a thorough investigation of the reports, and found that, when Windows 2000 is used as recommended, tools such as these cannot be used to compromise encrypted data. Specifically, if the user is a domain member - as most users are - the tools cannot compromise EFS-encrypted data. Even in the case where the user is not a member of a domain, the tools can only succeed if Syskey is used in the least-secure mode. If Syskey is used in either of two more-secure modes, the tools cannot succeed.

Nevertheless, it's worth discussing the tools and the risk they pose, for two reasons. First, there are some scenarios in which these tools could succeed, and customers who understand the issue can easily take steps to ensure that their data is secure. Second, these tools are illustrative of several larger security considerations, such as the need to physically protect the machine and remove cryptographic keys from it. We've developed the following Frequently-Asked Questions section to discuss in detail the tools and the threat they pose.

On This Page

Frequently-Asked Questions

Frequently-Asked Questions

What's the claimed vulnerability?

A typical report regarding this issue says something like the following:

• I've just discovered a tool on the Internet that lets anyone with physical access to a machine reset the Administrator account password to a known value, even if Syskey is in use on the machine. After resetting the Administrator account password, an attacker could log onto the machine as the administrator, then use the administrator's EFS Recovery Key to read any EFS-encrypted data on the machine. Alternatively, the attacker could log on as the Administrator, reset another user's password, then log on as that user and read his or her EFS-encrypted data.

What's Syskey?

Syskey is a feature first introduced in Windows NT® 4.0 (and provided as part of Windows 2000) that makes it more difficult for an attacker to compromise passwords on a Windows NT machine.

In Windows NT and Windows 2000, passwords are stored in the Security Account Manager (SAM) database. The password values themselves aren't stored in the SAM - instead, the hashed values of the passwords are stored there. If an attacker could obtain a copy of the SAM through some means, he could conduct a brute-force attack, in which he would generate the hash of every possible password and compare each to the hashes in the SAM database. When he found a match, he would know the password for the account.

Syskey thwarts this attack by encrypting the SAM database using strong encryption. Even if an attacker did manage to obtain a copy of the Syskey-protected SAM, he would first need to conduct a brute-force attack to determine the Syskey, then conduct a brute-force attack against the hashes themselves. This dramatically increases the work factor associated with the attack, to the point where it's considered to be computationally infeasible.

What's EFS?

The Encrypting File System (EFS) is a feature in Windows 2000 that provides cryptographic protection for files on the machine.

EFS was designed to thwart an attack in which an attacker who has physical control of a Windows 2000 machine would boot the stolen machine using an operating system that doesn't respect the Windows 2000 access controls, then copy the files. EFS blocks this attack by encrypting user-specified files. If an attacker stole these encrypted files, he would need to conduct a separate brute-force cryptographic attack against each file in order to read its contents.

A feature of EFS that plays a central role in the discussion here is the EFS Recovery Agent. A Recovery Agent is a user who is authorized to decrypt files belonging to other users. The chief use of this feature is to allow files to be decrypted in the event that the original owner loses the key. Whenever a file is encrypted by EFS, EFS also creates a copy of the key that is accessible by the Recovery Agent. By default, administrators are Recovery Agents - the local administrator in the case of a local user, and the domain administrator in the case of a domain user. However, the list of Recovery Agents can be customized via security policy.

Are there tools that allow an attacker to reset the Administrator account password to a known value?

Yes. We've examined several tools that do this. In each case, they require that the attacker have physical control over the machine, then boot into a different operating system. The tool then overwrites entries in the local SAM database in order to change the hashed password for the local Administrator account to a known value. The attacker could then reboot the machine normally, and log on as the local Administrator using the new password.

Do these tools represent a flaw in Windows 2000?

No. Tools like this are simply an example of the second and third Immutable Laws of Security:

• If a bad guy can alter the operating system on your computer, it's not your computer anymore.

• If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

It's simply a fact of computer science that the access control information created by one operating system to regulate the actions of its users is meaningless to other operating systems. If an attacker can boot into a different operating system, programs running under the new operating system can treat the information on the machine simply as a collection of binary data, and add, change or delete any information. It's worth noting that tools like these could be built to attack any operating system, regardless of vendor.

What about Syskey? Does it prevent tools like this from succeeding?

No. Syskey was not designed to prevent such an attack. It was designed to prevent the disclosure of password data, not to prevent it from being changed. These are two very different problems. It is simply not possible to prevent an attacker who can boot a foreign operating system on a machine from changing data on it. And an attacker who has the ability to overwrite the SAM database could, of course, also change the operating system itself, and simply remove the Syskey functionality if he wished. At this point, he could conduct the very same attack as described above, and overwrite the SAM with known hashes.

Once the attacker gained the ability to log on as the local Administrator, could he use the Administrator's EFS Recovery Keys to read another user's encrypted data?

Not if the user was a member of a domain. The default Recovery Agent for domain members is the domain Administrator account, not the Administrator account on the local machine. This means that the EFS recovery key would not even exist on the local machine, so it would be impossible to compromise it, even if the attacker had gained complete control of the local machine.

If the user was not a member of a domain, but was instead a local user, the default Recovery Agent would be the local Administrator. However, best practices would, if followed, prevent this case from leading to a compromise. Microsoft strongly recommends that, because of its value, the recovery key should always be exported from the machine and stored in a secure location. If this practice has been followed, there would once again be no recovery key on the machine to compromise.

OK, forget about compromising the recovery key. Could the attacker log onto the local Administrator account, then use the normal system tools to reset the password on a user account, and then log in as that user and read their EFS-encrypted files?

Not if the user was a domain member. Remember that the tools only enable the attacker to gain access to the local Administrator account - not the domain Administrator account. Local Administrators cannot reset domain members' passwords; they can only reset local users' passwords. Even if the user was a local user, the success of this attack would depend on what mode of Syskey was in use on the machine.

What are the Syskey modes, and what do they do?

There are three Syskey modes, and they determine the location of the decryption key that protects the SAM database. If the first mode - the default - is used, the key is stored on the local machine in an obfuscated state. If the second mode is used, the key isn't stored on the local machine at all; instead, the key takes the form of a password that the user must provide when booting the machine. If the third mode is used, the key is exported from the machine and stored on a floppy disk, which must be presented when booting the machine.

Why would the Syskey mode make a difference in the success of the attack?

We previously noted that Syskey encrypts the SAM database. However, it actually encrypts more than this - it also encrypts a storage area called LSA Secrets, which is used to store sensitive data, including cryptographic key material such as the users' EFS keys. The different Syskey modes would determine whether the attacker could decrypt the data in LSA Secrets.

If Syskey was used in Mode 1, an attacker who compromised a local user account would be able to access anything protected by Syskey. This is because, in Mode 1, the Syskey is stored on the machine, and Windows 2000 would automatically find it and use it. As a result, if the attacker could log on as a local user, Windows 2000 would decrypt LSA Secrets, and he could decrypt the user's EFS-encrypted files.

It's important to note that this has nothing to do with the tools we've been discussing. It would be equally true no matter how the attacker compromised the user's account. If the attacker has the capability to log in as the user, he would have the capability to use the data in LSA Secrets, and could therefore read EFS-encrypted data.

What if Syskey was used in Modes 2 or 3?

The story is completely different for Syskey Modes 2 and 3. In these two modes, the Syskey is not present on the machine. Even though the attacker might be able to log onto the machine, he would not have the key needed to decrypt LSA Secrets, and thus couldn't access the EFS decryption keys. He would therefore fail in his attempt to compromise the user's encrypted data.

Is the fact that this attack would work when Syskey is used in Mode 1 a security flaw?

No. It is, however, a good example of the Seventh Immutable Law of Security: encrypted data is only as secure as the decryption key. When Syskey is used in Mode 1, the key, although well-hidden, is nevertheless discoverable. It has to be, because otherwise the operating system itself couldn't find and use it. In contrast, in Modes 2 and 3, the key simply doesn't exist on the machine. No matter how thoroughly compromised the machine is, if the attacker doesn't have the keys, he can't decrypt the data.

The larger message here is that cryptographic keys need to be protected in a way that reflects the value of the data they protect. If a machine only holds low-value data, it may be appropriate to use Syskey in Mode 1. However, if it holds valuable or sensitive data, Syskey Modes 2 and 3 are more appropriate.

What should customers do to protect themselves against these tools?

We recommend three preventive measures:

• Physically protect the machine. An attacker could only use these tools if he was able to gain physical control of someone else's machine. But even if these tools didn't exist, there are many other attacks that could be mounted by an attacker who gains physical control of another user's machine.

• Be a domain member whenever possible. Domain members' credentials are centrally stored, and can only be changed at a domain controller, which, if best practices have been followed, will be the most heavily-defended machine in a network.

• Use Syskey in Modes 2 or 3 when sensitive data is stored on the machine. Both of these modes are less convenient than Mode 1 - Mode 2 requires memorizing a password, and Mode 3 requires carrying a floppy disk - but both are significantly more secure than Mode 1. (By the way, if you're using Syskey in Mode 2, be sure to select a strong password).