Securing Remote Management with WMI

Writing scripts for remote computer management can save man-hours and shoe leather. But like any part of Windows, it has to be properly secured, or you risk opening up your network to the bad guys.

• By Roberta Bragg
• February 01, 2002

I’ve been doing a lot of traveling lately and I’ve learned something. I’ve learned how vulnerable most airplanes are to takeover and how much more secure they are now that increased security measures are being taken at every airport. While I’m not happy about the extra delays, and I’m really upset that someone thinks I might attack a stewardess with my toenail clippers or that my knitting needles are dangerous (hey, yeah, I might knit an afghan), I’m quite willing to blindly obey every new restriction. After all, what choice do I have? I want to travel quickly between cities many miles apart and I really don’t want to give some small-minded, morally challenged coward an opportunity to kill people, so I’ll follow all the security rules whether or not I see the logic behind them. How I wish similar restrictions were placed on administrators of Windows systems; but, because you want the reasons behind security precautions, I’ll explain the why and wherefore. Hopefully, you won’t wait until disaster strikes to utilize this information.

So, quick, what’s the answer to tedious sessions with a GUI interface and systems administrators, slimmed from running around endlessly, visiting machines to update settings? What’ll make Unix aficionados who now have to manage Windows 2000 grin? What’ll get you home before midnight? The answer is writing scripts to manage those systems remotely. These scripts can do so by making calls to Windows Management Instrumentation (WMI).

WMI is Microsoft’s implementation of the Common Information Model (CIM). CIM is a vendor-independent standard for describing the hardware and OS components of computer systems and providing tools that a program can use to both read and modify components. The model provides a schema that describes static objects (those common to all computing devices) to which vendors may add dynamic objects (those specific to their products). The Distributed Management Task Force (DMTF), a consortium of PC hardware and network vendors, originally published CIM in 1996. In 1998, DMTF absorbed the efforts of another initiative, Web-Based Enterprise Management (WBEM), whose goal was the development of Web-based standards for enterprise administration. WMI describes the Windows operating systems, including file systems, event logs, devices, services, hardware controllers, processing and memory. While Microsoft-specific details are included, WMI is based on the CIMv2 Schema, a vendor-independent model of operating environments. Management applications and scripts can be written that take advantage of WMI. Eureka! We can manage Win2K, Windows NT and Windows 9x remotely across our networks. And, more important, we administrators can do so by writing our own scripts that make calls to WMI to do exactly what we want.

But can we do so securely?
Hmmm. Well, before you rush off and learn how to use this powerful tool, spend some time learning about the WMI security model and then use that knowledge as you craft scripts and your administrative model for deployment and use. Remember, security isn’t an add-on.

WMI doesn’t offer some magic back door to Windows systems. Like any process, WMI operations must follow the Windows security model you’ve implemented in your systems. Let me repeat: WMI-based scripts have to follow the Windows security model you’ve implemented in your systems. It doesn’t allow any WMI script to do anything the OS wouldn’t allow. If you haven’t patched systems, or if you haven’t followed commonly accepted policies and procedures for securing systems, WMI may become a self-destructive source in your network. If you’ve followed commonly accepted security policies and procedures, but ignore them and don’t create and utilize WMI scripts using a security model, you leave your system vulnerable to attacks and acts of gross stupidity. So, before you write your first management script, learn how to do WMI the right way, the secure way.

First, you must understand three WMI security levels. Like the airlines, you can’t afford to implement any new service, or continue with the old ones, without considering the security implications.

• WMI must obey native OS security limitations. If you understand the Windows security model, including access control and authentication, you’ll be able to leverage this knowledge to securely use WMI and block unauthorized use. Without this background, you’ll be continually frustrated and end it by granting everyone membership in the Administrators group. Remember, administration is not just “making it work”—it’s making it work in a secure manner.
• Since WMI is a DCOM application, DCOM—the distributed (i.e. across the network) implementation of the Component Object Model—can be configured to accept or reject WMI connections.
• The WMI service authorizes WMI script actions based on user credentials assigned to WMI objects.

Some security levels may be specified in the WMI call (a script statement that invokes WMI). The WMI calls are considered to be the client in the DCOM client/server model. Security for the server is dictated by registry settings for WMI on the machine. If no WMI configuration is done and no security levels are specified in the call, the defaults will prevail. DCOM registry settings are configured on the local machine and can’t be modified without explicit permission.

Native OS Security Limitations
In addition to obeying DACLs set on resources, WMI must also operate within the bounds of privileges assigned to the security context under which it’s operating. So, for example, if a user making a WMI call wants to clear the security log to cover his or her tracks, they must have that privilege, which is normally reserved for administrators. As an additional precaution, the DCOM specification requires that the explicit request to use most privileges be specified in the WMI call.

DCOM for Connection Control
DCOM controls connections between DCOM applications. WMI is a DCOM application; therefore, when you make calls to WMI in your script—whether they’ll run on a local or remote machine—DCOM comes into play.

