4.14 How WMI scripters are affected by the Microsoft security push

When working at the COM/DCOM level, the WMI client application has control of the authentication level for the WinMgmt.Exe outgoing calls (see the first book, Understanding WMI Scripting, Chapter 4, sections 4.3.3, "The security settings of the moniker," and 4.4.1, "Establishing the WMI connection"). In such a case, WinMgmt.Exe retrieves the WMI client security settings when called, and always attempts to call back the client sink routine with the same authentications level (see Figure 4.36, arrow 2). For obvious security reasons, it is always recommended that clients perform a security access check when the sink routine is invoked. However, when the WMI client is a WMI script or cannot control the security settings of the process or when the environment is pre-Windows 2000 (using NTLM), the machine LocalSystem does not have a network identity and it is impossible to control the security level of the callback. In such a case another action takes place, which utilizes UnSecApp.Exe (see Figure 4.37). Note that this slightly different action is also applicable for other applications, such as MMC snap-ins.

Figure 4.37: A WMI client application performing an asynchronous operation where UnSecApp.Exe is involved.

When a WMI script invokes an asynchronous operation, the WMI COM underlying mechanism starts UnSecApp.Exe in a separate process on the client (see Figure 4.37, arrow 1). Once started, UnSecApp.Exe passes its own sink to the client. Next , when the WMI script initiates the asynchronous call to WinMgmt.Exe, it passes the UnSecApp.Exe sink along with the call (see Figure 4.37, arrow 2). Therefore, during the WinMgmt.Exe callback, the sink utilized is the UnSecApp.Exe sink (see Figure 4.37, arrow 3). Because the WMI script can't enforce the callback security as a COM/DCOM WMI client (as shown in Figure 4.36), to get this callback working the UnSecApp.Exe accepts callbacks from everyone. Once the callback is accepted by UnSecApp.Exe, it returns the asynchronous call information back to the WMI script (see Figure 4.37, arrow 4). It is important to note that UnSecApp.Exe is only involved during the asynchronous operations. Therefore, synchronous and semisynchronous operations do not use the same mechanism.

When using asynchronous operations or event notifications in this implementation (Windows NT 4.0, Windows 2000, and Windows XP), it is recommended you take some precautions :

• If you can implement a logic that does not use asynchronous calls for your scripts, consider this option as the best option from a security standpoint. Therefore, you should always try to consider a synchronous or semisynchronous scripting technique when possible.

• If you must absolutely use an asynchronous scripting technique, make sure that the script does not perform some critical operations in the event sink (i.e., system shutdown) in a too powerful security context (i.e., administrative security context). If you implement an asynchronous scripting technique, it is a good idea to implement access checks in the client code as well. Obviously, as a preventive approach, it is best that you don't let scripts execute in the security context of an administrator whenever possible.

• Despite the previous recommendations, if you must perform some critical operations in the event sink in an administrative security context, as we will discuss in the next section, under Windows Server 2003 you can activate a lockdown mechanism, which Microsoft implements to secure the WinMgmt.Exe callbacks. Note that at writing time, there is no plan to implement a similar mechanism for the previous Operating System versions.

4.14.1.1 How the lockdown mechanism of Windows Server 2003 works

Under Windows Server 2003, Microsoft created a wrapper for UnSecApp.Exe. This wrapper plays the role of a security broker between the WMI client and the WinMgmt.Exe to validate the callbacks executed on the UnSecApp.Exe sink.

However, by default, this wrapper is disabled to ensure a backward compatibility with the WMI asynchronous applications previously developed. If the environment requires a stronger security, it is possible to enable the wrapper in two ways:

• By programming: This is only possible for the WMI COM/DCOM applications. In such case, the wrapper behavior can be determined by application, which means that one WMI client application could require authenticating the callbacks, while another will run with the default settings (Everyone).

• By changing a registry key: This is the technique to use for the WMI scripts, because there is no way from the scripting environment to determine the wrapper behavior. It is important to note that if the registry key is modified to enable the wrapper to only accept the authenticated calls, the setting is global for all applications (see Figure 4.38). There is no granularity available.

  
  Figure 4.38: The registry activating the new lockdown mechanism of Windows Server 2003.

The registry key to change is located in the registry hive HKLM\SOFTWARE\Microsoft\WBEM\CIMOM, where the UnsecappAccessControlDefault value must be changed as follows :

• To allow anonymous calls (default), the UnsecappAccessControlDefault value must be set to 0.

• To allow authenticated calls (global setting), the UnsecappAccessControlDefault value must be set to 1. Althought the default registry key value is set to 0, it is recommended to set it to 1 if you plan to use asynchronous calls in your applications or scripts.

Once enabled, the wrapper intercepts every callback to UnSecApp.Exe in order to verify the identity of the component performing the callback, which should normally be WinMgmt.Exe (see Figure 4.39). Actually, the wrapper extracts the SID of the client application from the security token when the initial call of the client application is executed (see Figure 4.39, arrow 1). When the callback to UnSecApp.Exe is performed (see Figure 4.39, arrow 3), the wrapper intercepts the callback as well to extract the SID of the caller. The extraction of the SID implies a call against Active Directory, which validates the SID existence of the caller. Next, the SID of the caller is compared with the SID of the client (see Figure 4.39, arrow 4) and if they match, UnSecApp.Exe executes the callback to the client application (see Figure 4.39, arrow 6).

Figure 4.39: A WMI client application performing an asynchronous operation where UnSecApp.Exe is involved and when the Windows Server 2003 lockdown mechanism is activated.

As long as the script runs in an authenticated security context, the activation doesn't affect the operation. However, if the callback is delivered under a different identity, the callback will not be returned to the sink routine, and UnSecApp.Exe will place an entry into the event log. However, the activation of the registry key setting could only affect applications in pre-Windows 2000 environments due to the lack of LocalSystem identity.

4.14.2 Setting the security descriptor of a CIM repository namespace

When creating a namespace in the CIM repository, the only element of information required is the name of the namespace, since the name of the namespace is used as a key property of the instance representing the namespace. However, every namespace is protected by a security descriptor, which is inherited from the parent namespace at creation time. Since the security of a namespace could be different from the one set on the parent, it is possible to set a different security descriptor (i.e., by using the SetSD method exposed by the __SystemSecurity system class). Since the security initiative, it is now impossible to set a security descriptor to null.

If by any chance the security descriptor is set to null on a namespace, the namespace will inherit the security of the parent namespace, since the "non-inheritance" option is not set. However, by eliminating the ability to set a null security descriptor, Microsoft wants to prevent anyone from deliberately removing the namespace security descriptor. Therefore, this initiative is purely preventive.

4.14.3 The ADSI WMI Extension

In Chapter 5 of the first book, Understanding WMI Scripting, we see how the ADSI WMI Extension can be used from scripts. This extension is available under Windows NT 4.0 (if ADSI and WMI are installed), Windows 2000, and Windows XP. Under Windows Server 2003 with the security push initiative, this extension has been removed from the Operating System. At writing time, the availability of this extension as a separate download is still under discussion at Microsoft. Actually, Microsoft decided to remove this extension from the Operating System for two reasons:

• One of the drivers during the security push was to leave only enabled components that are intensively used. Since the ADSI WMI Extension was not heavily used, Microsoft decided to remove it from the Operating System to reduce the potential surface of attacks.

• Although the ADSI WMI Extension is not subject to any particular security thread, Microsoft decided to remove it, since it requires high-level privileges to run.