How to remediate – Windows ComputerSystemProduct Enumeration (WMI)

1. Introduction

The Windows ComputerSystemProduct Enumeration (WMI) vulnerability allows obtaining product information from a remote host using WMI. This can reveal details about a system’s configuration, potentially aiding reconnaissance for further attacks. Affected systems are typically those running Microsoft Windows operating systems. A successful exploit could lead to information disclosure impacting confidentiality.

2. Technical Explanation

This vulnerability occurs because the Win32_ComputerSystemProduct WMI class is accessible and allows querying of system product details. An attacker can use this to gather UUIDs, identifying numbers, vendor names, and other potentially sensitive information. There is no specific CVE associated with this general enumeration issue. A simple example involves using a WMI query tool like `wmic` or PowerShell to retrieve the product information. Affected systems include those where remote WMI access is enabled without sufficient restrictions.

• Root cause: The Win32_ComputerSystemProduct class allows unauthenticated or insufficiently authenticated queries for system details.
• Exploit mechanism: An attacker uses a WMI query to retrieve product information. For example, using `wmic csproduct get IdentifyingNumber,Vendor`.
• Scope: Microsoft Windows operating systems with enabled remote WMI access are affected.

3. Detection and Assessment

You can confirm vulnerability by checking for accessible WMI classes on a target system. A quick check involves attempting to query the Win32_ComputerSystemProduct class. More thorough assessment requires scanning for open WMI ports and testing access permissions.

• Quick checks: Use `wmic csproduct get IdentifyingNumber` from a remote machine. If output is returned, the system is likely vulnerable.
• Scanning: Nessus plugin ID 10385 can identify this issue as an example.
• Logs and evidence: Check Windows Event Logs for WMI activity related to Win32_ComputerSystemProduct queries (Event ID 4657).

wmic /node:"target_hostname" csproduct get IdentifyingNumber,Vendor

4. Solution / Remediation Steps

4.1 Preparation

• Ensure you have administrative privileges to modify firewall rules and group policies. A roll back plan involves restoring the system snapshot or reverting the policy change.
• A standard change window may be required, with approval from IT security.

4.2 Implementation

1. Step 1: Block inbound WMI access via Windows Firewall. Use `netsh advfirewall firewall add rule name=”Block WMInbound” dir=in action=block protocol=TCP localport=389,445 remoteip=any interface=any profile=domain,private,public`.
2. Step 2: Restrict WMI access using Group Policy. Open Group Policy Editor (gpedit.msc) and navigate to Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Security FirewallWindows Defender Firewall with Advanced SecurityInbound Rules. Create a new rule to allow only specific IP addresses or subnets to connect via WMI.
3. Step 3: Configure Remote Registry service restrictions if needed, as it is often used in conjunction with WMI.

4.3 Config or Code Example

Before

netsh advfirewall show all profiles

After

netsh advfirewall firewall add rule name="Block WMInbound" dir=in action=block protocol=TCP localport=389,445 remoteip=any interface=any profile=domain,private,public

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate this vulnerability type. Least privilege is key; only grant necessary access to WMI resources. Input validation helps prevent malicious queries. Safe defaults reduce the attack surface by disabling unnecessary services and features.

• Practice 1: Implement least privilege principles, limiting which accounts have access to remote WMI.
• Practice 2: Regularly review firewall rules to ensure only authorized traffic is allowed.

4.5 Automation (Optional)

You can automate the firewall rule creation using PowerShell at scale. Be careful when modifying firewall rules remotely.

New-NetFirewallRule -DisplayName "Block WMInbound" -Direction Inbound -Action Block -Protocol TCP -LocalPort 389,445 -RemoteAddress Any -Profile Domain,Private,Public

5. Verification / Validation

• Post-fix check: Run `wmic /node:”target_hostname” csproduct get IdentifyingNumber` again. The command should fail to connect or return an error message.
• Re-test: Re-run the Nessus scan (ID 10385) and confirm it no longer reports the vulnerability.
• Smoke test: Verify that applications relying on WMI, such as inventory tools, continue to function without interruption.
• Monitoring: Monitor Windows Event Logs for blocked WMI connections related to port 389 or 445 (Event ID 4657).

wmic /node:"target_hostname" csproduct get IdentifyingNumber

6. Preventive Measures and Monitoring

Update security baselines to include restrictions on WMI access for example, a CIS control or GPO setting. Implement checks in CI/CD pipelines to prevent the same misconfiguration from being deployed. A sensible patch review cycle should be established.

• Baselines: Update your Windows Security Baseline to restrict remote WMI access.
• Pipelines: Include firewall rule validation as part of your infrastructure-as-code (IaC) pipeline.
• Asset and patch process: Review system configurations regularly for unnecessary open ports or services.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Blocking WMI may break applications that legitimately use it. Mitigation involves creating exceptions for trusted IP addresses.
• Risk or side effect 2: Incorrect firewall rule configuration could block legitimate network traffic. Mitigation involves thorough testing and documentation.
• Roll back:
  1. Step 1: Remove the firewall rule using `netsh advfirewall firewall delete rule name=”Block WMInbound”`.
  2. Step 2: Revert any changes made to Group Policy settings.

8. References and Resources

• Vendor advisory or bulletin: http://www.nessus.org/u?a21ce849
• NVD or CVE entry: No specific CVE exists for this general enumeration issue.
• Product or platform