Newsletters #9

Since the I-Love-You-Virus has infected many systems, there is a discussion about script security. Many administrators advocating to remove WSH or disable it at least. Below I like to give a few tips how to use WSH on your systems without lowering system security (because BAT- and EXE-files are also dangerous, and in Linux nobody tries to remove script engines, instead administrators use buid-in features to prevent unauthorized use). So let's talk about the details.

(c) Günter Born, http://www.borncity.de

Warning: The material submitted as a newsletter comes AS-IS without any warranty of any kind. In no event shall the author be liable for damages and losses of any kind. The material discussed herein is copyrighted by the author. You get a free right to use it. This newsletter may be distribute freely as long as: a) the text remains intact and unmodified, b) a reference to the WSH Bazaar www.borncity.de is given and c) the newsletter is not shipped with other commercial material. If you like to ship the newsletter with CD-ROMs etc. please ask. Permission will be granted in normal cases, but I like to know where my material goes into.

Prevent automatic WSH script execution

Windows default settings for Windows Script Host allows execution of a WSH script file. This means the Open command is set to activate the script upon a double-click on the script’s file. One other successful strategy to prevent infecting your systems by accident with WSH script viruses may be to disable the default Open command. What I propose is to change the Open action in a way that the command loads the source code into the Windows editor instead of executing the script using WSH. (If the user accidentally chooses Open to view the attachment in an e-mail reader or in Internet Explorer after clicking a download entry, a script virus doesn’t get executed. Instead the source code is getting loaded in Notepad.)

NOTE: Again, this strategy helps to block unintended execution of e-mail attachments containing WSH script viruses. But if a user is pertinent (stupid) enough, he/she still has the possibility to save such an attachment and try to launch it manually. But in my opinion the following solution reduce the risk of accidential infections a lot.

This "redirection" can be done by changing the registry settings for the file type associations .vbs, .js and .wsf. These associations are kept in the Registry branch HKCR in the keys VBSFile, JSFile and WSFFile (Note, in WSH 1 we haven’t the WSFFile sub-key). The following content of a .Reg-file will do the necessary changes for the .vbs file type (sub-key VBSFile) in Windows 9x:

REGEDIT4
[HKEY_CLASSES_ROOT\VBSFile\Shell\Open\Command]
@="notepad.exe \"%1\""
[HKEY_CLASSES_ROOT\VBSFile\Shell\Open2\Command]
@="notepad.exe \"%1\""
[HKEY_CLASSES_ROOT\VBSFile\Shell\Execute]
@="&Execute"
[HKEY_CLASSES_ROOT\VBSFile\Shell\Execute\Command]
@="c:\\windows\\WScript.exe \"%1\" %*"
[HKEY_CLASSES_ROOT\VBSFile\Shell\ExecuteDOS\Command]
@="c:\\windows\\COMMAND\\CScript.exe \"%1\" %*"

After importing the Reg file (double-click the Reg file and answer the dialog asking to import the file with Yes), the Open command is changed. Double-clicking a VBScript file afterward opens it in Notepad. To execute the VBScript file, right click the file and select Execute in the context menu. The context menu entry ExecuteDOS executes the script using Cscript.exe.

For .js files you can use a similar Reg file. The association is made in the sub-key JSFile. Use the same code as shown above, but exchange the VBSFile pattern to JSFile and save the result into a second REG file. The same may be applied for .wsf files. That file type uses the key WSFFile in the registry, so the pattern VBSFile have to be changed to WSFFile.

NOTE: There are also encoded versions of script files using the file extensions .vbe and .jse. You can use also Reg files to block the associations for those files.

To restore the old settings, you can use also a REG file. The following code obtained from a REG file restores the default settings for .vbs and removes the Execute and ExecuteDOS verbs from the VBSFile sub-key.

REGEDIT4
[HKEY_CLASSES_ROOT\VBSFile\Shell\Open\Command]
@="c:\\windows\\WScript.exe \"%1\" %*"
[HKEY_CLASSES_ROOT\VBSFile\Shell\Open2\Command]
@="c:\\windows\\COMMAND\\CScript.exe \"%1\" %*"
[-HKEY_CLASSES_ROOT\VBSFile\Shell\Execute]
[-HKEY_CLASSES_ROOT\VBSFile\Shell\ExecuteDOS]

You can create similar Reg files for .vbe, .js, .jse, and .wsf files to be able to reset the default WSH settings.

NOTE: Take care that Windows 2000 uses slight different folders to locate the WSH executable. The files may be found in the system folder \System32. So you need to customize also the Reg files in that way. As an alternative you can write a script program that detects the Windows version and the WSH version and alters the necessary Registry settings. If such a script is part of a logon procedure, users are protected against their self. Further details about registering file types may be obtained from my Microsoft Press title "Inside the Microsoft Windows 98 Registry". The information about registering file types is valid for all 32 Bit Windows versions.

TIP: If in doubt about using the Reg files mentioned above (and if you like to experiment a bit before you change your system settings), use the Folder Options command in a folder window (either in the View or Tools menu). Use the File Types property page. After selecting an entry like "VBScript Encoded Script File" or "VBScript Script File", you can view the settings using the button Edit (or Advanced in Windows 2000). The Edit File Type dialog shows all defined verbs useable for the file type. Change the settings for the Open and Open2 command manually and add the old settings for Open and Open2 as Execute and ExecuteDOS.

Security settings for WSH scripts (Win NT and Win 2000)

Infecting a system with script viruses is a consequence of lazy user behavior (or let’s say it a bit more drastic: user ignorance). If users don’t open e-mail attachments (and if mail-programs are setup in a way that attachments are not opened by default, even in preview mode), a virus can’t be spread. Unfortunately there are enough un-experienced users that are willing to open each attachment to any e-mail. And most Windows systems are handled in a way that all security issues are switched off. This remembers me always about Linux users running their system always with root user rights.

As a system administrator you can prevent scripts to be executed without removing Windows Script Host! And you can specify that this behavior is valid only for certain users or for the whole system. This option is available in all 32 Bit Windows versions, but it need to be activated – and the way to block WSH script to be executed differs a bit between operating systems. Let’s have a closer look at some strategies.

In Windows 2000 (and also in Windows NT 4) for instance, you can limit the right to execute a file to defined user groups. So why not block the WSH exe files from being executed from ordinary users? Here we go:

  1. Logon as an administrator, search for the files Cscript.exe and WScript.exe (located in the \System32 folder).
  2. Right-click each of these files, and select Properties in the context menu.
  3. Then select the Security property page, click Everyone and uncheck "Read & Execute" in the Allow column.

Proceed this step for all other user groups the WSH should be disabled (only System and Administrators may have the rights to execute a script).

After closing the Security page, execution of WSH scripts should be blocked for the requested user groups. If you need to execute scripts, logon as an Administrator and execute the files. For online sessions avoid to logon with Administrator rights.

© by G. Born

Disclaimer

The text was obtained from my manuscript "Microsoft Windows Script Host Programmer’s Guide", Microsoft Press. Details about Registry keys for file types may be obtained from my Microsoft Press title "Inside the Microsoft Windows 98 Registry". In no event shall the author be liable for any damages resulting from the use of the information given in this text. Use it at your own risk. Further information about WSH may be found in the WSH Bazaar at: www.borncity.de.

Planned topics for newsletter #10 and future newsletters:

Enyoy scripting, till the next newsletter arrives...


(c) G. Born, 24 - October 2000 - www.borncity.de