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.
