The file parameter accepts any WSH script name that has a .vbs, .js, or .wsf extension. The cert switch identifies the name of the certificate to use, which usually corresponds to the certificate holder's CN. Make sure that the selected certificate supports the code-signing feature. You can use the optional store switch to specify the certificate store to use. By default, the script selects the personal store (called My) of the user running the script.
To run SignScript.wsf with its required and optional parameters, type
C:\>SignScript.wsf
/file:"HelloWorld.wsf"
/cert:"LISSOIR Alain"
/Store:"My"
where HelloWorld.wsf is the script to which you want to add a digital signature, LISSOIR Alain is the certificate, and My is the certificate store. When the mandatory command-line arguments are present, SignScript.wsf digitally signs the script named in the command line (i.e., HelloWorld.wsf). To sign the script, SignScript.wsf uses WSH 5.6's new Scripting.Signer object. This object uses several methods and properties, which Web Table 1 (http://www.winscriptingsolutions.com, InstantDoc ID 25644) shows, to support various signing features. As callout D shows, the SignFile method uses three properties that match the script arguments defined in the XML <runtime> tags. When the script invokes the SignFile method, the Scripting.Signer object uses the appropriate syntax, based on the script-file extension, to store the signature in the script to be signed. Figure 3 shows the syntaxes for WS, VBScript, and JScript scripts.
Using a script isn't the only way to sign code. You can also use the Digital Signature Wizard (signcode.exe) provided with the Authenticode tools, which you can download from http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/000/219/msdncompositedoc.xml.
Enforcing WSH Security
You need to force WSH to check the validity of signatures added to scripts. By default, WSH doesn't check signatures and will run unsigned scripts or scripts with an invalid signature, so signing your scripts without enforcing a validity check is useless.
Different versions of Windows offer different mechanisms to enforce WSH security: Win2K and Windows NT users must modify registry subkeys to set WSH security. Windows .NET Server (Win.NET Server) and XP users can use Software Restriction Policies (formerly known as WinSafer).
Enforcing security under Win2K and NT. In Win2K and NT, WSH has a set of registry subkeys that you can modify to enforce WSH security on a per-user or per-machine basis. For user settings, you use the HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings registry subkey; for the machine settings, you use the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings registry subkey.
The data item you'll modify is called TrustPolicy. By default, its value is set to 0, which offers no digital signature checking. If you set the value to 2, your system will run only scripts with a valid digital signature. If you set the value to 1, when a user runs a script, WSH will display one of the following messages, depending on the state of the signature in the script:
- The started script doesn't contain any signature.
- The started script contains a signature but it has been tampered with.
- The started script has an expired signature.
- The started script contains a valid signature, but the certificate chain process terminated in a root certificate that isn't trusted.
The user can choose to terminate the script or override the prompt and run it.
Enforcing security under Win.NET Server and XP. You can use the same security mechanism with Win.NET Server and XP that you use for Win2K and NT. However, by default, Win.NET Server and XP use Software Restriction Policies, which you can set up by using the MMC Group Policy snap-in. To enable WSH to use Software Restriction Policies, use a registry editor to navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings\UseWinSAFER subkey and set its value to 1.
To use the TrustPolicy mechanism under Win.NET Server and XP, you first need to set the UseWinSAFER data item to 0. Note that under Win.NET Server and XP, the TrustPolicy data item isn't available by default; you must create it as a REG_DWORD data item under the same registry subkey. After you set the TrustPolicy value to 1 or 2, it behaves as it does in Win2K.
The default security level for Software Restriction Policies is Unrestricted. If you want to block execution of all unsigned scripts, you need to create four additional rules in Software Restriction Policies: three path rules to disallow execution of scripts that use extensions .vbs, .js, and .wsf, and one certificate rule to allow execution of signed scripts from a trusted source. The settings that Figure 4 shows will let only scripts signed by LISSOIR Alain run.
Putting It All Together
Microsoft's efforts to provide a simple and powerful infrastructure for creating administrative scripting solutions has also facilitated the creation and distribution of malicious code. With the release of WSH 5.6, Microsoft addressed this security weakness with a new digital code-signing mechanism that can help administrators reduce the threat of malicious code. Although using digital signatures is an excellent practice, it's useless unless administrators properly configure WSH to enforce signature verification and validation policies; by default, this security mechanism isn't activated. Moreover, script developers need to sign their scripts with a signature guaranteed by a certificate from a known CA to ensure that the person who runs the script can verify the trustworthiness of the script author.
WSH 5.6 ships with Win.NET Server and XP. You can also download it as a separate module for Win2K, NT 4.0, and Windows 9x from the MSDN Web site at http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/733/msdncompositedoc.xml.