07.23.10
Posted in General Stuff, Group Policy Preferences, Security-related at 10:24 pm by Administrator
Microsoft recently announced a new security vulnerability in Windows shortcuts that affects all versions of Windows since XP! Its references here: http://support.microsoft.com/kb/2286198. This particular vulnerability takes advantage of the icon that appears in shortcut (.lnk and .pif) files on Windows. Within the article cited above, Microsoft provides a “FixIt” workaround for the problem that essentially removes the icon from the shortcut, leaving a blank icon in its place. In looking at what they are doing in the FixIt, it struck me that you could leverage GP Preferences’ registry extension to blow this fix out to your entire environment pretty quickly. So, what I did was create two new GP Preferences registry items, that update the appropriate registry values, and remove the data from those values. The values in question are:
HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler\@
HKEY_CLASSES_ROOT\piffile\shellex\IconHandler\@
Where @ represents the “Default” registry value. Each of these values needs to have no data in them in order for this fix to work (and you’ll need to restart the target machine).
The GP Preferences items were very easy to craft. The following screenshot shows an example of the one I did for the lnk files:
Note that the value data field is left blank. That, in combination with using the “Update” action on the GP Preferences item, makes it easy to blank out a registry value. I then repeated this same process for the piffile path in the registry. Since I created this policy under “Computer Configuration”, I targeted the GPO to my computer objects in AD by linking it to an OU containing my computers. During the next policy refresh, the fix applied and I was protected. When an update is provided by Microsoft, you can again use GP Preferences registry extension to update the registry value with its previous, default value, which is “{00021401-0000-0000-C000-000000000046}” for both lnkfile and piffile.
Cool! GP Preferences strikes again!
Darren
Permalink
07.22.10
Posted in General Stuff, Microsoft-Related, Security Policy, Security-related at 10:02 pm by Administrator
Some of you may have seen a twitter post I did a while back letting folks know about the Security Compliance Manager, which is a tool from Microsoft that lets you manage, edit, report, search and export security templates and baselines. This tool is pretty cool, but it also has a hidden gem in it. When you install the SCM, you will notice a folder within its program group called “LocalGPO”, which contains a package called localgpo.msi. When you run that MSI it installs some files within a folder on your hard drive, and one of those files is a script called localgpo.wsf. What this script can do is pretty cool. It can do 3 things against your local GPO that I really like:
- It can backup your local GPO to a GPMC formatted backup. Which means you could backup a local GPO and then use GPMC to import it into a domain-based GPO.
- It can take a GPMC backup of GP settings and import them into a local GPO on a machine.
- It can restore a local GPO to its default state.
These are three great features for managing the local GPO. Let’s take a look at how to use each. For backing up the local GPO, the syntax is simple:
From a command shell, I simply type:
cscript LocalGPO.wsf /path:c:\gpbackups /export
Where c:\gpbackups is a path to where I want to store my backup and /export tells the script to export my local GPO settings.
Now if I want to import a GPMC backup into my local GPO, the syntax is even easier. I simply provide the path to the GUID-Named folder that GPMC creates under the backup directory when you back up a GPO, like this:
cscript LocalGPO.wsf /path:C:\gpbackups\{42ADD8FE-EDF6-479B-92C6-557343D8D091}
And, to restore a local GPO to its default config:
cscript LocalGPO.wsf /restore
Pretty easy to use and this script seems to support every OS from XP to Win7. A couple of caveats however. In looking at the script, Microsoft is only supporting Administrative Templates and Security Policy within these backup and restore operations (understandable given the ship vehicle for this thing). So if you have other policies like Scripts or IE Maintenance within your local GPO, it won’t be captured. Also, the script does not appear to deal with the multiple local GPOs feature supported in Win Vista and above. So if you have per-user local GPOs, they are not captured–only the default local GPO.
That being said the script does provide some good basic functionality as well as a good instructional document on how to capture and reset security settings from the local GPO (which are essentially stored in the local SAM rather than on the file system as in domain-based GPOs).
Hope this proves useful to you!
Darren
Permalink
06.22.10
Posted in Group Policy Preferences, Security-related at 10:47 pm by Administrator
Well, I’ve been crazy busy working on some new product releases but I wanted to take a moment to blog about some useful features in GP Preferences that often slip through the cracks. I saw a blog post today about how you could use a custom ADM file to remove administrative shares on Windows systems. This works pretty well, but I always prefer it when Group Policy makes it really easy for me to manage configuration, and GP Preferences does that time and again. With respect to shares, you may want to prevent users from publishing shares on their workstations, or you may just want to get rid of the administrative shares for security reasons. In either case, you’ll find that the Network Shares GPP feature can fill the bill. If you navigate to Computer Configuration\Preferences\Windows Settings\Network Shares, you’ll find this hidden gem. Right-click the Network Shares node to create a new share policy. The key to accessing the share removal feature is to choose the Delete action on the network share policy item you create, as shown below:
Note that within the policy, you can choose to remove all regular shares (i.e. those that the user creates), all hidden, non administrative shares (i.e. shares created by the user using the $ hidden marker) and admin shares (e.g. c$, admin$, etc.)
Obviously, you’ll want to use this feature carefully, especially when removing built-in administrative shares that are often used by remote management tools. But, the ability to remove user shares is especially useful in preventing your users from creating a peer-to-peer file sharing network under your nose, with little or no access controls!
Enjoy!
Darren
Permalink
07.16.09
Posted in Security-related at 9:35 am by Administrator
Recently, Microsoft announced a zero-day vulnerability in IE’s ActiveX video control, that required folks to react quickly to prevent exploits of this vulnerability. One of the possible routes for preventing this was to disable the affected ActiveX control in IE using so-called "Killbits" in the registry. This technique is described in general within a Microsoft KB article and specifically for this vulnerability within this document. Essentially, Killbits are a set of registry entries that must be enabled on a per-computer basis (i.e. within HKEY_LOCAL_MACHINE in the registry) that sets a flag on the GUIDs related to the given ActiveX Control. In the case of the recent video control vulnerability, there were something like 45 GUIDs requiring registry updates.
Someone asked me yesterday if Group Policy might not be a good way to push out these kinds of Killbits changes. And, not surprisingly, my answer was a solid, "YES!". Centralized registry change control, is, after all, the bread and butter of Group Policy for many enterprises. In this case, there are really two ways to skin this using Group Policy. The most obvious way is to create a custom ADM file (or ADMX for Vista/2008 environments) that hard codes the registry values in question. You can then add that ADM to a GPO in your AD environment and use it to target computer objects in AD for delivery of the Killbits values. Of course, the downside to that approach is that for any new ActiveX vulnerability that comes along, you have to create a new/modified ADM file with the new GUIDs.
Probably the easier way to handle this is to leverage our good friend, the Group Policy Preferences (GPP) feature that Microsoft introduced with Server 2008. Remember that you don’t need to have Server 2008 running in your environment to use GPP, but just need to have deployed the GPP Client Side Extensions (CSEs) to your XP, Vista and 2003 systems, and then you just need one Vista, SP1 or Server 2008 machine with GPMC installed to create and manage GPP settings. GPP includes a Registry extension (under either Computer or User Configuration\Preferences\Windows Settings\Registry) that lets you deploy "free-form" registry settings. One of the cool features of this Registry extension is the "Registry Wizard". The Wizard is designed to let you pick a bunch of existing registry values from the registry on a local or remote machine, and those are captured into policy without you having to manually enter anything! So, for example, you could apply the KillBits "Fix-it" package that Microsoft typically provides, to a test machine, and then use the Registry Wizard to capture those into a GPO, and push them out to all of your desktop machines. The following screen-shot shows an example of how this works with GPP and the Registry Wizard:
When you use the registry wizard in GPP to capture these registry entries, they are defined with a GPP Action type of "Update". This means that if these registry values exist already, they will be modified to conform to the KillBits value you specify. If they don’t exist, they will be created.
GPP provides a great mechanism for managing ActiveX Killbits settings, because they are centrally visible and manageable within the GP UI and you can use Group Policy’s built-in targeting mechanisms and even the more granular GPP Item-Level Targeting, to make sure all of the machines on your network receive the settings.
And of course, if you need to be able to automate reading or writing of these GPP Killbits registry settings, you can do that very easily with our GPExpert(r) Group Policy Automation Engine and Powershell!
Tags
Group Policy, ActiveX Killbits
Permalink
