Blocking Windows XP user group policy by exploiting a roaming profile vulnerability

For users that roam from workstation to workstation, roaming profiles can be a life saver. All the users settings and customizations move with them and save bucket loads of configuration.

There is a huge security hole with the Windows XP roaming profile model thought, as the HKEY_CURRENT_USER hive is synchronized to the network, any customizations to the security permissions are also synchronized. It is therefore possible to totally block group policies from applying at the HKEY_CURRENT_USER level with a few easy steps.

While this doesn't affect computer level policies in the same way, they are rarely used to enforce restrictions such as blocking regedit, command prompt or the run command. Incidentally a user in a high security environment can bypass these restrictions throughout the whole network by access a single vulnerable machine.

The following steps must be performed as a local Administrator. Hold on, did you say as an Administrator? Doesn't that ruin the whole security hole arguement? In fact there are so many vulnerabilities in Windows XP that unless the patch management of the environment is good, you should be able to elevate to Administrator or SYSTEM on some computer throughout the enviroment.

Even easier is to use the "vBootkit" by Nitin and Vipin Kumar. This ingenious boot CD allows the attacker to elevate any process to system level privileges by loading a temporary rootkit into the MBT. For example we could designate the vBootkit to elevate cmd.exe to SYSTEM token after we launch it, or if command prompt is currently blocked with policy we could elevate a 3rd party task manager or launcher.

The beauty of the vBootkit is as soon as you reboot, its gone, it only loads itself into the memory space of the single boot.


Could it get any easier?

1. After elevating yourself to an Administrator or SYSTEM prompt (perhaps via the Kumar's vBootKit), launch a regedit session.

2.  After I navigate to my "HKEY_CURRENT_USER\Software\Policies" key, you can see a number of policies that are set to apply to my account. These have likely been added via domain group policy.

3. If we right click the Policies key and select permissions, we find the SYSTEM has full control over this key.

5. The SYSTEM account is used to deliver group policies directly to this "HKEY_CURRENT_USER\Software\Policies" registry key. By setting the SYSTEM account to Deny permissions. as per the image below, we effectively block the system from being able to apply its group policies to my account.

Computer policies will still continue to function, but you can use the same technique on the "HKEY_LOCAL_MACHINE\Software\Policies" hive to block computer policies. The difference is HKLM changes won't follow you from computer to computer like HKCU policies will in a roaming profile environment.

6. The next step is to delete all the existing policies (unless there is any you want to keep of course). We can now potentially unblock Internet Explorer restrictions, allow the command prompt and perhaps even stop a login script from running.

7. Now if you run a gpupdate you will find the policies don't reapply, your HKCU policy free! The next time you log off these policy permission changes will be synchronized to the network and you will be exempt from HKCU policies on every machine login.

You can see how devastating this could potentially be. A systems administrator doesn't patch an edge workstations as early as early as he or she should, an employee elevates themselves to local administrator and applies these group policy blocks, the changes synchronize to the network. All of a sudden that same employee has allot more flexibility to launch attacks from more privileged workstations (that are running roaming profiles) in other parts of the network.

Possible ways of mitigating the attack

I think the easiest way to mitigate the attack is auditing. Regular checking, or scripted checking of NTUSER.DAT hives on the network share the roaming profiles reside.

I have played around with scripting to mount the hive as read-only (with reg load), check the Policies key for SYSTEM permissions irregularities with subinacl, report on any unusual findings and then un-mount the hive.

Using subinacl and the below string we can audit the current status of the SYSTEM account that is used to apply the group policy to the user "HKEY_CURRENT_USER\Software\Policies" key.

subinacl /verbose=1 /keyreg "HKEY_CURRENT_USER\Software\Policies" /display=dacl

You could very simply do this with a batch or kixtart script and have it run on a weekly or monthly basis and e-mail the dodgy findings directly to you.