COMMAND
Syskey
SYSTEMS AFFECTED
Windows 2000 Server, Windows 2000 Professional
PROBLEM
John Hayday found following (ISS SAVANT Advisory 00/26). Default
configuration of SYSKEY permits compromise of Encrypting File
System. 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 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.
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 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 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.
This situation was discussed in the following articles:
- http://www.deepquest.pf/win32/win2k_efs.txt
- 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 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.
Details on the ntpasswd program can be found at:
http://home.eunet.no/~pnordahl/ntpasswd/
SOLUTION
Subscribers 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.