Reading Time: 5 minutes

Last week, Microsoft released Security Bulletin MS04-025, including guidance and an update that resolves a publicly disclosed vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if Active Directory Group Policy preferences are used to distribute passwords across the domain – a practice that could allow an attacker to retrieve and decrypt the password stored in the cpassword value of Group Policy preferences.

The problem with cpasswords

Group Policy Preferences (GPPs) allow system administrators to set passwords using the following GPP extensions:

Local user and group
Mapped drives
Services
Scheduled tasks (Uplevel)
Scheduled tasks (Downlevel)
Immediate tasks (Uplevel)
Immediate tasks (Downlevel)
Data sources

An example would be a Group Policy Preference that sets the local administrator password for all domain-joined devices within the scope of the Group Policy Object (GPO). This scope can be configured with Organizational Units (OUs), but also through WMI Filters.

Now, when you’d set a password this way in the Group Policy Editor on Windows 8, Windows 8.1, Windows Server 2012 and Windows Server 2012 R2, the Group Policy Editor, already, warns you:

This warning message tells you that the password is stored. Authenticated Users can discover and access its value by simply browsing through the System Volume (SYSVOL). The password is not encrypted, but, as the warning suggests, merely obscured.

It’s true. Settings in GPPs are stored in XML files. Passwords in GPPs are stored in these XML files using the cpassword field. Below is the groups.xml file corresponding to a GPP with the extension used to create a new account with a non-expiring password for the Demo User:

Note:
Other XML files in the SYSVOL share of Domain Controllers, where you can find cpassword values are scheduledtasks.xml, services.xml and datasources.xml.

Of course, the password for the Demo User Account is configured as P@ssw0rd, as are all the passwords I tend to share with you on this blog… You can easily confirm it, by using the Get-GPPPassword PowerShell script that is part of PowerSploit.

Fixing your environment

Step 1, Determine the impact on your environment

By now, You might be wondering what the impact is on your Active Directory environment. Group Policy Preferences containing passwords may have been implemented before your time, before you had Windows Server 2012 (R2)-based Domain Controllers or other admins might just have been ignoring warning messages on this malpractice.

As part of KnowledgeBase Article 2962486, Microsoft has released a PowerShell script to detect Group Policy Preferences (GPPs) using GPP Extensions that rely on the cpassword.

I recommend running the Get-SettingsWithCPassword.ps1 PowerShell script with an account with sufficient privileges to access all Group Policy Objects on a domain-joined device.

Note:
When the device is a Windows client, make sure to have the Remote Server Administration Tools (RSAT) installed, since the script uses PowerShell Modules included with these tools.

Note:
The script does not support to be run from a device that is not joined to the Active Directory environment you are trying to scan.

The output of the script, when run successfully, is a list of GPPs containing cpasswords.

Step 2, Get rid of cpassword values

Now that you have determined the impact on your environment, you can remedy the situation (where needed):

Local users

For the Local User Management portion of GPPs that contain cpasswords, Microsoft has made the Invoke-PasswordRoll PowerShell script available to set the local account passwords on remote machines to random passwords.

Administrators can add local administrator accounts to computers by creating an Active Directory group and adding it to the local Administrators group through Group Policy Preferences -> Local Group. This method does not cache credentials in cpassword values.

Mapped drives

To map drives and assure only authorized access to the network location is allowed, protect the mapped drive using Active Directory objects to control permissions to the folder.

Services

In environments where the Services preference extension is used to change service properties in such a way that they run in a context, other than their original security context, admins can use (group) Managed Service Accounts (MSAs). This method does not cache credentials in cpassword values or in registry.

Scheduled tasks

When you encounter cpassword values in Group Policy Objects (GPOs) that specify running scheduled tasks in specific security contexts, the best practice is to select the Do not store password. The task will only have access to local resources. option.

Data sources

The Data Sources preference is used to associate a data source with a computer or user. Unfortunately, Microsoft does not have a workaround available to make these available in such a way in a secure manner.

Of course, when you repurpose old accounts, make sure you don’t use passwords that are equal to passwords found in obfuscated cpassword values, and, also, cannot be easily guessed based on old passwords. Someone might already have made a ‘backup’ of your SYSVOL…

When you reconfigure a Group Policy Preference (GPP) the corresponding XML files get overwritten. Any passwords stored in obfuscated cpassword values will be gone, after you click OK in the Properties of the GPP and close the Group Policy Object (GPO). SYSVOL replication will take care of replacing the XML files on all Domain Controllers in the domain.

Step 3, Neuter the User Interface

As part of MS14-025, Microsoft has released two security updates, as part of these KnowledgeBase articles:

Microsoft Knowledge Base Article 2928120 for systems with the security update from KnowledgeBase Article 2919355 installed.
Microsoft Knowledge Base Article 2961899 for systems without the security update from KnowledgeBase Article 2919355 installed.

When you install these updates on Windows client systems and Windows Server installations with the Remote Server Administration Tools (RSAT) installed or the Group Policy Management Tools (gpmc.msc) enabled, the User Interface for the Group Policy Editor (gpedit.msc) User Interface (UI) gets stripped from the management capabilities to create or edit cpassword values.

Note:
When you’ve already applied the security updates above and figured out you needed to perform step 2, you can always implement a system without the security update to granularly manage Group Policy Preference (GPP) settings.

Concluding

After years of guidance and warnings from Microsoft to not use passwords in Group Policy Preferences, MS14-025 finally triggers blocking the ability to configure them via the User Interface (UI). Be prepared.

a blog by Sander Berkouwer

Security Thoughts: Passwords in Group Policy Preferences (CVE-2014-1812)

The problem with cpasswords

Fixing your environment

Step 1, Determine the impact on your environment