If your WMI script attempts to execute WMI methods on a remote machine, it must first connect to that machine. This connection is controlled by DCOM settings. You can display or modify them through the dcomcnfg.exe application or by accessing the WMI component by using the Windows Component services MMC. Dcomcnfg.exe allows settings configuration for all DCOM applications. The dcomcnfg.exe default properties page can also be displayed using the Component Services MMC. Specific configuration for WMI, or any other DCOM application, is reached by selecting the applications on the Applications page of dcomdnfg.exe and clicking the Properties button.

There are two ways DCOM settings can have an effect. First, a DCOM application can be executed using various impersonation levels. Second, DCOM authentication levels determine if a caller’s credentials are checked and how frequently.

Impersonation levels determine the security context under which a DCOM application operates. A running process under Win2K operates under the security context of the user who executes it, so the process or application can only do that which the user account is allowed. The application can only access the resources (files, printers, objects) for which the user has permission. In the case of a service such as WMI, the normal security context is that of the account assigned to the service. For WMI, this is the system. Imagine what would happen if this couldn’t be adjusted! Every WMI script would operate with the full authority of the system. And what can the system do? Yep, you see the problem.

Who Are You, Anyway?
When a DCOM application such as WMI is executed, an impersonation level is requested. DCOM then changes the security context under which an application runs. The script may be able to do things the user can’t or may be unable to do things the user can. This is, of course, both a benefit and a disaster waiting to happen. While judicious use of this feature allows non-administrative users to run scripts designed to allow them management responsibility over designated machines, incautious use allows non-administrative, non-designated, potentially malicious users to run powerful, possibly damaging scripts on local and remote systems.

While DCOM impersonation levels are set by the calling script, the WMI service on the receiving system is set to respond to the levels in a method that allows authorized users to perform job duties, while providing a security boundary capable of deflecting attacks. Permission set on WMI namespaces (collections of WMI objects) determine if the calls are successful. The impersonation levels and WMI responses are:

• Anonymous (no calling user identify is exposed). WMI won’t honor these requests; it needs to know who’s asking for services in order to do security checks.
• Identify (the calling user identity is known). WMI uses its security settings to determine whether the process will run. WMI runs under the security context of the account that runs the WMI service on that machine. The default is the system.
• Impersonate (WMI is asked to run using the caller’s security context). WMI uses its security settings to determine whether the process will run. If it runs, it uses the security context of the caller. This is the default impersonation level for WMI on Win2K, as shown in Figure 1.

Figure 1. It’s important to remember that the default WMI settings are Impersonate and Connect.

• Delegate (connect to a remote system and use it to connect to DCOM services on remote machines and use the caller’s security context). Using this impersonation level carries the most risk. A poorly designed WMI script could wreak havoc across your network. You should note that this is only possible using Win2K-to-Win2K computers in an Active Directory domain. The Delegation impersonation level is only possible when Kerberos is used as the authentication mechanism.

“Have Your Photo ID Out and
Available Before Boarding…”
I can still remember when a photo ID wasn’t required to get on an airplane—ever. This is the equivalent of the “None” DCOM authentication level. Other levels parallel increasing security levels at the airport as well. Unlike airport security, DCOM authentication is set on both client and server and must be the same in order for any communication to take place. Table 1 is a listing of the levels and their rough equivalent for airport security measures.

Level Definition Parallel Default Use Windows 2000 default set for all DCOM applications. This is set in the WMI components snap-in at Administrative Tools | Component Services | My Computer | Properties | Default Properties page. No local interpretation of government requirements for security. None Callers credentials are never checked. Pre-1970s hijackings airport security. Connect         Credentials checked when first connection is made. Subsequent calls go unchecked.         The desk agent or gate agent asks to see your ID. You’re never asked again. Call Every time a new call is made, credentials are checked. First the agent, then the security checkpoint, then as you board the plane. Pkt Each packet sent requires credentials checks. ID is requested when you leave your seat, sit in your seat and receive your lunch. PktIntegrity Each packet requires credentials checks, and checksums are used for data integrity. Your bags are checked before and after you board. A contents list is compared. PktPrivacy Authentication, checksums and encryption for all packets. All of the above and you get to wear a bag over your head. No one but airline employees and guards know your identity. You only have to remove the bag when they ask you to do so.

Table 1. A listing of DCOM authentication levels and their airport-security comparisons.

I know that some of my yet-to-be implemented airport parallels to DCOM authentication levels seem ridiculous. Likewise, not every DCOM application requires PktPrivacy. You should, however, be aware of these levels and assign the appropriate level to the applications. It’s just like any other form of security: Balance the severity with the risk and re-evaluate your choices in the light of changing reality.

The Default Properties page of Administrative Tools | Component Services | Computers | My Computer allows the setting of the default DCOM properties. To set specific security properties for WMI, run dcomcnfg.exe from a command prompt and select Windows Management Instrumentation from the Applications tab, then click the Properties button. Using dcomcnfg modifies permissions in the HKEY Classes Root location for the application selected. In Component Services, DCOM is enabled by default. You may wish to disable DCOM to prevent remote administration using WMI and other DCOM applications on sensitive systems. Remember, though, that this will block remote-administration attempts—even yours. Note that the default authentication level is Connect, and the default authorization level is Identify. Loose and potentially dangerous settings here would be an authentication level of None (no credentials checked) and an authentication level of Delegate (remote management extending beyond this system.) Some Windows systems aren’t capable of all delegation levels.

