In my last article, I described how to use Windows 2000's Encrypting File System (EFS) to prevent an attacker from stealing confidential files from your laptop. I also iterated the importance of selecting hard-to-guess passwords and taking steps to protect your system against the Ntpasswd utility. As a final thought, I recommended that you always export and delete the recovery agent certificate. This last recommendation is especially important when you maintain Win2K-based systems that aren't members of an Active Directory (AD) domain, which is often the case with a mobile work force.
Data Recovery Without Active Directory
EFS won't work unless you define at least one recovery agent for each Win2K system. Win2K systems that are members of an AD domain use the domain’s recovery policy, and the domain Administrator account is the default recovery agent. Win2K systems that aren't members of an AD domain automatically define the local Administrator account as the recovery agent.
The EFS cardinal rule is that data recovery agents should never store their private key on a system. Instead, data recovery agents should store their data recovery certificate, which contains the private key, in a secure place and only reinstall the certificate when necessary to decrypt a file. The Win2K Help text states "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."
Win2K systems that aren't members of an AD domain automatically generate a data recovery certificate for the local Administrator account, which exposes the local Administrator’s private data recovery key to attack. To demonstrate this vulnerability, log on as the local Administrator and open the MMC by typing MMC at the command prompt. From the Console menu, select Add/Remove Snap-in and click Add. Double-click the MMC Certificates snap-in, select "My user account," click Close, and click OK to see the certificates the system assigned to the local Administrator account, as Figure 1 shows. Double-click the certificate labeled File Recovery. The Properties window for this certificate shows that "You have a private key that corresponds to your certificate," which means the system has installed the private key for this certificate with the certificate in your user profile.
In the situation that I've just described, an attacker that can gain physical access to the system can install a second copy of Win2K in a new directory. Then, the attacker can boot this new copy of Win2K and delete the SAM and sam.log files from the %systemroot%\system32\config directory of the original copy of Win2K (usually c:\winnt). If the attacker boots the original copy of Win2K, that individual can log on as the administrator without needing a password and decrypt any file on the system. Because the attacker deleted the SAM, Win2K creates a new, default SAM that contains just the Administrator and Guest accounts with no passwords protecting them. In addition, because this system is not a member of an AD domain, the local Administrator account is the recovery agent. Therefore, until you back up and delete the data recovery certificate’s private key, anyone can log on as Administrator and use the key.
Preventing Local Data Recovery Agent Attacks
To prevent attackers from using your private key, you need to back up and delete the data recovery certificate. First, log on to the laptop using the local Administrator account. Next, open the Certificates snap-in and manuever to the File Recovery certificate as before. This time, right-click the certificate, select All Tasks\Export, and click Next on the first page of the export wizard. Make sure you've selected the option that reads Yes, export the private key, click Next, and click Next again. Enter the password that you want to use to encrypt the private key once you've stored it on a 3.5" diskette, and click Next. Insert a formatted 3.5" diskette, enter a filename, click Next, review your choices, and click Finish to copy the certificate, including the private key, to your diskette. Now, right-click the File Recovery certificate again and delete it from your system. Store the 3.5" diskette in a secure place, make a backup of it, and store that backup copy in a secure place offsite.
If you are overwhelmed by the thought of managing a different recovery key for each laptop, keep in mind that both of the methods I described last time for defeating Ntpasswd will give you some measure of protection against the data recovery private key attack. By configuring Syskey to use a startup password, Win2K won’t boot without the startup password—even if you delete the SAM and sam.log files, thus rendering the local Administrator account password blank. Or, by joining the laptop to an AD domain (not a Windows NT domain), EFS will no longer use the local Administrator account as the recovery agent for any future files that you encrypt. Instead, EFS will use the AD recovery agent(s), thereby making the local administrator account an ineffective means of attack. This latter method of joining your laptops to an AD domain is the preferred way to protect against both Ntpasswd and local data recovery agent attacks. However, don't forget that you will greatly weaken EFS if domain data recovery agents fail to export, delete, and safely store their recovery certificates.
