Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS
In a parallel universe, where our normal rules of logic do not apply, security is enhanced by publishing exploits for unpatched vulnerabilities. Straight from that universe, we received a gift from H.D. Moore today - a brand new MetaSploit toolkit for an unpatched vulnerability in an ActiveX control that ships with the Windows Shell. The control is called the WebViewFolderIcon and is among other things used for rendering the Web View in Windows Explorer. It can also be called from inside Internet Explorer, and can therefore be exploited if a user allows ActiveX controls to run from a hostile site. Sandi says IE 7 is also vulnerable.
While I have yet to hear of exploits in the wild, and the actual vulnerability has been public for a couple of months already, the presence of a toolkit lowers the bar for large-scale exploitation to next to nothing. Microsoft released an advisory today, and most of the other outlets have too. The advisory contains several work-arounds, the most easily implemented of which is the advice to set the kill bit on the control.
As with the other recent web-based security issues, setting the killbit on a large number of systems is not simple though. Microsoft does mention in the advisory that it can be done with Group Policy, but leaves it up to the community to determine how exactly to do that. After discussing the risk a bit with my good friend Alun, we decided it was time to do something.
To solve this problem more generically I went ahead and wrote a script that can be used either on the command line, as a startup script, or be called from an Enterprise Management System (EMS), such as Microsoft's Systems Management Server (SMS). The script takes three arguments:
SlayOCX.vbs -k|-r GUID [-l]
where:
-k - Turn on the killbit of the control
-r - Turn off (revive) the killbit of the control
GUID - The GUID of the control, complete with the opening and closing {}
-l - Log the action to %systemdrive%\SlayOCX.log
The -l parameter is optional, the others are required. The reason the script requires the GUID is that it makes it more generic, allowing it to be applied to any ActiveX control you wish to killbit, or enable again. The script is attached to this post.
To set the kill bit on the first of the WebViewFolderIcon control, you would run the following command:
SlayOCX.vbs -k e5df9d10-3b52-11d1-83e8-00a0c90dc849 -l
To turn the control back on again, run this command:
SlayOCX.vbs -r e5df9d10-3b52-11d1-83e8-00a0c90dc849 -l
There are two controls that implement the vulnerable function. To kill/revive the second one, substitute 844F4806-E8A8-11d2-9652-00C04FC30871 for the GUID above and run the script again. You can only kill/revive one control each time the script executes.
You can configure this script to run as a logon script in Group Policy using the following steps, copied and pasted from the post about the DAXCTL and VML vulnerabilities:
Copy the script above (everything between the begin and end tags) and paste it into a new text document. Save the document as "ProtectIE.cmd". Alternatively, just download and expand the SlayOCX_vx.zip file attached to this post.
Copy the ProtectIE.cmd file to \\<your domain>\sysvol\<your domain>\scripts. where you replace "<your domain>" with the full DNS name of your domain.
- Open the GPMC (if you do not have the Group Policy Management Console, you need to get it. Strictly speaking you can manage GPOs without it, but you really don't want to)
Right-click the domain or OU where you want to link the GPO - you may as well do it at the domain level - and select "Create and Link a GPO Here..." Name your new GPO "SlayOCX"
Right-click the GPO ProtectIE and select "Edit..."
Expand "Computer Configuration:Windows Settings" and click on "Scripts (Startup/Shutdown).
- Double-click "Startup" in the right-hand pane
- Click "Add..."
- Browse to \\<your domain>\sysvol\<your domain>\scripts and select "SlayOCX". Click "Open"
- In the "Script Parameters:" box type "-k e5df9d10-3b52-11d1-83e8-00a0c90dc849 -l" without the quotes. Click "OK."
- Repeat steps 8-10, but this time, type "-k 844F4806-E8A8-11d2-9652-00C04FC30871 -l" in the parameters box.
- Click "OK" again.
Close the GPO editor and go back to the GPMC
In the "Security Filtering" pane remove "Authenticated Users" and click Add...
In the text box called "Enter the object name..." type "Domain Computers" or some other relevant group that you want to apply the policy to. Click OK.
The script should be run as a startup script, not as a logon script. Unregistering an ActiveX control is an administrative action, and as users should not be administrators, the script will not work properly as a logon script. Needless to say, this also means you have to restart the computer for the script to take effect if you run it from a GPO.
If you also want to use this script to block the, still unpatched, DAXCTL vulnerability, repeat steps 8 through 10 above, but type the following parameters in step 10:
-k D7A7D7C3-D47F-11D0-89D3-00A0C90833E6 -l
I should also mention that, while I am blissfully unaware of any adverse effects associated with killbitting this control at this time, that does not mean there are none.
Update Sept. 29
- There are two controls containing the WebViewFolderIcon issue. Added the GUID for the second one.