Analysis of Reported Vulnerability in the Windows 2000 Encrypting File System (EFS)

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
On This Page

Summary
Background
Stand-Alone Machine
Domain Controller
Delegation of Recovery Agents
Domain Members
For More Information

Summary

On 25 July 1999, a paper titled "Windows 2000 Encrypting File System (EFS) Vulnerability" was released, detailing purported vulnerabilities in the Encrypting File System that will ship as part of Microsoft® Windows® 2000. Microsoft takes security seriously, and has thoroughly investigated the report. However, the attacks described in the report rely on the user making an administrative error that the EFS documentation specifically warns against. There is no vulnerability in a properly-configured EFS installation.

Microsoft welcomes feedback on its beta products. This feedback allows us not only to ensure that our products are technically sound, but also to ensure that we are adequately describing proper usage and recommended practices. We thank the authors of the paper and are looking into ways of improving our documentation and wizards in order to minimize procedural errors in the use of our products.

Background

The paper discusses attacks against a stand-alone machine or a domain controller, and considers cases in which the EFS recovery agent has been left at the default or has been delegated to another user. Generically, the attack in each case is the same:

  • Gain physical access to the target machine

  • By some means, gain access to the recovery agent's Windows NT account

  • Use the normal EFS recovery mechanism to recover the user's encrypted files.

In the scenarios that the paper lays out, these attacks succeed, and the authors conclude that this represents a vulnerability in EFS.

In fact, these attacks do not constitute a vulnerability in EFS. Rather, they underscore a fundamental precept of security - that critical cryptographic keys should always be secured separately from the information that they secure. The attacks discussed in the paper succeed only because the EFS recovery key has been left on the machine in each case, contrary to the recommendations made in the EFS documentation. If the recovery keys are properly handled, the attacks fail.

Stand-Alone Machine

The first attack discussed is one mounted against a stand-alone machine. The attack focuses on the fact that the local Administrator is the default EFS Recovery Agent for a stand-alone machine. If the attacker can gain access to the Administrator account, the attacker can decrypt any EFS encrypted files on the machine.

This attack would succeed only if the local Administrator has made a critical error - namely, leaving the EFS Recovery Key on the machine. However, the EFS help documentation explicitly discusses the need to remove this key from the machine:

If you are the recovery agent, you should be sure to use the Export command from Certificates in Microsoft Management Console (MMC) to back up the recovery certificate and associated private key to a secure location. After backing up, you should use Certificates in MMC to delete the recovery certificate. (Windows 2000 Server beta 3 RC1 help, EFS)

And

The designated recovery agent should export the data recovery certificate, secure it in a safe place, and delete the data recovery certificate from the system hard disk. In this way, the only person who can recover data for the system is the person who has physical access to the data recovery certificate. (Windows 2000 Server beta 3 RC1 help, Best Practices)

Likewise, Microsoft's White Paper "Encrypting File System for Windows 2000" (https://www.microsoft.com/windows2000/techinfo/howitworks/security/encrypt.asp) provides the following recommendation:

The private keys associated with recovery certificates are extremely sensitive. Never leave them unsecured. Either generate them on a computer that is physically secured or export the key and certificate into a .pfx file, protected under a strong password and secure that file on a floppy disk. (p20, Using the Encrypting File System, Recommendations)

In addition, the specific attack described for obtaining access to the local Administrator account can be prevented by use of the SYSKEY utility. (See https://support.microsoft.com/default.aspx?scid=kb;en-us;143475&sd=tech for more information on SYSKEY). SYSKEY strongly protects the SAM and other security-relevant system information. If SYSKEY had been applied to the workstation in this scenario, the attacker would have been unable to boot the machine without a password, preventing them from making the modifications that are necessary for the attack against the Administrator account.

Domain Controller

The second attack discussed is mounted against a domain controller. The attack is essentially the same, focusing on the fact that the default EFS Recovery Agent for a domain is the domain Administrator, whose account resides on the domain controller. If an attacker could gain physical access to the machine and compromise the domain Administrator's account, he could recover all EFS encrypted files on the domain.

In order for this attack to succeed, the domain Administrator must have made the same administrative error as in the case of the stand-alone machine: he or she must have left the EFS Recovery Key on the machine. The attack also relies on the domain controller's SAM having not been protected using SYSKEY. As in the above case, taking either of these two steps would prevent the attack.

In addition, for this attack to succeed, the attacker must have been allowed to have physical access to the domain controller. This is a dangerous practice, for more reasons that this particular attack - domain controllers are the most security-sensitive servers on a network, and should always be physically protected. Only administrators should have physical access to them.

Delegation of Recovery Agents

Finally, the paper notes that it is possible for the Administrator to delegate the role of the EFS Recovery Agent to another user, and discusses an attack against a machine in which this delegation has been done. The attack is similar to those noted above, except that instead of attacking the Administrator account, the attacker would seek to change the password of the Recovery Agent's account to some known value in order to allow the attacker to log in as the Recovery Agent and recover the files.

This attack requires the same administrative error as the above two attacks. Regardless of who the EFS Recovery Agent is, the Recovery Key should be removed from the machine. Likewise, applying SYSKEY would prevent the attack from being able to change the Recovery Agent's logon password via the method discussed in the paper.

Domain Members

The paper does not discuss attacks against machines that are members of a domain. This is by far the most likely configuration for Windows 2000 machines, and it is interesting to consider the difference between this scenario and those that are discussed in the paper. A domain member would be far more resistant to attack than any of the cases described above, even if the same administrative errors had been made.

The most important difference is who the EFS Recovery Agent is. When a Windows 2000 machine joins a domain, the Domain Default Recovery Policy automatically takes effect, and the domain Administrator, rather than the local Administrator, becomes the Recovery Agent. This is a significant difference. To see why, consider what all of the above attack scenarios had in common: the EFS Recovery Agent and the user shared the same machine. This meant that, because the EFS Recovery Key had been left on the machine, the Recovery Key and data were collocated. Thus, the attacker had only to compromise the user's machine in order to gain access to both the encrypted data and the keys that would decrypt it.

In contrast, a domain serves to physically separate the Recovery Key from encrypted data. Each user's EFS-encrypted data resides on his or her workstation, but the EFS Recovery Key resides on an entirely different machine -- the Recovery Agent's machine. Thus, even if the Recovery Key were left on the machine, a successful attack would require that an attacker compromise two machines, the machine that contains the target data and the one that contains the Recovery Agent's key. This significantly increases the difficulty of the attack.

It is worth stressing that the fact that the data and key are separated does not change our recommendation that the EFS Recovery Key be removed from the Recovery Agent's machine, and that SYSKEY be used to strongly protect the SAM and other information. (After all, the machine that the attacker steals could be the EFS Recovery Agent's machine). However, it can be seen that the most common configuration for Windows 2000 machines -- that is, a workstation configured as a member of a domain -- provides significantly greater protection than any of the configurations discussed in the paper.

For More Information

More Information on Windows 2000 security and the Encrypting File System is available at: