Circumventing Group Policy as a Limited User

Active Directory (AD) Group Policy settings are widely used to secure Windows systems because you can deploy them to specific computers and users in an AD-based network. In an earlier blog post, I warned that one of the risks of having end users with local administrative privileges is that they can override Group Policy settings, and I promoted Limited User accounts as the secure alternative. However, Windows administrators need to be aware that if users, even users running under a limited account, can execute just one program of their choice, they can circumvent many Group Policy settings, including security-tightening settings such as Software Restriction Policies and Microsoft Internet Explorer (IE) security zones.

The problem with many Group Policy settings is that the applications at which they re directed enforce the settings. For example, Windows Explorer limits the execution of certain applications if Group Policy dictates, and IE implements zone security. The Windows architecture sets security permissions that give the owner of a process full control over that process. That means that users can alter the code or data of their own processes, including Windows Explorer and IE. If users manipulate the code or data related to Group Policy enforcement, they can bypass Group Policy settings.

Software Restriction Policies are another example of Group Policy settings that can be subverted by users with limited accounts. If you use Software Restriction Policies to single out executables that you don t want users to run (blacklisting) instead of defining the executables users can run (whitelisting), users might be able to run an arbitrary executable. When a user launches a process, the parent process checks Software Restriction Policies to see whether to allow the execution of the child process. The owner of the parent process could manipulate the process into bypassing Software Restriction Policies processing.

I've written a simple application, Gpdisable, that demonstrates the ease with which even a limited user can disable Software Restriction Policies. (You can view the code and sample execution on my blog at http://www.sysinternals.com/blog/2005/12/circumventing-group-policyas-limited.html.) The program uses DLL injection techniques 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 the DLL intercepts any calls of the API made by those processes or the DLLs they've loaded. The Software Restriction Policies code uses NtQueryValueKey to query the registry value HKEY_LOCAL_MACHINESoftware PoliciesMicrosoftWindowsSaferCodeIdentifiersTransparentEnabled, which, if present and non-zero, indicates that Software Restriction Policies is turned on. Gpdisable fools the Software Restriction Policies code by returning an error value, STATUS_OBJECT_NAME_NOT_FOUND, whenever it sees a value named TransparentEnabled passed to NtQuery-ValueKey.

What other Group Policy settings are susceptible to this type of attack? Systemwide security settings are enforced by core OS components that aren't accessible to limited users, but most of the settings in the Windows Components area of the Group Policy Editor's (GPE's) Administrative Templates node can be circumvented in environments in which end users can run arbitrary applications such as Gpdisable. Notably, IE configuration, including security zones, falls into this area, as do Windows Explorer, Windows Media Player (WMP), and Windows Messenger settings. The bottom line is that full control of an end-user environment is possible only with strict lockdown of the programs that users run, for example by using Software Restriction Policies in whitelist mode. It s also important to note that the ability of users with limited accounts to override these settings isn't due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.