1. Introduction
The WMI Windows Feature Enumeration vulnerability allows information about installed Windows features to be discovered using Windows Management Instrumentation. This can help attackers map a target environment and identify potential weaknesses. It affects systems running Windows Server and Desktop operating systems, potentially impacting confidentiality by revealing system details.
2. Technical Explanation
Nessus queries the ‘Win32_ServerFeature’ or ‘Win32_OptionalFeature’ WMI classes to list installed features. This is not a flaw in itself but reveals information that could aid an attacker. Exploitation requires local access to the target system. There is no specific CVE associated with this enumeration, as it’s considered an information disclosure issue rather than a direct exploit path. An attacker could use this information to determine which software is installed and look for known vulnerabilities within those components.
- Root cause: The WMI classes expose feature lists without sufficient restriction on access.
- Exploit mechanism: An attacker runs a query against the WMI namespace to retrieve the list of features. For example, using WMIC or PowerShell.
- Scope: Windows 7 and later desktop versions, all versions of Windows Server.
3. Detection and Assessment
You can confirm if feature enumeration is possible by querying WMI directly. A thorough assessment involves scanning with a vulnerability scanner that checks for this condition.
- Quick checks: Use PowerShell to list installed features.
- Scanning: Nessus plugin ID 139758 detects this issue. Other scanners may have similar checks.
- Logs and evidence: WMI event logs might show queries against the ‘Win32_ServerFeature’ or ‘Win32_OptionalFeature’ classes, though these are not always logged.
Get-WmiObject Win32_ServerFeature4. Solution / Remediation Steps
While disabling WMI is generally not recommended due to its importance for system management, restricting access can limit exposure. This vulnerability is an information disclosure issue; reducing the attack surface is the primary goal.
4.1 Preparation
- Dependencies: Ensure no critical applications rely on unrestricted WMI access. Roll back by restoring WMI permissions if issues occur.
- Change window needs and approvals should follow your organisation’s standard procedures for system configuration changes.
4.2 Implementation
- Step 1: Use the Windows Firewall with Advanced Security to create an inbound rule blocking access to WMI from untrusted sources.
- Step 2: Review and restrict permissions on the ‘Rootcimv2’ namespace using the ‘wbemadmin’ command-line tool or Group Policy.
4.3 Config or Code Example
Before
wbemadmin get wmi_namespace "rootcimv2" -n 10After
netsh advfirewall firewall add rule name="Block WMI Inbound" dir=in action=block protocol=TCP localport=389 remoteip=any interface=any enable=yes description="Blocks inbound access to WMI from untrusted sources."4.4 Security Practices Relevant to This Vulnerability
Least privilege is the most relevant practice here, limiting access to sensitive system information. Input validation and secure defaults are less directly applicable but contribute to overall security posture.
- Practice 1: Least privilege reduces the impact if WMI is compromised or misused.
4.5 Automation (Optional)
PowerShell can be used to automate firewall rule creation and permission adjustments, though caution is advised when modifying WMI settings.
# Example PowerShell script - use with care!
New-NetFirewallRule -DisplayName "Block WMI Inbound" -Direction Inbound -Action Block -Protocol TCP -LocalPort 389 -RemoteIP Any -Enabled True
5. Verification / Validation
- Post-fix check: Run `Get-WmiObject Win32_ServerFeature` from a remote machine; it should fail with an access denied error.
- Re-test: Re-run the Nessus scan (plugin ID 139758) to confirm the vulnerability is no longer detected.
- Smoke test: Ensure legitimate system management tools that rely on WMI continue to function correctly.
- Monitoring: Monitor Windows Firewall logs for blocked connections to port 389 from unexpected sources.
Get-WmiObject Win32_ServerFeature -ComputerName 6. Preventive Measures and Monitoring
Regular security baselines should include WMI access restrictions. CI/CD pipelines can incorporate checks to ensure configurations adhere to these standards. A sensible patch cycle ensures systems are up-to-date with the latest security fixes.
- Baselines: Update your security baseline or policy to enforce least privilege for WMI access.
- Pipelines: Add a check in your CI/CD pipeline to verify that WMI permissions are correctly configured during deployment.
- Asset and patch process: Implement a regular review cycle (e.g., monthly) to assess and update system configurations, including WMI settings.
7. Risks, Side Effects, and Roll Back
Blocking WMI access can disrupt legitimate system management tools if not carefully configured. Incorrect permission changes could also cause issues. The roll back steps involve restoring the original firewall rules or WMI permissions.
- Roll back: Remove the created firewall rule using `netsh advfirewall firewall delete rule name=”Block WMI Inbound”`. Restore original WMI permissions if modified directly.
8. References and Resources
- Vendor advisory or bulletin: https://msdn.microsoft.com/en-us/library/cc280268
- NVD or CVE entry: Not applicable – this is an information disclosure issue, not a specific vulnerability with a CVE.
- Product or platform documentation relevant to the fix: https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/querying-the-status-of-optional-features