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.
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
|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
||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
||Callers credentials are never
|| Pre-1970s hijackings airport
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.
||Every time a new call is made,
credentials are checked.
|| First the agent, then the security
checkpoint, then as you board the plane.
||Each packet sent requires credentials
|| ID is requested when you leave
your seat, sit in your seat and receive your lunch.
||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.
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
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
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.
||Execute WMI object methods.
||Read, Write or Delete objects
and class definitions from CIM.
||Write to static (CIM vendor
independent) WMI objects.
||Write to dynamic objects and
objects managed by vendors.
||Read WMI object properties.
||If set, a user can access WMI
from a remote machine and have the same permissions that
have been locally set.
||Read WMI security settings.
||Change WMI security settings.
|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
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.