Windows 2008 Server introduced a new feature known as Group Policy Preferences that allows administrators to deploy specific configurations that affect computers/users within a domain. This post details a serious problem associated with the use of Group Policy Preferences, specifically when a policy includes a username and encrypted password, which can result in a normal user being able to escalate their level of privilege on their local desktop/laptop and potentially compromise the security of the entire domain.
I would like to point out that I did not discover this vulnerability and it is not something new, in fact it has been well documented on the Internet for over a year. It is however clear that not all systems administrators are aware of the associated risks when using Group Policy Preferences, as I continue to see their use.
What are Group Policy Preferences?
Group Policy Preferences were introduced in Windows Server 2008 and provide additional functionality over Group Policy Objects (GPOs). Group Policy Preferences allow administrators to deploy specific configurations that can be configured to affect all computers/users within a domain, or target specific users/groups of users only.
Configured within the Group Policy Management Console, Group Policy Preferences allow administrators to push out a ultitude of policies, such as automatically Mapping a Network Drive when a user logs into their computer, updating the username of the Built-in Administrator account, or making changes to the Registry.
Group Policy Preferences can also be used with earlier versions of Windows, however additional client-side extensions are required to be installed. Further details can be obtained via the Microsoft Group Policy Preferences Getting Started Guide.
Group Policy Preference Example XML Configuration File
In this post I am not going to detail the steps taken to create and deploy a new policy through Group Policy Preferences, however the following provides an example of a Group Policy Preference XML configuration file that I have created to update the name and password of the Built-in Administrator account across all systems on which it is deployed:
You should be able to see that this policy will rename the Built-in Administrator account to “locadm”. The password that we have set on this account is however encrypted within the “cpassword” attribute.
Why using Group Policy Preferences is a bad idea
So far there does not seem to be too much wrong with the use of Group Policy Preferences. They are easy to configure/deploy and any password contained within a policy is encrypted within the Group Policy Preference XML configuration file, so what is the problem?
When a Group Policy Preference is deployed on a Domain Member, in this example on a Windows 7 client, a sub-directory is automatically added within “C:\Users\All Users\Microsoft\Group Policy\History”, which contains the Group Policy Preference XML configuration file. The full path to the history configuration file that I detailed earlier, the one that will rename the Built-in Administrator account and change its password, is shown below as an example:
- C:\Users\All Users\Microsoft\Group Policy\History\{A1C0C41B-D2F8-401B-A5D1-437DA197A809}\Machine\Preferences\Groups\Groups.xml
The history file is readable by any authenticated user, as shown below:
The same Group Policy Preference XML configuration file is also accessible via the following UNC path on the Domain Controller, again by any authenticated user:
- \\Domain_Controller\sysvol\Domain_Name\Policies\{A1C0C41B-D2F8-401B-A5D1-437DA197A809}\Machine\Preferences\Groups\Groups.xml
The problem is that although the password is encrypted within the Group Policy Preference XML configuration file, using 256-bit AES encryption, the 32-byte AES key is openly document by Microsoft. As a result, any authenticated user with access to the Group Policy Preference XML configuration file can easily decrypt the password stored within the “cpassword” attribute, using tools that are freely available on the Internet.
A user that decrypts the password stored within the “cpassword” attribute of my example Group Policy Preference XML configuration, would then have the username and password of the renamed Built-in Administrator account “locadm”, enabling then to log into their computer as this user. They would also be able to connect to other systems within the network where the credentials have been reused.
In the event of a domain administrator account being used within a Group Policy Preference policy, the user would be able to compromise the security of the entire domain.
Can unauthenticated users obtain access to this information?
Yes. Any user on the network that is able to monitor the network traffic between a Domain Controller and a system on which a Group Policy Preference is being deployed would be able to view the XML configuration file as plain text, as it is traverses the network unencrypted via the Server Message Block (SMB) protocol. The following screenshot shows an example of a captured SMB2 packet using wireshark, which contains the Group Policy Preference XML configuration file:
Proof of concept: Decrypting the password
To decrypt the password stored within the ‘cpassword’ attribute of a Group Policy Preference XML configuration file, I make use of the Ruby script published on the carnal0wnage web site.
The following screenshot shows the Ruby script that I have updated to include the encrypted password from the “cpassword” attribute of my example Group Policy Preference XML configuration file (line 5 contains the encrypted password I want to decrypt):
Now lets decrypt the password…
Can the History files be easily removed from Domain Members?
Yes. History files for individual Group Policy Preferences are automatically removed from Domain Members once they perform a Group Policy update (i.e. “gpupdate”), but only after “link enabled” is unchecked against the specific policy within Group Policy Management on the Domain Controller. It is imperative to unlink the policy and not simply delete it, as deleting the policy will not result in the corresponding History files being deleted on Domain Members. Instead, they will remain present until manually deleted.
However, it should not be considered sufficient to only delete the History files from Domain Members and then disable the policies on the Domain Controller and think all is well. Instead it should be assumed that any credentials used within deployed Group Policy Preferences have been compromised and therefore the password to each account should be updated.
The screenshot below shows the ‘link enabled’ option being unchecked:
To Summarise
Lets quickly recap why Group Policy Preferences should not be used when there is a requirement for the policy to contain a user credentials:
- Any authenticated user within the domain can trivially obtain access to the Group Policy Preference XML configuration files either locally on their computer, or via the sysvol folder on the Domain Controller. They can then decrypt any password contained within the “cpassword” attribute of a Group Policy Preference XML configuration file and escalate their level of privilege and obtain an unauthorised level of access to any resource within the network on which the credentials are accepted
- Any unauthenticated user on the network (e.g. an unauthorised user who connects a laptop to the network) that is able to sniff network traffic would be able to capture Server Message Block packets that contain the Group Policy Preference XML configuration file. They could then decrypt the password contained within the “cpassword” attribute, enabling them to obtain unauthorised access to any resource on which the credentials are accepted
So, do you still want to utilise Group Policy Preferences to deploy configurations within your domain?….