:: Deepquest ::

many people requested that file originaly posted here on my old site before ISP was raided 5 years ago: http://www.deepquest.pf/win32/win2k_efs.txt

Windows 2000 Encrypting File System (EFS) Vulnerability

Released: July 25th,1999

Copyright 1999

License is granted for use and distribution of this document and its contents only if the document is reproduced in its entirety or references to this documents content includes identification of the source of the information and credit given to the documents authors.

Any other use of this document is prohibited without the express written approval of the documents authors.

The information contained in this document is for informational purposes only. The authors make no warranties, express or implied, in this document. The authors are not liable for the use or misuse of the content of this document.

Windows NT, Windows NT 2000, The Windows 2000 Logo are registered trademarks of Microsoff Corporation.

Other products or company names mentioned herein may be the trademarks of their respective owners.

Summary:

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:” 1

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 we have uncovered.

Issue:

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

Verified Affected Software Versions:

* Windows NT 2000 Beta 3 build 2031 (Professional, Server, Advanced Server) * Windows NT 2000
Release Candidate build 2072 (Server, Advanced Server)

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

How this is possible:

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.

It is by leveraging this recovery agent security policy and the DRF attribute of the encrypted files that we are able to access any encrypted file on the Windows NT 2000 server.

What users can do? :

GO TO [url=http://www.microsoft.com/security/bulletins/win2kefs.asp]http://www.microsoft.com/security/bulletins/win2kefs.asp[/url] to see Microsoft’s response to our paper.

It describes how you must export your certificates and/or use SysKey to Encrypt your registry if you want to keep your data secure.

Contact information:

James J. Grace
[email]jgrace50@hotmail.com[/email]

Thomas S. V. Bartlett III
[email]Tbartlett_III@hotmail.com[/email]
Resources & References:

[url=http://www.microsoft.com/windows/server/default.asp]http://www.microsoft.com/windows/server/default.asp[/url]
[url=http://www.microsoft.com/windows/server/Technical/security/encrypt.asp]http://www.microsoft.com/windows/server/Technical/security/encrypt.asp[/url]
[url=http://www.microsoft.com/windows/server/zipdocs/encrypt.exe]http://www.microsoft.com/windows/server/zipdocs/encrypt.exe[/url] (White Paper)
[url=http://msdn.microsoft.com/library/sdkdoc/winbase/fsys_1fou.htm]http://msdn.microsoft.com/library/sdkdoc/winbase/fsys_1fou.htm[/url]
[url=http://www.europe.hp.com/desktops/partners/microsoft/tomorrow.html#Ultimate]http://www.europe.hp.com/desktops/partners/microsoft/tomorrow.html#Ultimate[/url]
[url=http://www.europe.hp.com/desktops/partners/microsoft/faq.html#q2]http://www.europe.hp.com/desktops/partners/microsoft/faq.html#q2[/url]
[url=http://www.zdnet.com/devhead/stories/articles/0,4413,343083,00.html]http://www.zdnet.com/devhead/stories/articles/0,4413,343083,00.html[/url]

1 All quotes taken from Microsoft Windows 2000 Server White Paper entitled: Encrypting File System for Windows 2000.