Long ago, when the grass was greener and the internet was safer, the Web Based Enterprise Management (WBEM) initiative was born in IT. Originally sponsored in 1996 by companies such as Cisco Systems, Intel and Microsoft, it has been widely adopted and implemented across platforms ranging from MAC OS to Redhat. WBEM is clearly documented, based on Internet standards, and provides a different approach to systems management than SNMP, for example.
The adaptation of WBEM for Windows is called WMI (Windows management interface) and was first introduced in Windows XP. We know that systems update faster than their components, and many vulnerabilities that were previously a convenient management tool migrate from version to version. In this article, I want to describe how WMI tasks are performed and how to avoid potential risks.
Due to its power, WMI allows using special utilities or scripts to perform various potentially dangerous actions on a PC, including stopping critical services and even shutting down the computer. For example, like this:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges) .Win32Shutdown (5)
(GWMI -Class Win32_Service -Filter "name = 'WinRM'" -ComputerName Server) .StopService ()
In addition, perform the same actions on the remote machine just like on the local one - just write the name of the required machine in the path to the WMI object.
The WMI namespace is a section of the WMI repository that is designed to group WMI classes and objects by purpose, plus define security attributes when accessing classes and objects in each such container. All namespaces begin with a root, which is denoted by the keyword root in WMI. The namespace is followed by a slash after the root name. Namespaces can be nested. Most of the interesting classes and objects are located in the root / CIMv2 namespace.
One of the existing Windows WMI namespaces can be selected as the default. This means that if you try to connect to this host without specifying a namespace, then you will automatically be connected to the one selected by default. In a standard Windows installation, the default space is root \ cimv2.
WMI technology is intended for Windows administrators, and the entire security system in WMI is designed so that using WMI scripts, a user on a given PC can perform only those actions for which he has been given permissions / privileges. These are the so-called default privileges. This is how WMI security is implemented at the operating system level: if the user at the operating system level is not given the privilege to restart the computer, then using WMI he will not be able to do this.
Additional security policies in WMI are implemented at the Distributed COM (DCOM) protocol namespace level, a distributed component object model. To take a closer look at these types of WMI security, I will briefly recall the basic general concepts related to security in Windows. And this security is based on usernames and their passwords.
About WMI permissions
When a user is created in Windows, their system account is assigned a unique security identifier (Security IDentifier, or SID). Based on the SID, an Access Token is generated for the user, to which the list of groups of which the user is a member and the list of privileges that he / she possesses (for example, stopping services or shutting down the computer) is also added. This access token is also assigned to all processes that the user starts. At this time, every object of the operating system, access to which is determined by the security system - a file, or a process, or a service or something else - has a Security Descriptor (SD). This descriptor, in turn, stores the Access Control List (ACL) for this object.
So, when a user or a process launched by him accesses an object, the access token of this user is compared with the access control list. Depending on the results, permission / privilege is issued or denied to perform the requested actions on the object.
At the namespace level, the WMI security mechanism follows the general Windows security model. Each namespace can have its own security descriptor that stores an access control list (ACL).
Each Access Control Entry (ACE) entry contains information about what permissions a particular user has when performing various operations in that namespace.
And here is the list of permissions when working with the namespace:
Execute Methods. Allows calling methods of classes from a specific namespace. Whether the method succeeds or fails depends on whether the user has permission to perform the operation on the system.
Full Write. Allows the creation and modification of subnamespaces, system classes, and class instances.
Partial Write. Opens the ability to create and modify any static classes and instances of non-system classes.
Provider Write.Lets you check out WMI provider classes and instances of those classes to the CIM repository.
Enable Account. Grants read access to the WMI namespace. Users with this permission can run scripts on the local computer that read WMI data.
Enable remotely (Remote Enable). Allows users to access the WMI namespace on a remote computer. By default, only administrators have this permission; standard users cannot retrieve WMI data from remote machines.
Read Security. Gives the right to read the security descriptor for the WMI namespace without modification.
Change security rules (Edit Security). Allows you to change the security descriptor for the WMI namespace.
All of these ACL entries are stored in the WMI repository. WMI permissions for a particular namespace apply to all subnamespaces and classes that are defined in that namespace (inherited from). You cannot define your own security permissions for an individual WMI class.
About the default setting
On Windows, the Administrators group has all the permissions from the table above, and for other users the account is enabled ( Enable Account ), it is allowed to call methods ( Execute Method s) and to write instances of provider classes to the CIM ( Provider Write ).
An administrator can change permissions for specific users by using the WMI Settings utility (MMC Management Console wmimgmt.msc snap-in).
Screenshot 1.
The above DCOM protocol is used to access the WMI infrastructure on a remote computer. The user runs a script or connects to WMI using special utilities and acts as a client, and the WMI object being accessed is a server. Standard DCOM impersonation levels are used to determine which access token will be used when working with WMI on a remote computer.
About Impersonation or Impersonation Levels
In Russian it sounds somewhat clumsy. What is impersonation and why is it needed? This is a technique where a process or system must use the credentials of another security principal, rather than its own security context, to connect to a resource.
Imagine - a certain service launched in the LocalSystem security context must perform an action on behalf of another account (for example, on behalf of the current user logged on to the computer). In this case, the service needs to create a special Access Token that describes the security context of the account under which we want to perform the specified action.
In order to create such an access token, the service needs to know the credentials of this user, and if this process occurs on the local machine, obtain a copy of the access token of the previously registered locally user.
To do this, the security context of the service must have the privilege of creating access tokens.
There is a more complex version of impersonation - delegation. This option is necessary when the connection to the target resource is not performed by the security principal itself (in the example above, by the service on behalf of the user), but through an intermediary (for example, an intermediate server).
Imagine: a user connects not directly to the database, but through a web application on a third server. To make such a connection, the web application must receive a delegate access token from the security principal (our service) - this will allow the web application to use the security principal's access token when it connects to the database.
In the case of WMI, delegation may look like this: we, working at the administrator's station, connect via WMI to a certain server and start a process on it using the Execute method of the Win32_Process class. This process is nothing more than another WMI script that connects to another host on the network in order to perform some action. If we do not use delegation, then on the target machine the script will be launched in the security context of the intermediate server account, which is far from always desirable. On the other hand, a similar situation with delegation in real life happens quite rarely.
About Impersonation Levels
Anonymous access (Anonymous). The server object has no right to get information about the user or the process that is accessing this object (in other words, the object cannot impersonate the client). This level of impersonation is not used in WMI.
Identification. The server object can request an access token associated with the client, but it cannot impersonate.
This level of impersonation is rarely used in WMI scripts, in which case you cannot run WMI scripts on remote machines.
Impersonate.The server object can use all the rights and privileges that the client has. It is recommended that you use this level of impersonation in WMI scripts, because then the WMI script on the remote machine will be able to perform all the actions that the user who runs the script is allowed to do.
DelegateAn object on a server that a client is accessing can refer to another object on a different server on behalf of the client. Delegation allows a script to use the access token of the user running it on the remote machine. The same token is used to access WMI objects on other workstations. There is a potential risk with this level of impersonation; delegation in WMI scripts should only be used when strictly necessary.
The default impersonation level depends on the version of WMI on the target computer. In versions of WMI below 1.5, the default level is Identify, in versions of WMI 1.5 and above - Impersonate. If necessary, you can change the default impersonation level by writing the name of the required level (for example, impersonate or Delegate) in the registry key
HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Wbem \ Scripting \ Default Impersonation Level .
Screenshot 2.
The DCOM protocol also provides the ability to request a specific level of authentication (authentication) and privacy for a WMI connection:
None. No authentication.
By default (Default). Standard security settings are used to select the authentication level. This is the recommended level because the client will be assigned the server-specified authentication level.
Connections (Connect). The client is only authenticated when it connects to the server. After the connection is established, no additional checks are performed.
Calls. The client is authenticated at the start of each call, while the server accepts requests. In this case, the packet headers are signed, but the data itself (the contents of the packets) transmitted between the client and the server is not signed or encrypted.
Package (Pkt).All data packets sent to the server from clients are authenticated. As with call-level authentication, packet headers are signed but not encrypted. The packages themselves are not signed or encrypted.
Package integrity (Pktlntegrity). All data packets are checked for authenticity and integrity. It is checked that the contents of the package have not been changed during the transfer from the client to the server. In this case, the data is signed, but not encrypted.
Privileges (PktPrivacy). All data packets are authenticated and integrity checked, and the data is signed and encrypted to ensure the confidentiality of the transmitted data.
Windows administrators are well aware of the system security settings available in the System Security Console and Domain Group Policies and the User Right Assignments section. A number of actions with the operating system can be done only if the user or group, which he belongs to, has one or another privilege. Such actions, for example, include: rebooting the system (shutting down its work), restoring the state of the system from a backup, or changing the system time.
Because WMI can perform all of these actions, the WMI developers have provided an additional security mechanism: even if a user account has the privileges required to operate on the system, it still cannot perform this action until it explicitly activates the privilege before performing the action. In particular, if an administrator runs a WMI script requesting a system reboot, this will still not happen until this privilege is explicitly activated in the script.
Summary
What is suggested to be done to secure WMI connections:
- Change the level of impersonation for critical services (Screenshot 2).
- Configure permissions wmimgmt.msc (Screenshot 1).
- Change the default repository. This can break the pattern attack scenario.
4. Change groups of persons with remote launching and WMI activation capabilities via the DCOMCNFG utility
5. To launch WMI, a user must be a member of the administrators group or DCOM users. The remote registry service must also be available.
6. Configure firewall - incoming connections to DCOM go through TCP port 135 and (have?) RPC dynamic range.
In conclusion, I want to say the following: WMI gives speed, power and ease of running commands on remote hosts, and SQL based command semantics makes it easy to learn.
There is a lot of information on the Internet about hacking and WMI attacks, because they fit into the current attack trend - the use of native system hacking tools - along with telnet NTP and DNS. Our task is to catch this trend and find methods of counteraction already embedded in the system.
Author: Galiulin Timur GTRch