How to remediate – SNMP Query Running Process List Disclosure

1. Introduction

SNMP Query Running Process List Disclosure allows an attacker to obtain a list of processes running on a remote host. This information can help them understand the target system’s functionality and identify potential vulnerabilities. Systems running SNMP services are usually affected, including network devices like routers, switches, and servers with SNMP agents enabled. A successful exploit could lead to increased reconnaissance and potentially compromise confidentiality.

2. Technical Explanation

The vulnerability occurs because the SNMP service allows unauthenticated queries for process information using Object Identifier (OID) 1.3.6.1.2.1.25.4.2.1.2. An attacker can send a simple SNMP request to retrieve this list. The main precondition is that the SNMP service must be enabled and accessible from the network.

• Root cause: The SNMP agent does not restrict access to process information, allowing anyone who can reach the port to query it.
• Exploit mechanism: An attacker uses an SNMP client tool (like snmpwalk) to send a GET request for OID 1.3.6.1.2.1.25.4.2.1.2. For example, `snmpwalk -v2c -c public .1.3.6.1.2.1.25.4.2.1.2`.
• Scope: Affected platforms include devices running SNMP agents on various operating systems like Linux, Windows Server and network hardware from vendors such as Cisco, Juniper, and HP.

3. Detection and Assessment

You can confirm vulnerability by checking if the SNMP service is enabled and accessible. A thorough method involves attempting to retrieve the process list directly.

• Quick checks: Use `systemctl status snmpd` on Linux or check services in Windows Services Manager for “SNMP Service”.
• Scanning: Nessus plugin ID 10823 can detect this vulnerability, but results should be verified.
• Logs and evidence: Check firewall logs for UDP traffic to port 161 from unexpected sources. SNMP agent logs may show query activity.

snmpwalk -v2c -c public  .1.3.6.1.2.1.25.4.2.1.2

4. Solution / Remediation Steps

The best solution is to disable the SNMP service if it’s not needed. If you must use SNMP, restrict access using appropriate security measures.

4.1 Preparation

• A change window may be needed, depending on your organisation’s policies. Approval from a system owner might be necessary.

4.2 Implementation

1. Step 1: Stop the SNMP service using `systemctl stop snmpd` (Linux) or via Windows Services Manager.
2. Step 2: Disable the service to prevent automatic restarts with `systemctl disable snmpd` (Linux).
3. Step 3: If you need to keep SNMP enabled, configure access control lists (ACLs) on your firewall to restrict UDP port 161 traffic to trusted sources only.

4.3 Config or Code Example

Before

# snmpd.conf (example)
rocommunity public 192.168.1.0/24

After

# snmpd.conf (example - disabled or restricted access)
#rocommunity public 192.168.1.0/24  (commented out to disable community string)
#Or, restrict with ACLs on the firewall

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of issue. Least privilege is important to limit damage from exploitation. Network segmentation reduces exposure.

• Practice 1: Implement least privilege by only granting necessary access rights to SNMP data.
• Practice 2: Use network segmentation to isolate sensitive systems and restrict access to the SNMP service.

4.5 Automation (Optional)

# Example Ansible playbook snippet to disable SNMP service on Linux systems
- name: Disable SNMP service
  service:
    name: snmpd
    state: stopped
    enabled: false

5. Verification / Validation

Confirm the fix by checking that you can no longer retrieve the process list via SNMP. A negative test involves attempting to query the OID from an untrusted host.

• Post-fix check: Run `snmpwalk -v2c -c public .1.3.6.1.2.1.25.4.2.1.2` and verify it returns “No Such Name” or a similar error.
• Re-test: Re-run the initial `snmpwalk` command to confirm no process list is returned.
• Smoke test: Verify any dependent monitoring systems still receive expected data (if SNMP remains enabled with restricted access).
• Monitoring: Monitor firewall logs for failed SNMP queries from untrusted sources as an example alert.

snmpwalk -v2c -c public  .1.3.6.1.2.1.25.4.2.1.2  (Expected output: No Such Name)

6. Preventive Measures and Monitoring

Update security baselines to include SNMP service disabling or strict access control. Consider adding checks in your CI/CD pipeline to enforce these settings.

• Baselines: Update a system hardening baseline (for example, CIS benchmark) to require SNMP service disabling or restricted access.
• Pipelines: Add configuration validation checks during deployment to ensure the SNMP service is disabled or properly configured with ACLs.
• Asset and patch process: Review configurations regularly for unnecessary services like SNMP.

7. Risks, Side Effects, and Roll Back

Disabling SNMP may impact existing monitoring systems that rely on it. Ensure you have a roll back plan in place.

• Roll back: Step 1: Re-enable the SNMP service using `systemctl start snmpd` (Linux) or via Windows Services Manager. Step 2: Restore the original SNMP configuration file if necessary.

8. References and Resources

• Vendor advisory or bulletin: Check your network device vendor’s security website for specific SNMP vulnerabilities.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2017-5638