OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Logon DoS to Windows 2000 through EFS
From: Brandon Lay (blayEASYSTREET.COM)
Date: Thu Jul 20 2000 - 17:49:48 CDT

Greetings,

NTBugTraq is the first place this has been posted. I hope MS is paying
attention.

The Problem:

If a user encrypts Autoexec.bat on a Windows 2000 NTFS system volume, no
user will be able to logon locally or access resources shared on this
computer remotely, not even Administrator.

Description:

Windows 2000 NTFS volumes support the Encrypting File System as built-in
functionality. This is a certificate-based encrypting system. Any user that
can be authenticated and has Write permission to a file, such as
Autoexec.bat (default is Full Control) can potentially encrypt the file by
right-clicking in Explorer, selecting Properties, clicking on the Advanced
button, and selecting Encrypt Contents to Secure Data. This functionality
should be seriously considered, as files encrypted by one user cannot be
shared with any other user (by default). Regardless of permissions or
ownership, if you encrypt a file, no one else can "open" the file. Of
course, because of this functionality, one would think you couldn't encrypt
system files. Well, if you attempt to encrypt the Winnt folder or the system
boot files (NTLDR, NTDETECT.COM, BOOT.INI), you will be denied access to
encrypt it. This is good.

However, there is no such protection on Autoexec.bat. Once this had been
done to Autoexec.bat, the next user to attempt a local logon will see the
dialog box with the message "Loading your personal settings..." and the
system just sits there waiting. My assumption is that Autoexec.bat is parsed
for environment variables on every logon. Since the file has been encrypted,
it can't be accessed unless the user who encrypted it presents a
certificate. The certificate is stored in the user's profile. Catch 22. The
user's profile hasn't actually been loaded yet, preventing access to the key
certificate that may (as in the case of the user who did the deed) decrypt
the file. Thus Autoexec.bat can't be read and somehow prevents the system
from continuing to load the user's profile. So not only does this prevent
other users from logging on, but also the user who encrypted it, and any
Recovery Agents (such as the Administrator account).

Here is a summary of my observances:

        1. After encrypting Autoexec.bat and logging off, you can't log on, system
hangs.
        2. If you think you will remotely access \\computername\c$ and decrypt it,
forget it. You can connect, which takes a while, but then the connection no
longer responds. In otherwords, you eventually see the contents of C$ in a
window, but it won't respond to any action. This is odd, since I thought I
understood the authentication process, that access to Autoexec.bat would
cause remote connectivity problems. (I wonder if denying read access would
cause the same behavior here. Hmmm, I didn't try this.)
        3. You cannot fix in any of the following ways (all tested): Through remote
access, safe mode, safe mode with command prompt. I'm going to assume that
the Emergency Repair process would do nothing for you, but I haven't tested
it yet, so don't quote me.

To Reproduce:

Logon locally to any current release version of Win2k - Pro, Server,
Advanced Server have been tested - with NTFS 5.0. Log on using any user
account (local or domain) and encrypt Autoexec.bat using the method
described above. Log off, and attempt to log on.

To Repair:

Boot to the Recovery Console (refer to article Q229716 for the How-To), log
on to your Win2k installation using the "administrator" password (must be
THE Administrator account), use the CD command to go to the root of the
drive, and delete Autoexec.bat. Before deleting it, you can verify it is
encrypted by using the DIR command which shows all attributes for files and
folders. On Autoexec.bat, you will notice the "e" attribute appears. Now if
you installed the Winnt folder on a different volume than your active, or
system, volume, you will need to change drive letters and then delete the
file.

The Possible Preventative Solutions (until this is hopefully fixed): (Pick
One)

* Set the NTFS Read permission for Authenticated Users on Autoexec.bat. If
you can't write to it, you can't encrypt it. Remove any other permissions
inherited or assigned.
* Disable EFS on stand-alone Win2K machines. To do this refer to Microsoft
article Q243035.
* Disable EFS domain-wide. Refer to Microsoft article Q222022.

BTW, deleting the file (since apparently we don't need to have it, but if
it's there we need to read it!) doesn't give you a preventative solution. As
a user could just create a file named Autoexec.bat on you System partition
and then encrypt it.

I'm not sure if I've tried every angle on this, so feedback is welcome.

Brandon Lay, MCSE+I, MCT, CCNA
Independant Consultant
blayeasystreet.com

----------------------------------------------------------------------------
Delivery co-sponsored by eEye Digital Security
============================================================================
Vulnerability Is Over ... eEye Digital Security Announces Retina(tm)

Retina is the first security software application with state-of-the-art
artificial intelligence features that allow it to think like a hacker. Other
security scanners search for known vulnerabilities, Retina uses built-in
features designed to handle 'what if' scenarios. Retina gives you the most
comprehensive network security analysis available. Available for download;
<http://www.eeye.com/click.asp?referrer=ntbugtraq2&P;=retina>
----------------------------------------------------------------------------