You should also note that COM Internet Services isn’t enabled. This would be required should you wish to implement remote control via the Internet. (You’ve got to be joking, right?)

Pay particular attention to the Security tab. You may want to restrict who can access WMI (Allow or Deny a group from even looking an WMI), launch (make WMI calls), and configure WMI (change these settings). I’d pay particular attention to who has the rights to configure WMI; after all, you may have learned to respect the security implications of WMI, while others may not. If you do modify these security settings, don’t forget to include SYSTEM!

WMI Service Authorization
WMI service authorization is controlled by setting DACLs on WMI objects. Without authorization, you won’t be able to make a WMI call. This is done within the WMI Control MMC, which is in the Computer Management Administrative tool, or can be accessed by loading wmimgmt.msc (Figure 2). Each machine’s WMI service authorization permissions apply to that machine only. This means that in order to manipulate objects on remote machines, you’ll need WMI service authorization on the remote machine. Multiple WMI object categories, or namespaces, exist. Relevant objects for administrative control exist under the CIMV2 namespace. Setting security is similar to setting DACLs on files, folders and AD objects: A Security Properties page is opened and security is applied to objects by assigning permissions to user groups. Possible permissions include those in Table 2.

Figure 2. The WMI Security tab. Setting permissions here is similar to setting normal DACLs.

Remember that other security mechanisms prevent blatant misuse of WMI. Before you remove groups from WMI permissions, note that the default permissions don’t allow groups other than administrators to do any remote WMI. Local users have some control over Windows-specific WMI controls on the local machine. And, as always, don’t change WMI permissions on production systems without adequate testing in a test environment.

Permission Definition Default Execute Methods Execute WMI object methods. Administrators Everyone Full Write Read, Write or Delete objects and class definitions from CIM. Administrators Partial Write Write to static (CIM vendor independent) WMI objects. Administrators Provider Write Write to dynamic objects and objects managed by vendors. Administrators Everyone Enable Account Read WMI object properties. Administrators Everyone Remote Enable If set, a user can access WMI from a remote machine and have the same permissions that have been locally set. Administrators Read Security Read WMI security settings. Administrators Edit Security Change WMI security settings. Administrators

Table 2. Possible security settings for WMI.

Doing WMI Security Right
So how can you use your new-found knowledge to securely use WMI and/or prevent its unauthorized use? Like any security methodology, doing WMI the right way requires you to think about a layered defense.

First, if you want to block all remote administration, you could disable DCOM on those machines. You will, however, prevent every DCOM application from running. A better choice might be to visit dcomcnfg.exe and configure DCOM for the WMI service alone. (For clarification, view the list of DCOM applications present in the dcomcnfg.exe applet—you may be surprised.)

Second, there’s reasonably adequate security with the default settings for WMI. Administrators are the only ones allowed to execute WMI remotely. However, should you choose to delegate this right to help-desk personnel or some other quasi-administrative group, you have only to create such a Win2K user group and give it Remote Enable permission on only the systems you want the group to manage. You can further tighten WMI permissions settings by removing the Everyone group from the permissions it has. Test this extensively before rollout, though—you may find this too restrictive. Use Deny permissions to explicitly block any group you have reason to believe may attempt to remotely sabotage your systems.

Third, make sure DCOM authentication is never set to None. The identity of the calling user will never be questioned, and we’ve all learned this is not good.

Fourth, create a trusted group of administrators and give this group—and this group only—the ability to modify DCOM settings. Setting up DCOM once won’t protect your systems if the widespread ability to change settings exists.

Additional Information Setting Processwide Security using Dcomcnfg.exe: http://msdn.microsoft.com/library/default.asp? url=/library/enus/com/security_1xbb.asp How to Use Dcomcnfg to Set Security for a Visual Basic DCOM Client/Server Application: http://support.microsoft.com/support/kb/articles/Q268/5/50.ASP Enabling DCOM Security using Dcomcnfg: http://msdn.microsoft.com/library/ default.asp?url=/library/enus/com/security_4l7r.asp Windows 2000 Supports Delegation with Kerberos Authentication Service: http://support.microsoft.com/support/kb/articles/Q262/2/91.ASP COM Security in Practice: http://msdn.microsoft.com/library/default.asp? url=/library/enus/dncomg/html/msdn_practicom.asp Windows Management Instrumentation, Matthew Lavy & Ashley Meggitt, New Riders, 2002.

Last, but not least, make sure Windows permissions and privileges are set appropriately on every machine! WMI can’t override these settings.

OK, now that you’ve designed and implemented your WMI security model, it’s time to grab the scripting books and articles, learn some scripting techniques and WMI methods, and manage your systems from a chair in your office. Actually, make that the weight machine/treadmill/bicycle—you’re going to find you need the exercise.