Sysinternals Freeware - Mark Russinovich & Bryce Cogswell

Mark's Sysinternals Blog

Circumventing Group Policy as a Limited User

Active Directory Group Policy settings are widely used to secure Windows systems because they can be customized to target and deploy to specific computers and users in an Active Directory-based network. In a previous blog post I warned that one of the risks of having end-users with local administrative privilege is that they can override group policy settings at will and I promoted limited-user accounts as the secure alternative. However, Windows administrators should be aware that if a user, even one running with a limited account, can execute just one program of their choice that they also can circumvent many group policy settings, including ones aimed specifically at tightening security such as Software Restriction Policies and Internet Explorer Zones.

The vulnerability within many group policy settings is that the applications at which they are directed enforce the settings. For example, Explorer limits execution of certain applications if Group Policy dictates and Internet Explorer implements Zone security. The Windows architecture sets security permissions on a process that allows the owner of the process full control over the process, which you can verify in the Permissions dialog that you access from the properties dialog of a process in Process Explorer:

That means that users can alter the code or data of their own processes, including Explorer and Internet Explorer, and by manipulating the code or data related to Group Policy enforcement they can bypass Group Policy settings.

Software Restriction Policies (SRP) are another example of Group Policy settings that can be subverted by limited users if you allow them to run an arbitrary executable – in other words, if you don’t apply SRP correctly by using it to define the executables users can run (whitelisting) instead of simply singling out executables that you don’t want them to run (blacklisting). When a user launches a process it’s the parent process that checks SRP to see if the execution of the child should be allowed or blocked, allowing the owner of the parent process to manipulate the process into bypassing or negating SRP processing. There are many ways of accomplishing that, including writing a program that reaches into the parent’s address space and changes the Registry path strings that refer to SRP storage or overwriting the code that reads SRP Registry settings.

I’ve written a simple application, Gpdisable, that demonstrates the ease with which SRP can be disabled by even a limited user. The program uses the DLL injection techniques described by Jeff Richter in Programming Applications for Microsoft Windows (Microsoft Press) to load a DLL into all the processes on the system to which the user running it has access. The DLL places a hook on the NtQueryValueKey API so that it intercepts any calls of the API made by those processes or the DLLs they’ve loaded. The Windows SRP code uses NtQueryValueKey to query the Registry value HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled, which if present and non-zero indicates that SRP is turned on. Here’s a Regmon trace of Cmd.exe, the Command Prompt, reading the value in response to an attempted execution of Notepad.exe, which I’ve disallowed using SRP:

Users don’t have permission to modify keys under HKLM, including the SRP settings, but Gpdisable fools the SRP code by returning an error value, STATUS_OBJECT_NAME_NOT_FOUND, whenever it sees a value named “TransparentEnabled” passed to NtQueryValueKey:

This screenshot shows the “The system cannot execute the specified program.” error SRP reports in the failed attempt to run Notepad.exe in a limited user account followed by execution of Gpdisable and subsequent successful execution of Notepad.exe:

Note that existing processes that have already launched children, such as Explorer and Command Prompt, cache the TransparentEnabled value and so will continue to enforce SRP. You could almost as easily override that by modifying a program like Gpdisable to reach into them and change their cached values.

The Regmon trace of the second Notepad execution looks similar to the first with the major exception that the query of TransparentEnabled is missing: Gpdisable intercepted it in user-mode and so the call never progressed into the kernel:

What other Group Policy settings are susceptible to this type of attack? System-wide security settings are enforced by core operating system components not accessible to limited users, but most of the settings in the Windows Components area of the Group Policy editor’s Administrative Templates node are ineffective in environments where end-users can run arbitrary applications such as Gpdisable:

Notably, Internet Explorer configuration, including Zones, fall into this area, as do Explorer, Media Player, and Messenger settings. The bottom lines is that full control of an end-user environment is possible only with strict lock-down of the programs users run, something that you can accomplish by using SRP in white-list mode, for example. It's also important to note that the ability of limited users to override these settings is not due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.

posted by Mark Russinovich @ 11:37 AM

Hey Mark; now you're writing root kits (GRIN)... Anyway, good info as usual. It goes right back to the things we've complained about in windows for years: the GUI's of each app actually doing the checking on things. For example in the Windows NT 4 world, you could set the policy saying the user can't run regesit. But since regedit only checked the policy when it was creating its main window - things like regedit /s still worked for that user. MS still has a lot to fix in this area as you've shown. Thanks!
Can one download GPDisable? Might come in handy if an administrator enables SRP and locks himself out of everything.
Where is Gpdisable????
Nice one Mark! Stimulating as usual. Surely the failure here is with the security policy in effect. A policy that blocks only "known" apps from running is bound to fall on it's back or you'll run yourself ragged catching up on new apps to stop. As you briefly stated, a "whitelist" policy would make GPDisable unable to run.
Can one download????
Yup, I carry around a cmd.exe and regedit.exe I modified that ignores GP. Great for quick troubleshooting on a locked down machine.
The first reference to gpdisable in the post now links to the zip file for download.
Speaking of group seems you can prevent the running of cmd.exe via Group Policy, but Group Policy has no effect on running, the 16-bit version of the command interpreter.
Another way to circumvent some policies is to unplug the computer form the network while it boots so it bypasses any computer policies, logon with cached credentials then plug the cable back-in.

I never really used this to circumvent security policy, but rather to get around a GPO Software Deployment assigned to compters of a specific OU. The software deployment hung at ever boot, so logging on with cached credentials with the cable unplugged was a workaround.

