make a good business better

Blog Information Security

Print Divider Print Divider Branding
 

Group Policy Security

10/15/2012  |  By: Stewart Fey, Director of Technical Services

Share

Social Logo Social Logo Social Logo Social Logo

As an Info Sec professional who does a number of penetration tests for some very secure companies, (think large government contractors), I am always researching the latest and greatest tools and techniques the “bad guys” and script kiddies are using to compromise computer systems. The other day I ran across an older and until recently not exploited “feature” in Microsoft. I have found that many of my clients are vulnerable to this internal attack and wanted to share it with you.

This technique which was recently re-highlighted and brought to more of a public awareness by a European security firm in early 2012 and exploits the way Group Policy stores and secures passwords. How Microsoft handles passwords in Group policy is very well published and to Microsoft’s credit they warn administrators as early as 2009 to consider the risks and not to use sensitive passwords within Group Policy files. But as we all know administrators do not have time to read and consider every bit of information Microsoft publishes about its products.

We would assume (shame on us) that it would be secured from the start.

The Issue

Within Group Policy there are several options such as starting a service, adding a user, and mapping a drive, that might require a specific user ID and password. These details can be entered as preferences within a Group Policy and sensitive data such as passwords are then encrypted and the entire policy is stored within an XML file in the SYSVOL folder of your domain controller.

Unfortunately, for the passwords to be decrypted the encryption key is stored generically on all Windows machines and well documented by Microsoft on its technical websites. Recently, several tools, including a Metasploit module have been published to make it very easy to instantly decrypt these passwords – no bruteforcing required! To make things worse, all domain users have access to read group policy files on the domain controller. So any authenticated ID has the ability to view and decrypt saved passwords within Group Policy files.

How can I see if my Group Policy files are vulnerable?

The simplest way to check is to browse using Windows Explorer to the SYSVOL share on your domain controller and search for XML files (*.xml) review these files for encrypted passwords (stored in the field cpassword=) and evaluate if any of these user ID/password combinations would grant access that your organization would not want all users to have. In my penetration tests most often these passwords are for local or domain administrator accounts.

The Fix

Since this is a well-known “feature” that Microsoft has been warning about for years, unfortunately, there is no fix. Your only option is to not use passwords in Group Policy preferences.