Windows Resource Protection (WRP) protects critical system resources

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.

This was first published in June 2008

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.