WMI Based Compliance Checks

Tenable's Research group recently added the ability to perform WMI (Windows Management Instrumentation)  queries to Windows servers and desktops as part of a Nessus configuration audit. These new features allow for rapid and in-depth auditing of a wide variety of configuration settings that are only available through WMI. This blog entry describes how the new API works, and includes several examples.

WMI Support for Windows Compliance Audits

Version 2.0.5 of the compliance_check.nbin plugin for performing Windows configuration audits includes support to perform WMI queries and audit Windows settings. The basic format of a Windows WMI audit statement is as follows:

<custom_item> 
type: WMI_POLICY 
description: "Test for WMI Value" 
value_type: [value_type] 
value_data: [value] 
wmi_namespace: ["namespace"] 
wmi_request: ["request select statement"] 
wmi_attribute: ["attribute"] 
wmi_key: ["key"] 
wmi_option: WMI_ENUM     <--- This last item is optional
<item> 

The four WMI values for namespace, request, attribute and key are required to specify the configuration settings on the remote system to be audited.

Many types of WMI settings are lists which can have multiple elements. To have the audit test each of these lists, the "wmi_option" flag can be set to WMI_ENUM. This will cause the audit to test each of the names in the namespace.

Example #1 - Testing for the correct Windows domain

Nessus has a plugin which can identify the domain of a remote Windows computer. With the new WMI auditing functionality, we can write an audit file which will tell us if the remote domain is the correct domain.

The following command line sequence prints out the audit file used to perform WMI queries, and then uses the nasl command line tool to run the test. The audit file tests remote systems to see if they are part of the Windows domain called "WORKGROUP".

[ron@test bin]# cat /root/wmi_example1.audit 
<check_type: "Windows" version:"2"> 
<group_policy: "Example WMI Audit"> 
<custom_item> 
 type: WMI_POLICY 
 description: "Member of domain - WORKGROUP" 
 value_type: POLICY_TEXT 
 value_data: "WORKGROUP" 
 wmi_namespace: "root/CIMV2" 
 wmi_request: "SELECT Domain FROM Win32_ComputerSystem" 
 wmi_attribute: "Domain" 
 wmi_key: "Name" 
</item> 
</group_policy> 
</check_type> 

[ron@test bin]# ./nasl -t 192.168.2.6 compliance_check.nbin 

            Windows Compliance Checks, version 2.0.5 

Which file contains your security policy : /root/wmi_example1.audit 
SMB login : Administrator 
SMB password : **********
SMB domain (optional) : 
"Member of domain - WORKGROUP": [PASSED] 

[root@test bin]# ./nasl -t 192.168.2.7 compliance_check.nbin

            Windows Compliance Checks, version 2.0.5 

Which file contains your security policy : /root/wmi_example1.audit 
SMB login : hulkhogan 
SMB password : ********
SMB domain (optional) : 
"Member of domain - WORKGROUP": [FAILED] 

Remote value: "corp.example.com" (LAPTOP24) 
Policy value: "workgroup"

The first audit of 192.168.2.6 tested a system and found that the domain is set to "WORKGROUP". In the second of 192.168.2.7, this system does not have the correct domain and is not compliant.

Example #2 - Hardware Inventory

In this example, we will perform an audit that shows the vendor of the network card installed on our servers. For server farms and even large desktop populations, ensuring that the right hardware is installed on computers can minimize a wide variety of IT maintenance issues which result from small variations in system configurations and helps to ensure that drivers are up to date and consistent across the enterprise.

The WMI attribute of "Manufacturer" from "Win32_NetworkAdapter" will provide a list of all vendors. Many of these will be virtual Microsoft devices, however, the primary network card and any wireless cards will each have their vendor information (if any) listed.

The following audit file illustrates how to search for systems that don't have network cards from AMD:

