Message-ID: <6f5565af041108171440f53f2a@mail.gmail.com>
From: fixer907 at gmail.com (Fixer)
Subject: Silencing Windows File Protection

Hi all,

In the past, the best way to bypass Windows File Protection (WFP) was
to attempt to set it to the known registry value that would shut it
down completely.  This was the vector used by Code Red II and other
forms of malware.  This technique was effective until Microsoft
changed this value to make it operating system and service pack
specific, thus making it infeasible for general use.

There exists, however, another mechanism for silencing, rather than
shutting down, WFP.  This mechanism represents an interesting flaw in
the operation of WFP and has a variety of potential uses.  While this
is not an exploit in and of itself, it can potentially be used by
various types of malware as a method for keeping access to a
compromised machine or for installing additional malicious code such
as backdoors, keyloggers, etc.  Keep in mind that this, like other
attacks against WFP, requires the attacker/malware/etc. to have
administrator permissions on the target computer.  This isn't an issue
for malware that is exploiting a known vulnerability and then simply
using this technique to hold on to that access.

Details:

In order to bypass WFP, it is necessary to navigate to the following
registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Contained within this key is the value SFCDisable.  This value is of
the DWORD type and can be set from 0 to 4.  Setting it to 1 or 2
requires the use of a debugger and is not relevant to this discussion.
 When setting this value to 0, WFP operates normally.  Setting this
value to 4, however, produces a very interesting result.  With this
value, WFP is still enabled, but all notifications (including all
Event Log entries) are suppressed.   This allows for the replacement
of critical system files with no warnings from Windows.

Files that are protected by WFP are typically stored in two locations.
 The first location is the primary location of the file
(c:\winnt\system32 for example).  The second is the dllcache
directory, which is a subdirectory of the system32 directory.  The
dllcache directory serves as a backup directory for all critical files
that WFP protects.  In the event that a critical file changes it is
replaced from the copy in the dllcache directory.  As such it is
necessary to replace both the primary copy and the dllcache copy. 
Additionally it will be necessary to first delete the copy in the
dllcache to ensure that the computer cannot simply replace the primary
file with a copy from the dllcache.

Execution Steps:

In order to properly execute this, the following steps must be taken
in precise order:

+ Set the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\SFCDisable to 4

+ Delete the target file in the dllcache directory

+ Delete the primary copy of the target file

+ Replace the dllcache and primary copies of the target file with the
new copies.  The order is irrelevant.

+ Set the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon to 0 (this step is optional)

It should be noted that, according to Microsoft, WFP was designed as a
system stability feature, not a security feature.  In order to fix
this problem it would be necessary to redesign the entire WFP
architecture.  Given that, Microsoft's official response was that the
necessary solution would likely be implemented in Longhorn.

As previously stated this is NOT an exploit by itself, simply a way to
keep access once you've got it and maybe install some additional
malicious code in the process.

Miscellaneous Notes:

+ This process has been tested and verified under Windows 2000 SP4 and
Windows XP SP2.

+ Using SFC /scannow will remove the altered files in the dllcache
directory (but not in the primary directory) but it will not alert the
administrator as to which files were altered.  Additionally there will
be the risk of causing software issues because of where SFC gets its
replacement files from.

+ Replacing the original application in the dllcache will not result
in WFP recognizing that a different application is in the primary
location and copying the correct application into the primary
location.  Once the application has been deleted from both locations
it appears that WFP does not track the application as part of its
database from that point on.

Hiya to all the H3 kennels out there...

-fixer
____________________________________________________________________________
Sed Quis Custodiet Ipsos Custodes?

Powered by blists - more mailing lists