How to remediate – SNMP Query Routing Information Disclosure

1. Introduction

SNMP Query Routing Information Disclosure allows an attacker to obtain a list of IP routes on a remote host. This information can be used to map out the network, potentially revealing sensitive internal addresses and aiding in further attacks. Systems running SNMP are usually affected, including routers, switches, servers, and network devices. A successful exploit could lead to loss of confidentiality regarding network topology.

2. Technical Explanation

The vulnerability occurs because the Simple Network Management Protocol (SNMP) service allows unauthenticated queries for routing information via Object Identifier (OID) 1.3.6.1.2.1.4.21. An attacker can send a request to this OID and receive a response containing the IP routing table. Preconditions include having network access to the target system on UDP port 161, where SNMP typically runs.

• Root cause: The SNMP service does not require authentication for reading routing information by default.
• Exploit mechanism: An attacker uses a tool like snmpwalk or similar to query the target host with OID 1.3.6.1.2.1.4.21 and retrieves the IP route table. For example, `snmpwalk -v 2c -c public .1.3.6.1.2.1.4.21`.
• Scope: Affected platforms include devices running SNMP versions 1, 2c, and 3 with default or weak community strings.

3. Detection and Assessment

You can confirm a system is vulnerable by checking if the SNMP service is enabled and accessible. A thorough method involves attempting to retrieve routing information using an SNMP query tool.

• Quick checks: Use `systemctl status snmpd` (on systems using systemd) or check for listening UDP ports on port 161 with `netstat -tulnp | grep :161`.
• Scanning: Nessus plugin ID 32849 can detect this vulnerability. OpenVAS also has relevant checks, but results may vary.
• Logs and evidence: Check system logs for SNMP requests originating from unexpected sources. Look for activity on UDP port 161 in firewall logs.

snmpwalk -v 2c -c public  .1.3.6.1.2.1.4.21

4. Solution / Remediation Steps

Disable the SNMP service if it is not required, or restrict access to trusted sources only. These steps are small and can be rolled back easily.

4.1 Preparation

• Ensure you have documented the current SNMP configuration in case of rollback. A roll back plan is to restore the snapshot or restart the stopped service.
• Change windows may be needed for production systems, and approval from network owners should be sought.

4.2 Implementation

1. Step 1: Stop the SNMP service using `systemctl stop snmpd`.
2. Step 2: Disable the SNMP service to prevent automatic startup with `systemctl disable snmpd`.
3. Step 3: If you need to keep SNMP enabled, configure access control lists (ACLs) on your firewall to only allow connections from trusted IP addresses.

4.3 Config or Code Example

Before

# /etc/snmp/snmpd.conf
acl_access community public any any

After

# /etc/snmp/snmpd.conf
# Remove or comment out the above line, or restrict access to specific IPs
# acl_access community public 192.168.1.0/24 any

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege is important, as limiting access reduces the impact of exploitation. Safe defaults mean disabling unnecessary services by default. Input validation could be used if SNMP must accept external input.

• Practice 1: Implement least privilege to restrict access to sensitive network information.
• Practice 2: Disable unused services like SNMP to reduce the attack surface.

4.5 Automation (Optional)

#!/bin/bash
# Stop and disable SNMP service on Debian/Ubuntu systems
systemctl stop snmpd &>/dev/null
systemctl disable snmpd &>/dev/null
echo "SNMP service stopped and disabled."

5. Verification / Validation

Confirm the fix by checking that the SNMP service is no longer running or accessible from untrusted sources. A negative test involves attempting to retrieve routing information again.

• Post-fix check: Run `systemctl status snmpd` and confirm it shows “inactive (dead)”.
• Re-test: Run `snmpwalk -v 2c -c public .1.3.6.1.2.1.4.21`. The command should timeout or return no results.
• Smoke test: Verify other network services (e.g., SSH, HTTP) are still functioning as expected.
• Monitoring: Monitor firewall logs for any unexpected SNMP traffic on port 161.

systemctl status snmpd

6. Preventive Measures and Monitoring

Update security baselines to include disabling unnecessary services like SNMP. Implement checks in CI/CD pipelines to ensure new systems are configured securely, for example using configuration management tools. A sensible patch or config review cycle of monthly is recommended.

• Baselines: Update your security baseline to require disabling SNMP unless specifically needed and properly secured.
• Pipelines: Add checks in CI/CD pipelines to ensure SNMP is disabled by default on new systems.
• Asset and patch process: Review system configurations regularly, at least monthly, to identify and remediate any unnecessary services or insecure settings.

7. Risks, Side Effects, and Roll Back

Disabling SNMP may impact network monitoring tools that rely on it. Ensure these are aware of the change. Rolling back involves re-enabling the service with `systemctl start snmpd` and `systemctl enable snmpd`.

• Roll back:
  1. Step 1: Start the SNMP service using `systemctl start snmpd`.
  2. Step 2: Enable the SNMP service to start automatically with `systemctl enable snmpd`.

8. References and Resources

• Vendor advisory or bulletin: [https://www.kb.cert.org/vuls/id/836059](https://www.kb.cert.org/vuls/id/836059)
• NVD or CVE entry: [https://nvd.nist.gov/vuln/detail