S 2.367 Use of commands and scripts under Windows Server 2003 and higher

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

In practice, commands and scripts are often used to perform minor tasks such as setting or displaying certain parameters. Scripts allow for automatic running of commands. Incorrect operation and lack of knowledge can multiply the risk connected to an individual command in a script. For this reason, scripts must be used with care so that their effects remain controllable and understandable. If the time and effort needed for planning, designing, and maintaining scripts is acceptable, then you can simplify and standardise administrative tasks using scripts.

Commands

Commands are understood to be the calling of programmes using the Run... menu entry or entered at the prompt of the command line. While the command line interpreter command.com is used in DOS, the much more powerful CMD.exe is available in Windows. Everything that can be called in the CMD shell is referred to as a command. Differentiation must be made between the implicit commands and control constructs of the CMD shell, the commands of the operating system, and the commands of third-party manufacturers. Commands can be collected and assembled in a readable file (batch file, special script file).

Scripts

A script is a plain text file that can be created using any text editor such as notepad.exe. The statements contained in a script are executed by calling the corresponding interpreter. Scripts are used in Windows mainly for automating administration tasks. In particular, they make it much easier to execute a series of administration tasks a multiple number of times. If they are executed automatically, for example using Planned Tasks, then they also execute when an administrator is not present. Reusing scripts guarantees the traceability and uniform quality of the tasks performed.

Requirements

The same requirements should apply to script interpreters, supplied scripts, scripts in optional packages from the manufacturer (e.g. MBSA, Support Tools, Resource Kit), and user-defined scripts as those that apply to standard software (see module S 1.10 Standard software). In the end, such scripts are standard software for administration. The requirements and conditions for the creation and execution of scripts must be analysed, and mandatory specifications must be made based on the analysis. Furthermore, all scripts developed internally as well as all tools and scripts from third party manufacturers must be adequately documented and tested (see T 2.83 Testing standard software).

Scripts that are critical to the operation of an IT system environment may only be written or maintained by administrative personnel who are adequately trained in the programming of scripts and who have sufficient experience in this area (see T 2.67 Inappropriate administration of access rights). It must be ensured, especially in the area of administration and its automation, that no unauthorised or unreleased software in the form of tools or complex scripts are used. Do not use software whose source cannot be determined. Furthermore, the environment in which scripts are allowed to run must be adequately protected against misuse and malware.

The framework for the use of scripts should be specified in a security policy. At a minimum, the security policy must specify for what purpose the scripts will be used and where they come from, as well as which script environments and script languages are allowed for use. Furthermore, the requirements applying to the development and release of scripts in certain areas of application must be specified. The safeguards must always be applied, unless specified otherwise. However, it must be taken into account that this may not be effective and practical for every area of application under some circumstances, for example in the case of login scripts.

You should consider prohibiting the use of unsigned scripts in general. The signatures are based on security certificates. Scripts from the manufacturer are already signed. It is recommended to create your own certificates using templates from a Windows Server 2003 certification authority. Special programming objects in the cryptographic API of Windows are used to sign the certificates, and these objects can be accessed in scripts. More detailed information for Windows Server 2003 can be found in the Platform Software Development Kit (Platform SDK) or, for Windows Server 2008 and higher, in Windows SDK. This policy can be implemented in Windows XP/Server 2003 or higher for administration purposes with the help of a software restriction policy.

Basic principles

It must be taken into account for all scripts that scripts are generally upward compatible, but are often not downward compatible due to new developments and the use of new functions.

Scripts are always executed in the security context of the user session calling the script; they possess the authorisations of this security context while they are running. When a script is started by a service or a running process, the security context of the service or process also applies to the script. For many functions accessed in scripts, administrative privileges are needed to access individual objects or the entire server.

If scripts (e.g. login/logout scripts) or services (e.g. in connection with data backups) are provided to users, then no unauthorised, extended rights are permitted to be granted when the script executes.

In many cases, scripts are distributed and executed automatically using domain logins or through the group policies of the Active Directory.

It must be ensured that the source text of administrative scripts cannot be seen by the users and that the scripts do not affect operations. Corresponding settings are located in the administrative templates supplied under Administrative Templates | System | Scripts.

For Windows Server 2008 and higher, it must be noted that scripts are also subject to user account control (see TS 4.340 Use of the Windows User Account Control UAC in Windows Vista and higher). This may result in the fact that scripts generated with earlier Windows versions do not work any more because they are lacking administrative privileges.

