Internet Security Systems SAVANT Windows 2000 Advisory No: 00/26 Dated: 10 May 2000
Platforms Affected: ~~~~~~~~~~~~~~~~~~~ * Windows 2000 Server * Windows 2000 Professional
Subject: ~~~~~~~~ Default configuration of SYSKEY permits compromise of Encrypting File System
Summary: ~~~~~~~~ The Encrypting File System (EFS) permits files and folders on a user's system to be secured against unauthorized access, by providing on-disk data encryption using public key cryptography. This is particularly useful for the protection of sensitive data on a laptop should it be stolen. Internet Secu- rity Systems has discovered that, due to the way access to a user's private key is controlled, a vulnera- bility exists if EFS is used with the default settings for SYSKEY. This vulnerability permits the recovery of any data on a hard disk encrypted by a user having a local account.
Issue ~~~~~ EFS permits files and folders on a system to be secured against unauthorized access, by providing on- disk data encryption using public key cryptography. This level of protection is necessary to prevent access to sensitive data when Windows 2000 cannot provide security using the standard NTFS Access Control Lists (ACLs). This would be the case if a hard disk was stolen and booted onto a floppy disk containing an alternative operating system. Tools that allow access to files on NTFS formatted volumes irrespective of any NTFS permissions are freely available for both MS-DOS and UNIX operating sys- tems.
The protection is accomplished using public-key encryption and takes advantage of the CryptoAPI architecture in Windows 2000. When enabled, files are encrypted with a fast symmetric encryption algo- rithm using a randomly generated file encryption key (FEK). 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 encrypted with one or more public keys, including those of the user and a key recovery agent. Encrypting data raises the issue of data recovery should an employee who has encrypted some sensitive data leave, or their encryption keys be lost. To protect against the inability to access company data, a data recovery agent is mandated for use of EFS under Windows 2000. Disabling the data recovery agent will disable EFS. Because the FEK is totally independent of a user's public/pri- vate key pair, a recovery agent may decrypt the files' contents, without compromising the user's private key.
The default data recovery agent for a system is the local administrator. It has been known for some time that a vulnerability exists if the key recovery agents private key is left on a system susceptible to theft. By booting the system using an alternate operating system the SAM database can be deleted. When the sys- tem reboots a new database is created in which the administrator account has a blank password. The attacker can now login as the administrator and thus use the local administrator's recovery key to decrypt all encrypted data. A similar scenario has also been discussed for decrypting files when the recovery agent has been delegated to another user. These problems can be circumvented by removing the recovery agent's key from the system and placing it on a floppy disk, which is then kept in a secure location.
This situation was discussed in the following articles:
Windows 2000 Encrypting File System (EFS) Vulnerability: http://www.deepquest.pf/win32/win2k_efs.txt
Analysis of Reported Vulnerability in the Windows 2000 Encrypting File System (EFS): http://www.microsoft.com/technet/security/analefs.asp
Internet Security Systems has established that, even if the recovery agents private key is removed from the system, as recommended, all data encrypted by a local user can be accessed if the default SYSKEY security setting has been used. There is no evidence to suggest that this issue effects domain-based user accounts.
For a user to decrypt an encrypted file requires access to the user's private key as shown above. Access to the key is controlled by the user's ability to successfully log onto the system. Windows password hashes (LAN Manager or NTLM) stored in the SAM are known to be susceptible to off-line attack. To defend against this possibility Windows 2000 employs a program called SYSKEY to provide additional encryption of the SAM. SYSKEY has three modes of operation:
Store Startup Key Locally - Windows 2000 will use a pseudorandom number generator to pick a ran- dom 128-bit system key. This system key will be stored, obfuscated, in HKLM\SYSTEM. In this mode, no user interaction is required to reboot the machine.
Store Startup Key on Floppy Disk - Windows 2000 will store the encrypted system key on a floppy. The key itself will be stored in a file named StartKey.key. In this mode, the floppy will be required to boot the system.
Use a Passphrase to Unlock the System Key - Windows 2000 will feed the passphrase you enter to a special algorithm, which will generate a 128-bit key from it. A maximum of 128 characters may be entered for a passphrase. SYSKEY does not enforce any minimum password length. In this mode the passphrase will be required during system reboot.
Of these, the first mode, where the key is held on the system, is the default on Windows 2000. This was thought to provide sufficient protection for the SAM, whilst offering ease of use.
A new version of a freely available utility (ntpasswd - by Petter Nordahl-Hagen) is capable of putting new password hashes directly into the SAM, thus changing the user's password, even with SYSKEY enabled. SYSKEY is automatically applied to these new hashes when the system is rebooted.
After using the utility it is possible to login to any user account, including the administrator's, using the known password. Successful authentication then allows access to the user's private key and hence any file that the user has encrypted. The data recovery agent's private key is not required.
Recommendations ~~~~~~~~~~~~~~~ Subscribers who wish to use EFS are strongly recommended to use one of the other two modes of SYS- KEY operation, where the system will not reboot without intervention. Whilst this does not stop 'ntpasswd' from overwriting the existing password hash with a new value, it prevents the system from being rebooted and thus prevents anyone logging on with the new password, hence protecting the pri- vate key. This issue does not affect domain-based accounts.
Further Information ~~~~~~~~~~~~~~~~~~~ Further information is available from the following locations:
Details on the ntpasswd program can be found at: http://home.eunet.no/~pnordahl/ntpasswd/
Details on EFS can be found in the MS White paper:
Copyright (c) 2000 by Internet Security Systems, Inc. This advisory may be freely distributed in elec- tronic form, but must not be modified or distributed using any other means.
SAVANT (c) is a subscription service provided by Internet Security Systems giving best practise security advise on a range of operating systems. Further details can be obtained from www.iss.net
Disclaimer ~~~~~~~~~~ The information within this advisory may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the ISS be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.