Get a glimpse inside Don Jones' book "Managing Windows with VBScript and WMI" with this series of book excerpts. Below is an excerpt from Chapter 28, "Scripting Security." Click for the complete book excerpt series or purchase the book.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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.
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).
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.
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.exescriptname, 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.
WScript.exeto 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.exeis under Windows File Protection on Windows 2000 and later, the file may eventually wind up being replaced under your nose.
Click here to go back to the beginning.
Click for book details or purchase the book.