System resources for scripts:

Standard installations under Windows Server 2003 and higher have extensive capabilities available for creating and executing scripts:

These are script environments provided by the manufacturer that also include documentation. The batch programming capabilities were limited in older versions, but are very powerful nowadays; a FOR statement is available, for example. It is not necessary to install these programs.

VBScript is a simple script language. It does not contain any built-in functions for administration. Administration functions can only be obtained in combination with the Windows Scripting Host (WSH) and the interfaces to the Windows Management Instrumentation (WMI), Active Directory Service Interface (ADSI), and other interfaces of the operating system. To accomplish this, the objects to be provided through a given interface must be integrated into the corresponding script. They can still be used without knowledge of the corresponding object model with the help of extensive templates and examples, but this is not recommended in this case (due, for example, to the similarity of methods such as GetObject and CreateObject). JScript is used for the same purpose as VBScript, but they are different in terms of their syntax, which in the case of JScript is based on the Java programming language syntax. Development of VBScript and JScript has been discontinued since the release of Windows Server 2003 and therefore must be examined critically in terms of the ability to use them over the long term.

Scripts (for example in the form of .vbs or .js files) are called and processed using CScript.exe (with the output displayed in the command line) or WScript.exe (with the output displayed graphically in a window). The WSH is executed when these two programmes are called. WSH is the default environment for processing and editing scripts. It comes with its own program functions and can load extensions for WSH-compatible languages (VBScript, JScript). The WSH is an interpreter. It can use COM objects and has access to a series of system interfaces (see above). WScript.exe and CSript.exe both contain a rudimentary debugger for testing scripts.

A series of updates and patches for Windows NT/2000/XP/2003 appeared in connection with the WSH that eliminated the security problems, but also made it necessary to change some existing scripts. This should be taken into account when developing scripts for the WSH.

WMI (Windows Management Instrumentation) is integrated into Windows Server 2003 as a central management technology. WMI allows for uniform access for the configuration, administration, and monitoring of almost all Windows resources. WMI has been available since 1998 (since Windows NT 4.0 SP4). The WMI architecture is complex, consists of three layers (resources, infrastructure, consumer), and uses an object-oriented design. It was implemented using DLLs for the provider descriptions (%SystemRoot%\system32\wbem) and the WMI service (winmgmt.exe). Compatible script environments such as WSH or ActivePerl are used to gain access in Windows scripts. A WMI can be configured and the class definitions available can be analysed with the wmimgmt.msc snap-in, the WMI test program wbemtest.exe, or the command line tool wmic.exe.

With ADSI, script-based administration of the Active Directory service is possible in a manner similar to that used in the WMI technology.

New features of Windows Server 2008

The Windows PowerShell offers an extended command line and scripting environment for the Windows platform that supersedes VBScript, Jscript, and the WSH. PowerShell uses some concepts known from from the Unix environment (e.g. pipes) and is based on the .NET object model. With Windows Server 2008 and higher, PowerShell is available as an option; with Server 2008 R2 and higher, it is included in standard scope of delivery. :

Scriptomatic is a tool providing script generation capabilities. The tool supports WMI and ADSI. A version for PowerShell is also available.

There is no general product support available for many tools and scripts provided by Microsoft. Whether or not support is available must be clarified with the manufacturer on a case-by-case basis. Some of the tools were provided as teaching aids and do not have any or only inadequate error handling capabilities.

Disabling WSH

Unfortunately, the scripting capabilities available in Windows are also abused for the purpose of spreading malware. For this reason, the execution of scripts is often restricted or prohibited on clients. In a client/server environment, the administrative and organisational use of scripts justifies the higher risks involved and the corresponding time and expense incurred for security. If only command line scripts are needed, then the WSH should be blocked on the server to increase security.

The WSH can be blocked in a variety of ways:

Alternative script environments

Alternative script environments such as Perl, KiXtart, and others do not automatically reduce the number of possible points of attack. They access operating system functions as well and can also contain their own security gaps. The requirements and basic principles stated above apply in this case.

Documentation

The documentation principles generally applicable in software development must be met both for development of scripts developed internally as well as for scripts of third-party manufacturers. At a minimum, a requirements catalogue, a functional description, user help, the conditions for execution, and version control management should be available. You must be able to determine which scripts are used for a particular Windows component or a particular operating concept based on the script name and version number found in the corresponding documentation.

Review questions:

© Federal Office for Information Security. All rights reserved.