From: fixer907 at gmail.com (Fixer)
Subject: Silencing Windows File Protection

That's peculiar as I didn't need to reboot for either OS.  I was
simply able to swap the files and go.  I wonder what would have caused
that to happen in your case.

-Fixer


On Tue, 9 Nov 2004 11:42:58 -0300, Jeff Donahue <jeff@...net.com.uy> wrote:
> 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