Windows Tip Sheet

Lock Down Those Scripts!

Take care of this task throughout the company via this Active Directory trick.

• By Don Jones
• 06/30/2004

"Lock down your scripting environment" is a big refrain with me. Anyone who's attending my scripting classes has heard me say it, and certainly anyone who reads anything I've written has seen it. Recently, though, I got a huge pile of e-mail telling me that it's just too darn difficult to run around to every machine in the company installing the registry hacks necessary to properly lock down the Windows Script Host. Yeah, you're right. Fortunately, there's Active Directory, which is more than willing to do it for you.

First, some background: The current version of WSH (that'd be 5.6, available from www.microsoft.com/scripting) obeys a cool registry key. Normally, WSH doesn't care if your scripts are digitally signed or not, because this key is set to zero. However, setting it to 1 or 2 makes WSH care: When WSH sees a script that hasn't been signed (and the signing certificate must have been issued by a certification authority that the local machine trusts), WSH either notifies the user and asks what to do (registry key set to 1) or refuses to run the script (set to 2). Asking the user is almost always the wrong answer, of course, because we all know they'll just say "run it anyway," so I prefer the second option.

As I mentioned, this all takes place in a registry key. Well, actually a couple of registry keys. On Windows 2000, just one key is involved: HKCU\Software\Microsoft\Windows Script Host\TrustPolicy, which is a REG_DWORD value. On Windows XP and Windows 2003, though, things are more complicated. Under HKLM\Software\Microsoft\Windows Script Host\ you'll find a value named UseWINSAFER, which is set to 1 by default. This forces WSH to obey Software Restriction Policy settings instead of the TrustPolicy key. Since nobody sets up Software Restriction Policies, setting TrustPolicy to 1 or 2 has no effect until you set the UseWINSAFER value to 0. There's another value on the HKLM side which tells WSH to ignore the HKCU settings and instead obey HKLM\Software\Microsoft\Windows Script Host\TrustPolicy.

And so on. It's definitely too painful to think about modifying all your client and server computers but, as I said, "Active Directory to the rescue!" I've made an ADM template, which you can import into a Group Policy object and use to push your preferred WSH security settings out to the world. You can download it from www.scriptinganswers.com/download/adm.zip. You'll need to modify the GPO editor's Filter options (from the View menu) to display more than just "managed policies," because these WSH policies aren't managed (they're referred to as preferences, not policies, and they remain permanent even if you un-assign the GPO). The template will let you assign all of the necessary registry keys, and a couple of other related ones, besides.

With the right WSH TrustPolicy setting in place, scripts will only run if they're signed. To get your scripts to run, simply sign them using a digital certificate that's trusted by local computers. This might be a certificate issued by a commercial CA like VeriSign or Thawte, or one issued from your internal corporate CA. Until virus authors begin signing their scripts—thus providing an identity trail back to them—your scripting environment will be safe and snug.

Micro Tip Sheet Think you can lock down scripting by just deleting WScript.exe and CScript.exe? Be careful: Those files are under Windows File Protection (Win2K and newer) and can be copied back by the operating system during the next automatic file protection scan. So maybe you can lock down scripting by disassociating "VBS," "JS," "WSH," and other filename extensions from WScript.exe and CScript.exe? That's a false sense of security: All an attacker has to do is execute "WScript.exe Anyfile.xxx" and the script (contained in "Anyfile.xxx") will happily execute. Looking for a way to digitally sign scripts? Microsoft suggests writing a script to do it, which is kind of cool. You can also use PrimalScript (www.sapien.com), which has a built-in script-signing tool. In fact, the latest version can be configured to automatically sign scripts with a designated certificate every time you hit "Save," making script signing completely transparent.

More Resources
Microsoft Scripting Technologies: http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001169

Windows Script Host documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsoriWindowsScriptHost.asp

My Windows scripting Web site: www.scriptinganswers.com