<check_type: "Windows" version:"2"> 
<group_policy: "Example WMI Audit"> 
<custom_item> 
 type: WMI_POLICY 
 description: "System uses an AMD Network Adapter" 
 value_type: POLICY_TEXT 
 value_data: "Advanced Micro Devices (AMD)" 
 wmi_namespace: "root/CIMV2" 
 wmi_request: "SELECT Manufacturer, Name FROM Win32_NetworkAdapter" 
 wmi_attribute: "Manufacturer" 
 wmi_key: "Name" 
 wmi_option: WMI_ENUM 
 check_type: CHECK_EQUAL_ANY 
</item> 
</group_policy> 
</check_type> 

Notice this audit policy makes use of the "WMI_ENUM" flag. Without this flag, the WMI query would not return a list of all network interface manufactures. Also notice that the "check_type" flag is set to "CHECK_EQUAL_ANY". This allows our text of "Advanced Micro Devices (AMD)" to be matched on the entire list of vendors returned by the WMI query, and as long as one matches, our audit passes.

Below is an example command line run of this audit file:

[ron@test bin]# ./nasl -t 192.168.2.6 compliance_check.nbin

            Windows Compliance Checks, version 2.0.5

Which file contains your security policy : /root/wmi_example2.audit 
SMB login : Administrator 
SMB password : **********
SMB domain (optional) : 
"System uses an AMD Network Adapter": [PASSED] 

If we wanted to allow more than one vendor, we can change the VALUE_TYPE from POLICY_TEXT to POLICY_MULTI_TEXT and list multiple strings in the value_data segment. Such an example is shown below:

<check_type: "Windows" version:"2"> 
<group_policy: "Example WMI Audit"> 
<custom_item> 
 type: WMI_POLICY 
 description: "System uses authorized network cards" 
 value_type: POLICY_MULTI_TEXT 
 value_data: "Advanced Micro Devices (AMD)" || "3COM Network Card" || "Intel Network Card" 
 wmi_namespace: "root/CIMV2" 
 wmi_request: "SELECT Manufacturer FROM Win32_NetworkAdapter" 
 wmi_attribute: "Manufacturer" 
 wmi_key: "Name" 
 wmi_option: WMI_ENUM 
 check_type: CHECK_EQUAL_ANY 
</item> 
</group_policy> 
</check_type> 

In this example, if any of the strings separated by "||" match in our list, the entire audit passes.

Auditing with WMI

If your organization has developed WMI scripts and queries to perform analysis of your Windows systems, you can adapt these scripts to Nessus audit files.

If you are new to WMI, you should spend some time researching the wide variety of tools and techniques that have been developed to analyze WMI. A tool that I like for exploring WMI information is the "WMI Utils" program that allows you to analyze your local computer as well as network computers.

Microsoft resources include the WMI Administrative Tools and my favorite is the Scriptomatic Utility.

Existing WMI Support in Nessus 3

Previous Tenable blogs have described how  Nessus 3 includes a variety of vulnerability checks which make use  of WMI queries. The basic vulnerability audits included with the Nessus Professional and Home Feeds obtain the following information:

• Computer Manufacturer and Model Information
• USB Drive Enumeration
• Network Interface Enumeration
• Wireless SSID Enumeration
• Windows Software License Activitation
• Disk Partition Types

These plugins are very useful and can offer inspiration for new types of audits.

More detailed WMI queries are also available to Nessus 3 users in the form of the wmi_func.nlib library. This file is distributed with all Nessus 3.2 downloads and allows Nessus users to call WMI APIs from their NASL programs.

For More Information

The following blogs have described running WMI queries for vulnerability auditing, or creating custom NASL scripts. 

• Wireless SSID Enterprise Discovery
• Using Manufacturer Information for Automatic Dynamic Asset List Creation
• Advanced Nessus 3 WMI Checks Against Windows Systems
• Nessus 3.2 BETA -- Example WMI library usage (Note -- Nessus 3.2 is now GA)
• WMI API Under Nessus 3.2
• Scriptomatic Utility