Full Disclosure mailing list archives
Re: Silencing Windows File Protection
From: "Jeff Donahue" <jeff () adinet com uy>
Date: Tue, 9 Nov 2004 11:42:58 -0300
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 () gmail com>
To: <full-disclosure () lists 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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Silencing Windows File Protection Fixer (Nov 08)
- Re: Silencing Windows File Protection Jeff Donahue (Nov 09)
- Re: Silencing Windows File Protection Fixer (Nov 09)
- Re: Silencing Windows File Protection Jeff Donahue (Nov 09)