Ways to Implement Safe Scripting

Although Software Restriction Policies offer a promising way to control what runs on your users' computers, it's only available on XP and 2003, and does require some pretty significant planning before you can roll it out. Are there any alternatives to safely scripting? Absolutely.

The Filename Extension Game

One of the easiest ways is to configure your users' computers to no longer associate VBS, SCR, WSF, and other filename extensions with the WScript.exe executable. Removing these file associations prevents users from double-clicking any script files and having them automatically run. To keep your own scripts running, simply associate a new filename extension-such as CORPSCRIPT-with WScript.exe. Name trusted scripts appropriately, and they'll run. It's unlikely a hacker can guess your private filename extension, making this a simple, reasonably effective means of establishing a safer scripting environment.

Script Signing

As I described earlier in this chapter, signing your scripts is a simple and effective way to guarantee their identity. By globally setting the WSH trust policy, you can prevent your computers from running untrusted scripts. There doesn't have to be much expense associated with this technique: You can establish your own Certification Authority (CA) root, use Group Policy to configure all client computers to trust that root, and then use the root to issue yourself a code-signing certificate.

Antivirus Software

Most modern antivirus software watches for script launches and displays some kind of warning message. I don't consider this an effective means of protecting your enterprise from unauthorized scripts; it's difficult to communicate to your users which scripts are "good" and which are "bad," putting them into just as much trouble as before the antivirus solution stepped in to help. However, such software can provide an easy-to-deploy means of protecting against scripts, especially if you aren't planning to use your own scripts on users' machines (as in logon scripts).

Defunct Techniques

Some popular techniques have been used in the past to control scripting that I want to discuss very briefly. I don't consider these methods reliable, secure, or desirable.

• Removing WScript.exe and Cscript.exe. Under Windows 2000 and later, these two files are under Windows File Protection and are not easily removed to begin with. Plus, doing so completely disables scripting, which probably isn't a goal if you're reading this book.

• Disassociating the VBS, WSF, and other filename extensions. Scripts can still be executed by running Wscript.exe scriptname, because that doesn't require a filename extension. In other words, it doesn't require much effort for hackers to e-mail shortcuts that do precisely that, thus defeating this technique as a safety measure.

• Renaming WScript.exe to something else. This is ineffective. Although it prevents the existing file extensions (VBS, etc.) from launching WScript.exe, it doesn't necessarily prevent scripts from running. Additionally, because WScript.exe is under Windows File Protection on Windows 2000 and later, the file may eventually wind up being replaced under your nose.