Message-ID: <000f01c4c66a$67e6d2b0$668b28c8@administrator>
From: jeff at adinet.com.uy (Jeff Donahue)
Subject: Silencing Windows File Protection

You're right, except that it's necessary to reboot for this to start 
working. Tested it on a Windows XP SP2 machine and received no warning after 
setting the appropiate registry value and rebooting.

----- Original Message ----- 
From: "Fixer" <fixer907@...il.com>
To: <full-disclosure@...ts.netsys.com>
Sent: Monday, November 08, 2004 10:14 PM
Subject: [Full-Disclosure] 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?
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html 

Powered by blists - more mailing lists