Prevent users from running unauthorized scripts
Windows 2000's Windows Script Host (WSH) scripting infrastructure is a simple yet powerful environment for creating and hosting scripts. Used in combination with Win2K technologies such as Active Directory Service Interfaces (ADSI), Collaboration Data Objects (CDO), and Windows Management Instrumentation (WMI), WSH greatly enhances an administrator's scripting capabilities. Win2K's addition of thousands of scriptable COM objects made creating administrative scripting solutions even easier.
However, the arrival of the LoveLetter.vbs virus in May 2000 changed the perception of Windows scripting. Although the Windows community was happy to have a powerful scripting infrastructure with thousands of scriptable COM objects, this scripting facility also presented a security weakness: Virus writers could more easily create and distribute malicious code.
In October 2001, Microsoft released WSH 5.6 as part of Windows XP. WSH 5.6 introduces a security model that uses a new code-signing feature and enhanced control over script execution to reduce the risks from malicious code such as the LoveLetter.vbs virus. After some background about the underlying security technologies of this new security model, I walk you through a script that illustrates how to add a digital signature to your code and show you how to create policies to enforce WSH security.
Digital Signature Technology
Microsoft Authenticode technology, coupled with an infrastructure of trusted entities called public key infrastructure (PKI), provides the code-signing capability. Authenticode technology is a set of industry-standardbased developer tools that let software publishers attach to their programs and scripts digital signatures that include information about themselves and their code. PKI is a security model that offers businesses protection for their networks through the use of technologies such as public key cryptography, digital certificates, and security policies. Windows PKI is an integrated set of security components and services built into Windows OSs.
Although Authenticode technology doesn't guarantee that signed code is safe to run, a digital signature on a program tells users that the software publisher is a PKI participant, and as such, is less likely to be distributing harmful code. I won't discuss the details of Authenticode and PKI here, but you can obtain more information about these and other Microsoft security technologies by searching Microsoft's security Web site at http://www.microsoft.com/security/default.asp.
Obtaining a Certificate
Before you can add a digital signature to your code to guarantee its integrity and origin, you must obtain an appropriate digital certificate. A certificate is a data set that identifies an organization, a script developer, or some other entity. The certificate issuer, called a Certification Authority (CA), issues a certificate after verifying a certificate applicant's identity. The certificate's data set includes a public key. When you sign a script with your private key, other parties can verify your identity by retrieving your public key from the certificate contained in the script.
To obtain a certificate from a CA, you must meet the criteria for a commercial or individual publishing certificate and submit your credentials to a CA such as VeriSign or Thawte. Keep in mind that CA services aren't free. Also, make sure that obtaining a certificate from one of these companies doesn't conflict with your company's security practices. Verify that your company isn't already using a PKI and that it doesn't already have an external CA for its employees.
If you want to obtain a certificate just for testing purposes, you can install Microsoft Certificate Services, available in server versions of Win2K, and use it as your CA. (For instructions about how to install Certificate Services, refer to the Windows PKI documentation checklists at http://www.microsoft.com/windows2000/en/advanced/help/sag_sechecklist.htm.)But be sure to use the certificate it generates for internal use or testing purposes only. A certificate that an internal CA issues will have little value to external entities because they won't know or trust the CA. After you obtain your public/private key pair (i.e., your certificate) from Certificate Services, you can use the certificate to sign your scripts. When you run signed scripts in your test lab, Windows PKI will recognize and verify the signature.
After you install Certificate Services, you can request your certificate for code signing through the Microsoft Management Console (MMC) Certificates snap-in. Expand Console Root, Certificates - Current User, Personal. Right-click Certificates and select All Tasks, Request New Certificate, as Figure 1 shows. A wizard will guide you through the steps to get your certificate and will prompt you to enter a certificate-friendly name (i.e., the certificate display name). The wizard will ask you to choose a certificate template; select the CodeSigning template. If you don't see this template in the list, you must install it in your CA by opening the MMC Certification Authority snap-in and selecting the Certificate Template to Issue option. Your system saves the new certificate in your certificate store with a name that corresponds to your common name (CN).
Add a Digital Signature to Your Scripts
Now that you have a certificate for signing your script, let's look at a sample script that illustrates WSH 5.6's new code-signing feature. Listing 1 shows the Windows Script (WS) file SignScript.wsf. SignScript.wsf adds a digital signature to a script by using a set of command-line parameters. The script uses the XML command-line parsing feature—a new component of WSH 5.6—which makes writing command-line scripts easier.
The and tags at callout A in Listing 1 group the set of runtime command-line arguments for the script. Because the script accepts more than one command-line argument, a set of tags encloses each argument. For example, a command-line argument definition enclosed in the XML tags with the name file provides a /file argument at the command line, and an argument named cert provides a /cert argument at the command line.
When the script starts, it executes the lines at callout B to verify the presence of both the file and cert command-line arguments. (These two arguments are required; the store argument is optional.) Each test evaluates a Boolean value to determine the presence of the command-line arguments. For example, the expression
WScript.Arguments.Named.Exists("cert")
returns a Boolean value of True if the command-line argument cert is present. If one of these two switches is missing, the ShowUsage method (new with WSH 5.6), which callout C shows, uses the information contained within the tags to display Help text, as Figure 2, page 14, shows.