COMMAND
EFS
SYSTEMS AFFECTED
Win2000
PROBLEM
Rickard Berglind found following. He has found a major problem
with the encrypted filesystem (EFS) in Windows 2000 which shows
that encrypted files are still very available for a thief or
attacker.
The problem comes from how EFS works when the encryption is done.
When a user marks a file for encryption a backup-file, called
efs0.tmp, will be created. When the copy is in place the orginal
file will be deleted and then recreated, now encrypted, from the
efs0.tmp- file. And finally, when the new encrypted file is
succesfully created, the temporary-file (which will never be shown
in the user interface) will be deleted as well.
So far, so good. The only file remaining is the one which is
encrypted.
But the flaw is this: the temporary-file is deleted in the same
way any other file is "deleted" - i.e. the entry in the $mft is
marked as empty and the clusters where the file was stored will
be marked in the $Bitmap as available, but the psysical file and
the information it contains will NOT be deleted. The information
in the file which the user have encrypted will be left in the
backup file efs0.tmp in total plaintext on the surface of the
disk.
When new files are added to the partition will they gradually
overwrite the secret information, but if the encrypted file was
large - the information could be left for months.
So how can this be exploited? If someone steals a laptop or have
psysical access to the disk it will be easy to use any low level
disk editor to search for the information. For example, the
Microsoft Support Tool "dskprobe.exe" works fine for locating old
efs0.tmp-files and read information, in plain-text, that the user
thought was safe.
There should be a function in the EFS which physically overwrites
the efs0.tmp at least once to make it a lot harder for an attacker
to gain control over secret information.
Here is a description how to test this. Use any version of
Windows 2000. Install the Support Tools from the Win2000 CD. For
demonstrating purposes - create a new partition with the size of 7
MB. Choose to format with NTFS. Create a new small file (easier
to find) with Notepad and put some text in it. Save this file in
the root of the new partition.
Do not encrypt it yet.
Let us look at the file through DiskProbe before encryption-start
Diskprobe from Support Tools on the Start Menu.
A. Choose the "Drives"-menu and "Physical Drive". Double click
on "physical drive 0" (or other drive you are using). Click
"Set active" and then "OK"
B. Choose "Drives" again and this time "Logical Volume". Double
click the drive letter for your new partition and then "Set
active" and "OK".
C. Choose the "Sectors"-menu and "Read". For starting number type
80 and for the number - 35 perpaps.
Maximize the window and click the arrow for "Next sector".
At sector 86 you should see the name and contents of your file
(assuming you made a new partition).
The file is obiously in plain text and easy to read for anyone
with physical access to this disk, regardless of permissions in
the ACL, which is ignored when using this kind of utiliy. Better
encrypt this file .. !
Now close the DiskProbe utility and open Explorer and locate your
new file. Choose Properties - Advanced - Encrypted - OK. The
file is now encrypted.
Wait a few moments to be sure the new data has been written to the
disk. Open Diskprobe again and repeat steps A, B and C.
When reaching sector 86 you should be able to see the name of your
file, but not be able to read the information - it is now
encrypted.
But.. continue to click the Next Sector-Arrow and look carefully
at the information being displayed. A few sectors away from the
orginal file there should be a file called efs0.tmp - which is
the backup file EFS creats during encryption. You should ALSO
be able to see the contents of this efs0.tmp file - which will
be the data from the file you encrypted. The problem is just that
the data is in clear and plain text. So again - anyone with
physical access to this disk can read the data you thought was
safe.
Peter Gutmann has demonstrated for years now that there is no form
of over-writing which makes any substantial difference to the
ability to recover previously written data from a computer hard
disk. A working URL is:
http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
"Inside Windows 2000 - 3rd edition" (MS Press) has a description
on how the EFS system works, including the creation of the
temporary file described here.
It appears that the temp file is created to allow rollback on
system failure during encryption. This, however, does not excuse
the failure to erase the disk space used by that file once the
encrypted file has been written to disk. This may lead to a small
window where the disk is in a consistent state (ie the file has
been successfully encrypted) and the backup data is yet to be
erased, so the logging/recovery process should be modified in any
fix to ensure that the file system recovers system failures in
the best way possible - obviously a failure during encryption
will leave the unencrypted file on disk for recovery, but a
successful encryption should always remove the unencrypted data.
Many people have suggested that encrypting the folder would solve
the issue, but let us look at some short scenarios. You have an
encrypted folder and you copy a file from somewhere on your
partitions to this folder. Result: no efs0.tmp will be created
and left behind, which might look good. The reason for this is
the efs0.tmp is only a backup file, which makes the file
recoverable if the power should go during encryption, and is used
as the "original" when the encrypted version of the file is
created. When you copy a file there obviously exists a "original"
file and no efs0.tmp is needed. The problem is when you later
deletes the first file - it will very much exist on the surface
of the disk - readable for anyone with a disk editor. Result:
plain text version remains on disk.
If you move a file to the encrypted folder from the same partition
there is only one file and no original which could be used as
backup file. In this case a efs0.tmp will be created and left on
disk. Result: plain text version remains on disk.
If you move a file to the encrypted folder from a different
partition no efs0.tmp will be created. The reason for this is
that a move operation between partitions is really a copy and
later a delete of the first file. In this case a original exist
and no efs0.tmp will be created. But the file on the first
partition will be deleted as always - i.e. not removed from the
sectors. Result: plain text version remains on disk.
The only way to not leave any plain text behind you is to create
an encrypted folder and create every file there - from the very
beginning. This might be fine, but it also gives the following:
any file which have been located on your hard disk before you
start using EFS could never be safe even after encryption.
SOLUTION
The only solution is to encrypt in memory or use some removable
partition as the temp space.
While EFS does indeed work as Rickard discusses, this is not new
information. For instance, "Encrypting File System for Windows
2000":
http://www.microsoft.com/WINDOWS2000/library/howitworks/security/encrypt.asp
(p 22) notes the following:
"EFS also incorporates a crash recovery scheme whereby no data
is lost in the event of a fatal error such as system crash,
disk full, or hardware failure. This is accomplished by
creating a plaintext backup of the original file being
encrypted or decrypted. Once the original is successfully
encrypted or decrypted, the backup is deleted. NOTE: Creating
a plaintext copy has the side-effect that the plaintext
version of the file may exist on the disk, until those disk
blocks are used by NTFS for some other file."
The plaintext backup file is *only* created if an existing
plaintext document is coverted to encrypted form. If a file is
created within an encrypted folder, it will be encrypted right
from the start, and no plaintext backup file will be created.
Microsoft recommends this as the preferred procedure for using EFS
to protect sensitive information. "Encrypting File System for
Windows 2000", page 22, makes this recommendation:
"... it is recommended that it is always better to start by
creating an empty encrypted folder and creating files directly
in that folder. Doing so, ensures that plaintext bits of that
file never get saved anywhere on the disk. It also has a
better performance as EFS does not need to create a backup and
then delete the backup, etc."
Even if the plaintext backup file were not created, it would
still be a bad idea to create a sensitive file in plaintext and
then encrypt it later. Many common operations, such as adding
data to or removing data from a file, compressing and
decompressing a file, defragmenting a drive, or opening a file
using an application that creates temporary files, can result in
plaintext being left on the drive. It is simply not feasible for
any software package to be able to track down and erase all the
plaintext "shreds" that may have been created during the file's
plaintext existence. The only way to ensure that there is no
plaintext on the drive is to encrypt the file right from the
start.
Frank Knobbe pointed out that PCGuardian's Encryption Plus Hard
Disk software works well on Windows 2000 and does complete disk
encryption (enter password at boot to decrypted system files),
solving the EFS issues posed by Rickard.
Kris Kennaway was succinct; "If the file was overwritten even once
then it can't be recovered in software. Not many people have
access to expensive scanning equipment which can pick up residual
magnetisation of the storage medium."
Camillo Sars said; "F-Secure FileCrypto does a secure delete, that
is overwrite, of the original when doing an initial encryption.
Nevertheless, any files created after encryption comes into effect
are immediately written to disk in encrypted form, without any
intermediate steps of writing temporary plaintext to disk."
Roman Fischer said; "PGPDisk creates one large file. On this
file, it reads/writes the data. Thus it overwrites the same parts
of the file all the time, not leaving any temp files behind
(other than maybe in swap space or memory)."