Problem solve Get help with specific problems with your technologies, process and projects.

Windows Resource Protection (WRP) protects critical system resources

Windows Resource Protection (WRP) has undergone some changes since it's predecessor, Windows File Protection (WFP) was used to protect critcal Windows system files. Learn about WRP's evolution and what it means to the security of your Windows shop in this excerpt from "Hacking Exposed Windows."

Hacking Exposed Windows
By Joel Scambray

Have a look inside the third edition of Hacking Exposed Windows : Microsoft Windows Security Secrets and Solutions by Joel Scambray, with this excerpt from chapter 12, "Windows security features and tools."

Like Windows 2000 and Windows XP, Windows Vista comes equipped with a mechanism to protect critical system resources. It's called Windows Resource Protection (WRP). Like its ancestor, Windows File Protection (WFP), WRP attempts to ensure that critical files are not intentionally or unintentionally modified. However, WRP takes this one step further by protecting registry values as well.

Like WFP, WRP stashes away copies of files that are critical to system stability. The location, however, has moved from %SystemRoot%\System32\dllcache to %Windir%\WinSxS\Backup, and the mechanism for protecting these files has also changed a bit. There is no longer a System File Protection (SFP) thread running to detect modifications to critical files. Instead, WRP relies on Access Control Lists (ACLs). As such, it should be no surprise that WRP is always enabled.

Hacking Exposed Windows
Buffer overflows can be prevented by GS cookies

The finer points of User Account Control (UAC) in Windows Vista

Service level security in Windows Vista and Windows Server 2008

Under WRP, the ability to write to a protected resource is granted only to the TrustedInstaller principal -- this excludes administrators as well. This can be observed in Figures 12-15 and 12-16.

Like other discretionary ACLs, those supporting WRP can be modified as well. In a moment, we will discuss how they can be modified to allow the replacement of WRP-protected resources. In the absence of these modifications, only the following actions can replace a WRP-protected resource:

• Windows Update installed by TrustedInstaller
• Windows Service Packs installed by TrustedInstaller
• hotfixes installed by TrustedInstaller
• operating system upgrades installed by TrustedInstaller

Figure 12-15

Administrators lacking write privilege

Figure 12-16

TrustedInstaller with full control

As previously mentioned, workarounds for WRP exist. By default, the local administrators group has the SeTakeOwnership right, as shown under User Rights Assignment within the Local Security Policy (Figure 12-17).

With this privilege, a principal can take ownership of the WRP-protected resource. At this point, permissions applied to the protected resource can be changed arbitrarily by the owner, and the resource can be modified, replaced or deleted.

Remember that WRP isn't designed to be an end-all security feature. The primary purpose for this technology is to prevent third-party installers from modifying resources that are critical to the OS's stability. One of the benefits of knowing how to disable WRP is to make life easier when you're reverse-engineering or instrumenting a process. Depending on what you're after, you may want to alter the process's behavior. To do this, you have two primary choices: patch the process during runtime or patch the .dll or .exe on disk. The former requires you to apply the patch every time the process executes, the latter is a one-time shot.

Figure 12-17

Administrators group with SeTakeOwnership privilege.

Dig Deeper on Windows applications

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.