How to remediate – Emerson Network Power Avocent MergePoint Unity KVM Switch Dete…

1. Introduction

The Emerson Network Power Avocent MergePoint Unity KVM switch is vulnerable to information disclosure. This allows an attacker to read the model number of the device, potentially aiding reconnaissance efforts. Systems affected are typically those using Avocent MergePoint Unity KVM over IP switches for server and device control. A successful exploit could lead to a low impact on confidentiality, with no direct impact on integrity or availability.

2. Technical Explanation

The vulnerability allows reading the model number of the Emerson Network Power Avocent MergePoint Unity KVM over IP switch via SNMP or through the web interface. An attacker can query the device using standard SNMP tools, or simply view information displayed in the web UI. No authentication is required to read this information.

• Root cause: The model number is exposed without proper access controls.
• Exploit mechanism: An attacker sends an SNMP request to the switch and retrieves the system description which contains the model number, or views the web interface.
• Scope: Affected products are Emerson Network Power Avocent MergePoint Unity KVM over IP switches.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking the device’s version information and whether the model number is publicly accessible.

• Quick checks: Access the web interface of the KVM switch and check the ‘About’ or ‘System Information’ page for the model number.
• Scanning: Nessus plugin ID 70698c1f can be used to detect this vulnerability. This is an example only, other scanners may also provide detection capabilities.
• Logs and evidence: No specific logs are generated related to this information disclosure.

snmpwalk -v 2c -c public <switch_ip> system

4. Solution / Remediation Steps

There is no patch available for this vulnerability as it relates to information disclosure of the model number. Mitigation focuses on network segmentation and limiting access to the KVM switch’s management interface.

4.1 Preparation

• Backups are not required for this mitigation. Stop services only if necessary for network changes.
• Dependencies: Network connectivity to the KVM switch is needed. Roll back plan: Restore original network configuration if any issues arise.
• Change window needs: Standard change control procedures should be followed.

4.2 Implementation

1. Step 1: Implement network segmentation to isolate the KVM switch’s management interface from untrusted networks.
2. Step 2: Restrict access to the KVM switch’s web and SNMP interfaces using firewall rules, allowing only authorized IP addresses.

4.3 Config or Code Example

Before

# No firewall rules in place, allowing access from all networks

After

# Firewall rule example (iptables) - replace with your specific network configuration
iptables -A INPUT -s <authorized_ip> -d <switch_ip> -p tcp --dport 80 ACCEPT
iptables -A INPUT -s <authorized_ip> -d <switch_ip> -p udp --dport 161 ACCEPT
iptables -A INPUT -d <switch_ip> -j DROP

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact of information disclosure, while network segmentation limits access to sensitive devices.

• Practice 1: Implement least privilege principles by granting only necessary permissions to users and services accessing the KVM switch.
• Practice 2: Network segmentation isolates critical systems like KVM switches from untrusted networks, reducing exposure.

4.5 Automation (Optional)

Automation is not directly applicable for this vulnerability as it relates to network configuration and access control. However, infrastructure-as-code tools can be used to manage firewall rules consistently.

# Example Ansible playbook snippet - replace with your specific environment
- name: Configure firewall rule for KVM switch
  firewalld:
    zone: public
    rich_rule: 'rule family="ipv4" source address="<authorized_ip>" destination address="<switch_ip>" port protocol=tcp port=80 accept'

5. Verification / Validation

Confirm the fix by verifying that access to the KVM switch’s management interface is restricted to authorized IP addresses and SNMP queries are blocked from unauthorized sources.

• Post-fix check: Attempt to access the web interface or send an SNMP query from an unauthorized IP address. Access should be denied.
• Re-test: Repeat the initial detection method (web interface access, snmpwalk) from an unauthorized IP address. The model number should not be accessible.
• Smoke test: Verify authorized users can still access and manage the KVM switch without interruption.
• Monitoring: Monitor firewall logs for blocked connections to the KVM switch’s management ports (80, 161). This is an example only.

# Example command to test SNMP access from unauthorized IP
snmpwalk -v 2c -c public <switch_ip> system # Should timeout or return no response

6. Preventive Measures and Monitoring

Update security baselines to include network segmentation requirements for critical infrastructure devices like KVM switches. Implement regular vulnerability scanning and penetration testing to identify potential weaknesses.

• Baselines: Update a security baseline or policy to require network segmentation for all KVM switches.
• Asset and patch process: Review the configuration of critical infrastructure devices regularly, including KVM switches.

7. Risks, Side Effects, and Roll Back

Implementing network segmentation or restricting access could potentially disrupt legitimate management traffic if not configured correctly. Ensure authorized IP addresses are properly defined.

• Roll back: Remove the newly added firewall rules to restore access from all networks.

8. References and Resources

• Vendor advisory or bulletin: http://www.nessus.org/u?70698c1f
• NVD or CVE entry: No specific CVE is associated with this information disclosure.