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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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 > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
