Default SYSKEY configuration compromises encrypting file system
13 May. 2000
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 Security Systems (ISS) has discovered that, due to the way access to a user's private key is controlled; a vulnerability 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.
Vulnerable systems:
* Windows 2000 Server
* Windows 2000 Professional
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 systems.
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 algorithm 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/private key pair, a recovery agent may decrypt the files' contents, without comprom ising the user's priva
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 system 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.
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 random 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:
People who wish to use EFS are strongly recommended to use one of the other two modes of SYSKEY 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 private key. This issue does not affect domain-based accounts.