I wonder if this could also be used to bypass some security policies...
I've been doing some security testing on deployment citrix servers lately, to check that they're locked down sufficiently. CMD.EXE is disabled, and COMMAND.COM's NTFS permissions are set to deny local users. Regedit is also disabled. I've found that I can run .bat and .cmd files though.

I've been wondering how I can use this wonderful bit of code in a batch script to gain a command shell, but have been drawing a blank thus far. Any suggestions?
"but rather enabled by design decisions made by the Microsoft Group Policy team."

I would suspect that is because the internal Microsoft IT Dept has no respect for employee privacy. The Group Policy teams didn't want to make the rope that would be used to hang them.
Nice, altough I think that some people will not read it until the end and won't understand it and will post in a tech site something like "new vulnerability allows to circumvent windows group policies"
Sean D - not sure about cmd or bat files... but I just tried this - I locked down cmd.exe and calc.exe and ACL'd and was still able to launch calc.exe with a simple command launching gpdisable, specifying calc.exe.
For the blogger that mentioned unplugging the network cable during the boot process as a method to "get around" the application of computer policy. That's not entirely correct. What you're getting around is the policy update mechanism. Policy is applied from a local cache. If the network is unavailable then the computer will simply detect that and jump straight to the application of the cached policies. Plus, after the boot process policy will reapply at specific intervals even if no change has occurred.
For the blogger that mentioned unplugging the network cable during the boot process as a method to "get around" the application of computer policy. That's not entirely correct. What you're getting around is the policy update mechanism. Policy is applied from a local cache. If the network is unavailable then the computer will simply detect that and jump straight to the application of the cached policies. Plus, after the boot process policy will reapply at specific intervals even if no change has occurred.
Great article Mark! Do you know if in windows vista the engine of software restriction will change?
Wow. This site is great. I have no words to said more than thanx.

I'm admin. How can i protect my network from this exploit?
I'm admin. How can i protect GP from this exploits?
krneki, read the last paragraph.
Ive been using SRP for a few months and found it worked great for internet-outward facing programs and other nasty's that try to get a grip of HKLM (such as Limewire/AUX Magnet Key??). Now Mark's gone and blown this away...sweet.
So for a white-list, which executables are in need of and/or safe to lock down??
If I use SRP on system files Im gonna get problems, so I'd would be nice if someone knowledgable could start a SRP whitelist....? Or do we just apply a Basic User rule to /Program Files/

"Where is Gpdisable????"

My first thought when I saw this post was that some nasty script writer would like to implement Mark's work into something else....just a thought.
SAFER is inherintly unsafe if the the default rule is allowed. At best, it is a security management solution where an admin can send out a disallow rule to block naive user from accidentally click on a malware. The technique Mark described will not work if the default rule is disallowed and only a limited set of allowed programs and DLLs are permitted to run via allow rules (path, hash, or certificate). You can even make all internet facing applications, like IE, to run as basic user by creating a basic user level rule on these applications.

The settlement process has begun in The Electronic Frontier Foundation class action lawsuit against Sony BMG for the flawed digital rights
management(DRM) that Sony BMG released in millions of CDs over the last several years.

DMusic has been working with EFF to notify as may people as possible so they can get some redress against Sony BMG pursuant to the class action settlement, or alternatively, choose to seek compensation against Sony BMG individual in their own lawsuit.

Music fans who bought the affected CDs can submit claims for clean music. Many customers are also eligible for extra downloads or a small cash settlement.

SO PLEASE CHECK OUT for more details about the settlement, including a list of the CDs affected. AND MAKE sure you don't stick an infected CD in your computer - it will plant malicious spyware that is difficult to remove!
Policy is not applied at all if a DC cannot be reached. Unplugging the network and logging on with cachedcredentials prevents GP processing and therefore the previous refresh of policy remians in effect. There is never an application of policy form a local cache.
"I wonder if this could also be used to bypass some security policies... "
Downloading the "regtools.vbs on" will allow a off-line computer (if vbs is allowed) to turn on all registry editing tools. You can then change many restrictions set by GP's and make the changes you wish and you'll likely find that many of the changes in the registry stays when you login again and teh GP is returned.
Another approch in some systems when restrictions are enforced by scripts is to use Mark's Autoruns to kill the entries that run startup scripts when you are login with a connection to the network. Not uncommon on larger corporations networks as far as I've seen.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

RSS Feed



Full Blog Index

Recent Posts

Premature Victory Declaration?
Sony: No More Rootkit - For Now
Sony: You don’t reeeeaaaally want to uninstall, do you?
Sony’s Rootkit: First 4 Internet Responds
More on Sony: Dangerous Decloaking Patch, EULAs and Phoning Home
Sony, Rootkits and Digital Rights Management Gone Too Far
The Bypass Traverse Checking (or is it the Change Notify?) Privilege
Registry Junk: A Windows Fact of Life
Multi-platform Images


03/01/2005 - 03/31/2005
04/01/2005 - 04/30/2005
05/01/2005 - 05/31/2005
06/01/2005 - 06/30/2005
07/01/2005 - 07/31/2005
08/01/2005 - 08/31/2005
09/01/2005 - 09/30/2005
10/01/2005 - 10/31/2005
11/01/2005 - 11/30/2005
12/01/2005 - 12/31/2005
01/01/2006 - 01/31/2006
02/01/2006 - 02/28/2006
03/01/2006 - 03/31/2006
04/01/2006 - 04/30/2006
05/01/2006 - 05/31/2006
07/01/2006 - 07/31/2006

Other Blogs

Raymond Chen
Dana Epp
Aaron Margosis
Wes Miller
Larry Osterman
Bruce Schneier
Larry Seltzer