How to remediate – WMI Antivirus Enumeration

1. Introduction

The WMI Antivirus Enumeration vulnerability allows an attacker with valid credentials to obtain a list of antivirus software installed on a remote Windows host. This information can be used to map a network and identify systems that may be vulnerable to specific threats, or to avoid detection during an attack. Affected systems are typically older desktop operating systems. A successful exploit could lead to reduced confidentiality as system protection details become known.

2. Technical Explanation

This vulnerability occurs because Windows Management Instrumentation (WMI) allows enumeration of installed antivirus products through the ‘rootsecuritycenter’ and ‘rootsecuritycenter2’ namespaces. An attacker connecting with appropriate credentials can query these namespaces to retrieve this information. This plugin only works on older desktop operating systems as these namespaces are not present in newer versions.

• Root cause: The WMI interfaces expose antivirus software details without sufficient access control checks.
• Exploit mechanism: An attacker uses a scripting language, such as PowerShell, to connect to the target system via WMI and query the ‘rootsecuritycenter’ or ‘rootsecuritycenter2’ namespace for installed antivirus products. For example, using `Get-WmiObject -Class Win32_AntivirusProtection`.
• Scope: Windows XP, Vista, and Windows 7 desktop operating systems are affected.

3. Detection and Assessment

You can confirm vulnerability by checking for the presence of the relevant WMI namespaces on a target system. A thorough method involves attempting to enumerate antivirus software using WMI.

• Quick checks: Use PowerShell to check if the ‘rootsecuritycenter’ namespace exists: `Get-WmiObject -Namespace rootsecuritycenter`. If it returns objects, the namespace is present.
• Scanning: Nessus plugin ID 10384 can detect this vulnerability. This is an example only and may require updating.
• Logs and evidence: No specific logs directly indicate this enumeration; however, successful WMI queries might be logged in Windows Event Logs (Application and System), depending on auditing configuration.

Get-WmiObject -Namespace rootsecuritycenter | fl Name, PathName

4. Solution / Remediation Steps

Due to the age of affected systems, upgrading the operating system is the preferred solution. If this isn’t possible, restricting access to WMI can reduce risk.

4.1 Preparation

• A change window may be required, depending on your organisation’s policies. Approval from a senior IT administrator is recommended.

4.2 Implementation

1. Step 1: Restrict access to the ‘rootsecuritycenter’ and ‘rootsecuritycenter2’ namespaces using Windows Firewall with Advanced Security.
2. Step 2: Create an inbound rule blocking all connections except those from trusted sources.
3. Step 3: Verify the new firewall rules are active and functioning as expected.

4.3 Config or Code Example

Before

No specific firewall rules are in place for WMI namespaces.

After

New inbound firewall rule blocking connections to rootsecuritycenter and rootsecuritycenter2 except from trusted sources. (Example: Allow only connections from the local machine)

4.4 Security Practices Relevant to This Vulnerability

Least privilege is a key practice for mitigating this vulnerability. Limiting access to WMI reduces the potential impact if an attacker gains credentials. Input validation, while not directly applicable here, is important for preventing other types of attacks.

• Practice 1: Least privilege – restrict user accounts and service accounts to only the permissions they need.
• Practice 2: Patch cadence – regularly update systems with security patches to address known vulnerabilities.

4.5 Automation (Optional)

PowerShell can be used to automate firewall rule creation at scale, but requires careful testing.

# Example PowerShell script - use with caution!
New-NetFirewallRule -DisplayName "Block WMI Antivirus Enumeration" -Direction Inbound -Namespace rootsecuritycenter -Action Block
New-NetFirewallRule -DisplayName "Block WMI Antivirus Enumeration 2" -Direction Inbound -Namespace rootsecuritycenter2 -Action Block

5. Verification / Validation

• Post-fix check: Run `Get-WmiObject -Namespace rootsecuritycenter`. It should return no objects or a connection error due to the blocked rule.
• Re-test: Re-run the initial PowerShell command (`Get-WmiObject -Namespace rootsecuritycenter`) from an untrusted host; it should be blocked by the firewall.
• Smoke test: Ensure any applications relying on WMI for legitimate purposes still function correctly.
• Monitoring: Monitor Windows Event Logs (Security) for failed WMI connection attempts to ‘rootsecuritycenter’ and ‘rootsecuritycenter2’.

Get-WmiObject -Namespace rootsecuritycenter | fl Name, PathName # Should return no results

6. Preventive Measures and Monitoring

Regular security baselines should include restrictions on WMI access. Consider adding checks to your CI/CD pipeline to ensure these settings are maintained.

• Baselines: Update a security baseline or Group Policy Object (GPO) to restrict access to the ‘rootsecuritycenter’ and ‘rootsecuritycenter2’ namespaces.
• Pipelines: Add checks in your CI/CD pipeline to verify that firewall rules are correctly configured on new systems.
• Asset and patch process: A regular review of system configurations can identify misconfigurations like open WMI ports.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Blocking WMI could break legitimate functionality; test thoroughly.
• Risk or side effect 2: Incorrect firewall rules can cause unexpected service disruptions.
• Roll back: Remove the newly created firewall rules to restore default WMI access. Restore from snapshot if necessary.

8. References and Resources

• Vendor advisory or bulletin: Nessus Plugin 10384
• NVD or CVE entry: No specific CVE is associated with this enumeration, but it relates to the overall WMI security concerns.
• Product or platform documentation relevant to the fix: Windows Firewall Documentation