Re: [Full-Disclosure] Silencing Windows File Protection

From: Jeff Donahue (jeff_at_adinet.com.uy)
Date: 11/09/04

  • Next message: debian-security-announce_at_lists.debian.org: "[Full-Disclosure] [SECURITY] [DSA 589-1] New libgd1 packages fix arbitrary code execution" 
    To: "Fixer" <fixer907@gmail.com>, <full-disclosure@lists.netsys.com>
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

  • Next message: debian-security-announce_at_lists.debian.org: "[Full-Disclosure] [SECURITY] [DSA 589-1] New libgd1 packages fix arbitrary code execution"

    Relevant Pages

    • Re: Seem to have lost Calc.exe in Win XP
      ... , and/or malware. ... Windows File Protection of a successful replacement or error ... is the System log - look at the events from WFP. ... That could mean the the one in dllcache is wrong (as far as XP is ...
      (microsoft.public.windowsxp.general)
    • Re: Windows 2000 WFP
      ... From: Jim Nugent ... Conversation: Windows 2000 WFP ... It sounds like WFP simply consults the dllcache and servicepackfiles ...
      (microsoft.public.win2000.setup_upgrade)
    • [Full-Disclosure] Silencing Windows File Protection
      ... the best way to bypass Windows File Protection (WFP) was ... The second is the dllcache ...
      (Full-Disclosure)
    • Re: Seem to have lost Calc.exe in Win XP
      ... Check Event Viewer System log for source: Windows File Protection ... (There may be a second set of 2 reports when you ran WFP again.) ... That could mean the the one in dllcache is wrong (as far as XP is ...
      (microsoft.public.windowsxp.general)
    • PC cards stopped working after uninstal of hotfixes
      ... I had started getting some error message or other and googled it and found ... corrupted and wouldn't start explorer. ... loading windows stopped to Task Manager and then start explorer from the ... If explorer.exe is running from dllcache and my sfc /scannow ran from ...
      (microsoft.public.windowsxp.setup_deployment)