One of the major security-related centerpieces of Win 2000 is the Encrypting File System (EFS). EFS is a public key cryptography-based system for transparently encrypting on-disk data in real time so that attackers cannot access it without the proper key.
Microsoft has produced a white paper that discusses the details of EFS operation, avail- able at http://www.microsoft.com/windows2000/library/howitworks/security/en- crypt.asp. In brief, EFS can encrypt a file or folder with a fast, symmetric, encryption algorithm using a randomly generated file encryption key (FEK) specific to that file or folder. The initial release of EFS uses the Extended Data Encryption Standard (DESX) as the encryption algorithm. The randomly generated file encryption key is then itself en- crypted with one or more public keys, including those of the user (each user under Win 2000 receives a public/private key pair) and a key recovery agent (RA). These encrypted values are stored as attributes of the file.
Key recovery is implemented in case employees who have encrypted some sensitive data leave an organization or their encryption keys are lost, for example. To prevent unre- coverable loss of the encrypted data, Win 2000 mandates the existence of a data recovery agent for EFS—EFS will not work without a recovery agent. Because the FEK is com- pletely independent of a user’s public/private key pair, a recovery agent may decrypt the file’s contents without compromising the user’s private key. The default data recovery agent for a system is the local administrator account.
Although EFS can be useful in many situations, it probably doesn’t apply to multiple users of the same workstation who may want to protect files from one another. That’s what NTFS file system access control lists (ACLs) are for. Rather, Microsoft positions EFS as a layer of protection against attacks where NTFS is circumvented, such as by booting to alternative OSes and using third-party tools to access a hard drive, or for files stored on remote servers. In fact, Microsoft’s white paper on EFS specifically claims that “EFS par- ticularly addresses security concerns raised by tools available on other operating systems that allow users to physically access files from an NTFS volume without an access check.”
We will see how this claim stacks up during our discussion of the next vulnerability.
EFS Best Practices EFS is available for any file or folder on the Properties screen under the General tab, Advanced button. In addition, the command-lineciphertool can be used to encrypt and decrypt files. Typecipher /?at a command prompt to see how.
Although files can be encrypted individually, Microsoft’s EFS white paper recom- mends encrypting at the folder level because attempted manipulation of individually en- crypted files occurs via many methods and can inadvertently leave them in a plaintext state. Also, encrypted files cannot be compressed.
Under the Win 2000 help on EFS, look up the best practices topic for some more good tips on using EFS wisely.
Be careful when moving EFS-encrypted files. Although standard backup mechanisms (for example, ntbackup.exe) will copy encrypted items as-is, the normal copy command reads files in a way that is transparently decrypted by EFS. If the destination is a non-NTFS 5.0 partition, files will be left in plaintext state on the destination volume. If the destination is aremote NTFS 5.0 partition, the file will be encrypted but will not be identical to the original—the remote copy will be encrypted with a new FEK. Note that this means EFS only protects the file while it is stored on disk; files are plaintext while they traverse the network wire.
] Nullifying the EFS Recovery Agent Key
Popularity: 3
Simplicity: 1
Impact: 10
Risk Rating: 5
Continuing our previous discussion of Grace and Bartlett’s paper at http://
www.deepquest.pf/win32/win2k_efs.txt, the ability to overwrite the Administrator ac- count password takes on a more serious scope once it is understood that Administrator is the default key recovery agent (RA). As Grace and Bartlett further describe in this pa- per, once successfully logged in to a system with the blank Administrator password, EFS-encrypted files are decrypted as they are opened, since the Administrator can trans- parently access the FEK using his or her recovery key.
Why does this work? Recall how EFS works: the randomly generated file encryption key (which can decrypt the file) is itself encrypted by other keys, and these encrypted val- ues are stored as attributes of the file. The FEK encrypted with the user’s public key (ev- ery user under 2000 receives a public/private key pair) is stored in an attribute called the Data Decipher Field (DDF) associated with the file. When the user accesses the file, his or her private key decrypts the DDF, exposing the FEK, which then decrypts the file. The value resulting from the encryption of the FEK with the recovery agent’s key is stored in an attribute called the Data Recovery Field (DRF). Thus, if the local Administrator is the defined recovery agent (which it is by default), then anyone who attains Administrator on this system is able to decrypt the DRF with his or her private key, revealing the FEK, which can then decrypt the EFS-protected file.
Defeating Recovery Agent Delegation But wait—what if the recovery agent is delegated to parties other than the Administrator? Grace and Bartlett defeated this countermeasure by planting a service to run at startup that resets the password for any account defined as a recovery agent.
Of course, an attacker doesn’t have to focus exclusively on the recovery agent, it just happens to be the easiest way to access all of the EFS-encrypted files on disk. Another way to circumvent a delegated recovery agent is to simply masquerade as the user who encrypted the file. Usingchntpw(see earlier), any user’s account password can be reset via offline attack. An attacker could then log in as the user and decrypt the DDF transpar- ently with the user’s private key, unlocking the FEK and decrypting the file. The data re- covery agent’s private key is not required.
U Export Recovery Keys and Store Them Securely
Microsoft’s response to Grace and Bartlett’s paper conceded that EFS could be defeated in this way, but characteristically attempted to downplay the risks by asserting that the at- tack would fail if proper EFS recovery key handling practices were followed (see http://www.microsoft.com/technet/security/analefs.asp).
Unfortunately, the description of the export process supplied by Microsoft on this page is outdated, and the EFS help files don’t specify how to do it either. To export the re- covery agent(s) certificates on stand-alone systems, open the local Group Policy object (gpedit.msc), browse to the Computer Configuration\Windows Settings\Security Set- tings\Public Key Policies\Encrypted Data Recovery Agents node, right-click on the re- covery agent listed in the right pane (usually, this is Administrator), and select All Tasks
| Export. This is shown next:
A wizard will run, prompting for various pieces of information before the key can be exported. To back up the recovery agent key, you must export the private key along with the certificate, and we recommend enabling strong protection (requires a password).
Finally, make sure to select Delete The Private Key If Export Is Successful. This last step is what makes stealing the recovery agent decryption key from the local system highly im- probable (we just hate to say impossible…).
Recall that deleting the recovery agent certificate entirely from the right pane will disable EFS since Win 2000 mandates a recovery agent. The following illustration shows what happens when EFS is used without a defined recovery agent—it doesn’t work!
Items that have been encrypted previous to the deletion of the recovery agent remain encrypted, but, of course, can only be opened by the encrypting user unless the RA can be restored from backup.
For machines joining a domain, the situation is different: the domain controller holds the recovery key for all systems in the domain. When a Win 2000 machine joins a domain, the Domain Default Recovery Policy automatically takes effect; the Domain Administra- tor, rather than the local Administrator, becomes the recovery agent. This physically sep- arates the recovery keys from the encrypted data and makes the Grace and Bartlett attack much more difficult. It is good practice to export the recovery agent certificate from do- main controllers as well. If they were compromised, every system in the domain would become vulnerable if the recovery key were available locally.
Microsoft also asserts in the “analefs” paper that the ability to delete the SAM, causing the Administra- tor password to be reset to NULL, can be solved by SYSKEY. We have already demonstrated that this is false unless the SYSKEY password- or floppy-required mode is set (the paper does not refer to this).