Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Subject: ISS SAVANT Advisory 00/26
From: Hayday, John (ISSReading) (jhaydayISS.NET)
Date: Thu May 11 2000 - 05:02:40 CDT

Internet Security Systems
SAVANT Windows 2000 Advisory No: 00/26 Dated: 10 May 2000

Platforms Affected:
* Windows 2000 Server
* Windows 2000 Professional

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 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


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-

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

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

This situation was discussed in the following articles:

* Windows 2000 Encrypting File System (EFS) Vulnerability:

* Analysis of Reported Vulnerability in the Windows 2000 Encrypting File
System (EFS):

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

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.

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:

* 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

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.