COMMAND
EFS
SYSTEMS AFFECTED
Windows NT 2000 Beta 3 build 2031 (Professional, Server, Advanced Server)
Windows NT 2000 Release Candidate build 2072 (Server, Advanced Server)
PROBLEM
James J. Grace and Thomas S. V. Bartlett III have released a
whitepaper (and some code) detailing a means to bypass protection
offered by the Encrypting File System (EFS) built into Windows
2000. They posted the whitepaper and the code on our home page.
Come take a look if you're interested.
http://www.ntsecurity.net
Here's a small part. Microsoft defines the following issues with
computer security related to physical access to computer hardware
and data: "A standard safety measure on a personal computer system
is to attempt to boot from a floppy disk before trying to boot
from the hard disk. This guards users against hard drive failures
and corrupted boot partitions. Unfortunately, it also adds the
convenience of booting different operating systems. This can
mean someone with physical access to a system can bypass the
built-in security features of the Microsoft(r) Windows NT(r) file
system access control by using a tool to read Windows NT file
system (NTFS) on-disk structures. Many hardware configurations
provide features like a boot password to restrict this kind of
access. Such features are not in widespread use, and in a typical
environment, where multiple users are sharing a workstation they
don't work very well. Even if these features were universal, the
protection provided by a password is not very strong.
Additionally, the hard disk can be removed from a secure computer
and then plugged into a computer where the perpetrator has
sufficient access. Typical scenarios where unauthorized data
access becomes an issue include:
A stolen laptop. It only takes a moment for someone to pick
up an unattended laptop. What if the thief is not interested
in reselling your computer, but is interested in the sensitive
information stored on its hard drive?
Unrestricted access. Office desktop systems are left
unattended and anyone can come in and quickly steal
information from an unattended computer. The root of these
security concerns is sensitive information, which typically
exists as unprotected files on your hard drive. You can
restrict access to sensitive information stored on an NTFS
partition if Windows NT is the only operating system that can
be run and if the hard drive cannot be physically removed. If
someone really wants to get at the information, it is not
difficult if they can gain physical access to the computer or
hard drive. Availability of tools that allow access to NTFS
files from MS-DOS(r) and UNIX operating systems makes
bypassing NTFS security even easier. Data encryption is the
only solution to this problem. There are a number of products
on the market that provide application-level file encryption
using password-derived keys.
However, there are some limitations with most of these approaches.
Microsoft's weapon to combat this problem is to utilize the
Encrypting File System Architecture (EFS) to secure user data. To
this end Microsoft further quotes in regard to EFS:
"EFS particularly addresses security concerns raised by tools
available on other operating systems that allow users to
physically access files from an NTFS volume without an access
check.."
"An individual with physical access to the machine could
potentially attempt sophisticated attacks by going to the disk
directly. Attempts to read the data this way will fail because
it is encrypted and a successful process would require
implementing EFS itself. Another possible attack with
physical access can be to invalidate or delete the recovery
portion on the encrypted file. This will still not work
because EFS will automatically recreate the recovery
information when the file is successfully opened next time."
With this said it would appear that EFS provides for a bulletproof
solution to encrypting sensitive data. Unfortunately we have to
disagree with Microsoft's statements regarding the robustness of
EFS, due to the security concerns that authors have uncovered.
It is possible to gain access to all encrypted data on a Windows
NT 2000 workstation or server if physical access to the hardware
can be obtained. No user accounts or passwords are required for
this access. Access to the encrypted data is possible on
standalone and domain member devices. This would include Windows
2000 workstations that are members of a domain as well as Windows
2000 resource/member servers that are in workgroups or domains.
Access is also possible on Domain Controllers running Microsoft
Active Directory Services (ADS).
Typical scenario. The fictitious nuclear technology company, ACME
NUKES has very strict computer security needs. To insure they
have adequate security protection they deploy data encryption
technologies as part of their overall security policy. To assist
in this plan ACME deploys Windows NT 2000 Advanced server to all
Servers and Windows NT 2000 Professional on all desktops and
laptops. During normal day-to-day operations ACME insures that
the needed data is constantly encrypted by enforcing an encryption
group policy for the organization. Employees and scientists using
the data are ensured their work is secure whether it is on the
network, on workstations or laptops. The fictitious BRUTUS
corporation is in the business corporate espionage and selling
information to the highest bidder. After hearing about the new
technologies that ACME corporation is developing BRUTUS selects
ACME as a viable and profitable target. Each night ACME
scientists take the encrypted secret project data home to review.
Not overly concerned about possible compromise due to the new
automatic encryption of Microsoft's EFS. BRUTUS operatives take
advantage of this loose physical security and are able to steal a
laptop from one of the scientist home. (This also could have been
a server from the company network.) BRUTUS now in possession of
the physical encrypted data begins the process of accessing the
drives to obtain the encrypted files. Once physical access to
the data and hardware has been accomplished all encrypted data can
be quickly recovered using the techniques that follow. ACME's
secret data has been compromised. How to reproduce the issue:
To access the data that is encrypted on the system hard drives,
complete the following procedures: (For the purpose of this
discussion assume Windows NT 2000 was installed into "c:\winnt")
For member servers or workstations do the following:
* Install a second (parallel) copy of Windows NT 2000 onto the
computer system. If there is not enough hard disk space use
a third party utility to delete unneeded files to make
space. Install this copy into say "c:\winnt2".
* Boot the computer to the copy of NT installed into the
"c:\winnt2" directory.
* Using Windows Explorer locate the "c:\winnt\system32\config"
directory.
* Make a backup copy of all the files located in
"c:\winnt\system32\config".
* In the "c:\winnt\system32\config" directory locate and
delete the SAM and SAM.LOG files.
* Shutdown and reboot the computer into the "c:\winnt"
directory (This is the original servers installation)
* At the logon screen press CTL+ALT+DEL.
* Enter Administrator for the user name.
* Press the enter key for the password. (No Password)
* The system now logs you on as administrator.
* Using Windows Explorer, locate the encrypted files and open
them. EFS will automatically decrypt the files for you. At
this point you are able to access all files encrypted or
plaintext on the server.
This problem also affects servers that are running Microsoft
Active Directory Services (ADS). For Active Directory Services
Domain Controllers do the following (For the purpose of this
discussion assume Windows NT 2000 was installed into "c:\winnt"):
* Install a second (parallel) copy of Windows NT 2000 onto the
computer system. If there is not enough hard disk space use
a third party utility to delete unneeded files to make
space. Install this copy into say "c:\winnt2".
* Boot the computer to the copy of NT installed into the
"c:\winnt2" directory.
* Using Windows Explorer locate the "c:\winnt\system32\config"
directory.
* Make a backup copy of all the files located in
"c:\winnt\system32\config".
* In the "c:\winnt\system32\config" directory locate and
delete the SAM and SAM.LOG files.
* Shutdown and reboot the computer.
* As the NTLDR boots and the BOOT.INI menu is presented press
the F8 key to boot the server into Safe Recovery Mode
* Select Active Directory Services Recovery from the menu.
* Select the original server installation
* The system will now boot into safe mode
* At the logon screen press CTL+ALT+DEL.
* Enter Administrator for the user name.
* Press the enter key for the password. (No Password)
* The system now logs you on as administrator.
Using Windows Explorer, locate the encrypted files and open them.
EFS will automatically decrypt the files for you. At this point
all data on the servers has been compromised. Note: Deleting the
SAM on Windows NT 4.0 provides the same ability to logon as
Administrator with no password. Microsoft has made provisions to
allow extensive delegation of Recovery Agents in your domain
environment. This allows you to remove Administrator from having
the ability to recover encrypted files and assign this right to
other users. While this may appear to be a solution to our
previous scenarios, it really is not.
As outlined below authors will demonstrate how to subvert any
attempts to use delegation of Recovery Agents to another user and
still successfully access all encrypted data on the system.
Bypassing Delegation of Recovery Agents
=======================================
The procedure that follows is very similar to the previous two
with only slight variances. In this scenario we will use a
service that we wrote to assist as well as regedt32. The service
is installed to the original system "c:\winnt" install, which
then allows you to call any programs that you wish. Further
details on this will be outlined later.
* Install a second (parallel) copy of Windows NT 2000 onto the
computer system. If there is not enough hard disk space use
a third party utility to delete unneeded files to make
space. Install this copy into say "c:\winnt2".
* Boot the computer to the copy of NT installed into the
"c:\winnt2" directory.
* Using Windows Explorer locate the "c:\winnt\system32\config"
directory.
* Make a backup copy of all the files located in
"c:\winnt\system32\config".
* Launch REGEDT32.EXE
* From the registry menu select "Load Hive"
* Browse to "c:\winnt\system32\config" and load the SYSTEM
hive.
* Give the hive any name such as SystemXXX
* Expand the SystemXXX registry hive and locate
"SystemXXX\Select registry key.
* Identify which control set is the current control set. In
this example it is 1.
* Locate and expand SystemXXX\ControlSet001\Services
* Create a new key under the services key such as Resetpwd
* Under the Resetpwd key add the following keys:
"Type"=dword:00000010
"Start"=dword:00000002
"ErrorControl"=dword:00000001
"ImagePath"="c:\winnt\system32\resetpwd.exe"
"DisplayName"="Password Reset Service"
"ObjectName"="Local System"
Note: On Windows 2000 systems you do not need to enclose these
registry items in quotes. If you do, the service will not start
correctly. You can review other services to see how this needs
to be setup if you need assistance.
* After adding these keys unload the SystemXXX hive that you
loaded
* Using explorer copy the Resetpwd.exe service to
"c:\winnt\system32"
* At the root of the C:\ drive create a file called ResetPwd.bat
* In this file enter the following line "Net User username
password" where username is the name of the delegated
recovery agent and password is the password you wish to
reset the account to.
Note: You can reset multiple accounts by simply adding additional
lines to the ResetPwd.bat file. If you do not know who the
recovery agents are you could reset the administrators password
and then using the Active Directory Users and Computers MMC
snap-in locate the domain recovery agents policy and review the
user accounts that have been granted RA rights. (Assuming that
this is a domain controller).
It is also possible to identify recovery agents per file by using
the WIN32 Crypto API's to query the Data Recovery Field (DRF) for
a given file to locate users who can recover the encrypted file.
Further, you could simply identify the owner of the file or the
user who encrypted the file by querying the Data Decipher Field
(DDF), reset that users password using the service and decrypt
the file by logging on as that user.
* Save this file and reboot the computer to the original NT
install in "c:\winnt"
* Wait for the system to come up. You should then hear the
system beep if you have installed the service correctly.
* At the logon screen press CTL+ALT+DEL.
* Enter recovery agents name for the user name.
* Enter the password you selected for the password.
* The system now logs you on as the RA user.
* Using Windows Explorer, locate the encrypted files and open
them.
EFS will automatically decrypt the files for you. At this point
you are able to access all files encrypted or plaintext on the
server. The ResetPwd.Exe service file simply calls ResetPwd.Bat
and it must be in the root of C:. The service performs no other
function. Because the service runs as the System account, this
grants us unlimited potential for system, domain and data
compromise. The potential security issues that are raised from
merely being able to install a service in this manner can also
affect Windows NT 4.0 computers.
Note: This service beeps every 30 seconds to aid in identifying
that this service is installed. We do not wish for this utility
to be used for malicious or unethical purposes so the beep is
included as a deterrent and identifying mechanism.
This vulnerability exists as part of the default installation of
Windows NT 2000 and is actually by design. Each NT user is
generated a public and private encryption key pair. This process
is automatically controlled by the default security policy on the
computer or by the ADS domains default domain security policy.
When a user invokes EFS by marking a file as encrypted, EFS by
default generates a 128-bit random secret key called a File
Encryption Key or FEK. (It is possible to use variable sized keys
but 128-bit is the default. Export versions still require 40-bit).
The secret FEK is then used to do a block DES cipher of the file,
converting the file from plain text to cipher text. The users
public encryption key is then used to encrypt the FEK and this
encrypted FEK is stored as an attribute of the encrypted file as
the Data Decipher Field or DDF. The file is then protected from
prying eyes and can be decrypted only by the user. When the user
attempts to access this file, EFS is again invoked but this time
the file is decrypted. To decrypt the file, EFS takes the users
private key and the DDF attribute, combines them in an algorithm
and recovers the secret FEK. The FEK is then used to decrypt the
file from cipher text to plain text. This entire process is
fast, painless and invisible to the user. This type of security
is great for individual users but in an enterprise environment
this can cause potential problems. The most critical of these
problems being recovery of encrypted data if the user is not
available. To insure that all encrypted files on Windows NT 2000
computers can be recovered Microsoft deploys the concept of
Recovery Agents (RA). RA's have the ability to decrypt any
encrypted file on the system. This is accomplished by having a
second attribute field on the encrypted file called a Data
Recovery Field or DRF. Just as the DDF contained the FEK
encrypted with the users public key so the DRF contains the FEK
encrypted with the RA's public key. To insure that files can be
recovered, Windows NT 2000 enforces a default security policy
that makes the Administrator a Recovery Agent.
SOLUTION
The problem with the attack outlined is that the user has to have
left the recovery key on the machine in order for it to be
compromised. The help files for EFS recommend that the recovery
key be exported for just this reason. Administrator accounts are
sometimes compromised, even if only because the admin chose a
really weak password; because of the importance of the EFS
recovery key, it's very important that the private key be
physically separated from the machine.
In addition, scenario uses the default recovery policy, which
specifies the local administrator as the recovery agent. However,
in any networked configuration, the first thing that should have
been done was to change the recovery policy to make the domain
administrator (or some other domain authority) the recovery agent.
This is the more likely operational use of EFS -- a central
domain authority having the ability to recover encrypted files
that were generated by any domain user. The advantage it would
have in the specific scenario you described is that the recovery
agent's private key would once again not be present on the
machine.
Finally, it is recommended using SYSKEY to strongly protect the
SAM and other security-relevant information. If this had been
done, it would not have been possible to compromise the machine
by simply deleting the SAM -- the attacker would have been
prompted at boot time for the SYSKEY key, which (if good practices
have been followed) would not be on the machine.