Using Group Policy Preferences for Password Management = Bad Idea OR “How to Get Your Network Owned in Several Simple Steps”
One of my customers recently needed to change the local administrator password on several hundred Windows 7 workstations and was trying to determine the best method: PowerShell script or Group Policy Preferences.
The easy answer is to use Group Policy Preferences since it has a built-in mechanism for changing/managing local computer passwords. The problem is that while the password in Group Policy Preferences is encrypted using AES 256, the private key for the encryption is posted on MSDN. This means that Group Policy Preferences is vulnerable to password exposure.
Since the private key for this data is well known, using Group Policy Preferences to manage local computer passwords means these passwords are vulnerable to discovery. Since the Group Policy Preference data is stored in an XML file in SYSVOL (such as drives.xml, groups.xml, printers.xml, etc), all authenticated users in the domain has read access (they have to in order to apply Group Policy). This means that any authenticated user can open the Group Policy Preference XML file with the encrypted password and decrypt it using the AES key posted on MSDN. This AES key is part of every Windows computer that is Group Policy Preferences capable (native support in Windows 7 and newer; Windows Vista with an install; and Windows XP SP 2 & Windows 2003 SP1 with a patch, KB943729) in order for the computers to decrypt the password and use it. If the Group Policy Preference requires a password to be entered, it is stored in an XML file in SYSVOL. Despite the fact that the password is AES 256-bit encrypted (and base 64 encoded with padding if necessary), it is not secure. Microsoft does not recommend storing passwords in Group Policy Preferences (blog post linked below) and Windows Server 2012 displays a message with a similar warning.
Windows Server 2012 Group Policy Preference password Warning:
More information on how Group Policy Preferences are attacked is in the post “Finding Passwords in SYSVOL & Exploiting Group Policy Preferences“.
Here’s a sample groups.xml file from SYSVOL representing a Group Policy using Group Policy Preferences to add a new user to computers in the linked OU.
<?xml version=”1.0″ encoding=”utf-8″?>
<Groups clsid=”{3125E937-EB16-4b4c-9934-544FC6D24D26}”>
<User clsid=”{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}” name=”LocalTestUser” image=”0″ changed=”2013-07-04 00:07:13″ uid=”{47F24835-4B58-4C48-A749-5747EAC84669}”>
<Properties action=”C” fullName=”” description=”” cpassword=”sFWOJZOU7bJICaqvmd+KAEN0o4RcpxxMLWnK7s7zgNR+JiJwoSa+DLU3kAIdXc1WW5NKrIjIe9MIdBuJHvqFgbcNS873bDK2nbQBqpydkjbsPXV0HRPpQ96phie6N9tn4NF3KYyswokkDnj8gvuyZBXqoG94ML8M1Iq7/jhe37eHJiZGyi5IBoPuCfKpurj2″ changeLogon=”0″ noChange=”0″ neverExpires=”0″ acctDisabled=”0″ userName=”LocalTestUser”/>
</User>
</Groups>
cpassword above represents the encrypted password and I was able to browse to and save this file from SYSVOL with a regular domain user account. All that is left to do is to perform a Base64 unencode, then decrypt using the MSDN AES key.
Here’s the 32-byte AES key used to encrypt ALL Group Policy Preferences passwords in any domain:
4e 99 06 e8 fc b6 6c c9 fa f4 93 10 62 0f fe e8 f4 96 e8 06 cc 05 79 90 20 9b 09 a4 33 b6 6c 1b
The problem is that since the AES encryption (and decryption) key is known (and posted publicly on MSDN and here), Group Policy Preferences can’t be considered a secure method for changing passwords.
The Microsoft Group Policy Blog posted about the potential issues in 2009:
Are passwords in preference items secure?
A password in a preference item is stored in SYSVOL in the GPO containing that preference item. To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.Because passwords in preference items are not secured, we recommend that you carefully consider the security ramifications when deciding whether to store passwords in preference items. If you choose to use this feature, we recommend that you consider creating dedicated accounts for use with it and that you do not store administrative passwords in preference items.
Where can you use passwords?
You can use passwords in the following types of preference items:
- Local User preference items: When you create or modify a local user account, you can specify both a user name and a password for the account.
- Data Source preference items: If a user name and password are required to access the data source, you can provide them in the preference item. If you do so, end users to whom the preference item applies can access the data source regardless of their own permissions, but only if the specified account has the necessary permissions.
- Mapped Drive preference items: You can specify the user name and password to be used to connect to a mapped drive. If you do so, end users to whom the preference item applies can access the mapped drive regardless of their own permissions, but only if the specified account has the necessary permissions.
- Scheduled Task or Immediate Task preference items: You can configure a scheduled task to run under the security context of a specified user (allowing the task to run regardless of whether that user is logged on), by selecting the “Run as” check box and providing a user name and password.
- Service preference items: You can modify which account the service runs under by selecting “Local System account” or by selecting “This account” and specifying a user name and password.
If this HAS to be done and you accept the risk, you can set the group policy for a few days and then delete it. However, there is a chance that someone already copied the XML file containing the password and already knows it. Using SCCM or a scripted solution may be the best answer for now, unless you want to pay for a product from CyberArk or Quest (note that these products are mentioned for informational purposes only).
Here’s a PowerShell script I wrote that reports on what credentials are stored in Group Policies. PowerShell Script: Discover Group Policy Passwords (updated 10/2014). Note that it requires the Active Directory PowerShell cmdlets.
Attack Vectors:
- MetaSploit has a module for gathering passwords from Group Policy Preferences.
- There’s also a PowerShell script that can identify and extract the password(s) stored in Group Policy Preferences using the MSDN AES key.
Here’s the original post with the PowerShell script that is now hosted and updated on GitHub’s PowerSploit section. - Details on how simple the process actually is: Exploit credentials stored in Windows Group Policy Preferences
There is code on MSDN for managing local admin passwords for computers by storing the password in a confidential Active Directory attribute on each computer object. Note that this solution is not supported by Microsoft.
Summary
This sample is a fully working solution that implements automatic management of password of builtin Administrator account on computers joined to domain.
Solution currently available out of box on the platform (Group Policy Preferences) does not fulfill usual security requirements. Main problems with GPO Preferences are:
- Password is the same on many workstations
- Password stored in GPO and transported over network is not encrypted, but obfuscated (and obfuscation algorithm is published on MSDN), so it is not secure solution
Solution implemented by this sample does not have such weak points.
Recent Comments