1. Introduction
SNMP Request Network Interfaces Enumeration allows an attacker to obtain a list of network interface cards on a remote host. This information can be used for reconnaissance, helping attackers map out a target network and identify potential vulnerabilities. Systems running the SNMP service are usually affected, including servers, routers, switches, and other networked devices. A successful exploit could lead to increased knowledge of the target system, potentially impacting confidentiality.
2. Technical Explanation
The vulnerability occurs because the SNMP service allows unauthenticated or weakly authenticated requests for network interface information. An attacker can send a request using the OID 1.3.6.1.2.1.2.1.0 to retrieve this data. The main precondition is that the SNMP service must be running and accessible on UDP port 161.
- Root cause: The SNMP service provides network interface information without sufficient access control.
- Exploit mechanism: An attacker sends an SNMP GET request to the target host using a tool like snmpwalk, specifying OID 1.3.6.1.2.1.2.1.0. This retrieves a list of interfaces. For example, `snmpwalk -v 2c -c public
1.3.6.1.2.1.2.1.0`. - Scope: Affected platforms include devices running SNMP services on various operating systems like Linux, Windows Server, and network hardware from vendors such as Cisco and Juniper.
3. Detection and Assessment
You can confirm a system is vulnerable by checking if the SNMP service is running and accessible. A thorough method involves attempting to retrieve interface information using an SNMP request.
- Quick checks: Use `systemctl status snmpd` (Linux) or check services.msc (Windows) to see if the SNMP service is active.
- Scanning: Nessus plugin ID 34871 can detect this vulnerability, but results should be verified manually.
- Logs and evidence: Check system logs for SNMP activity on UDP port 161. Event IDs will vary by operating system.
snmpwalk -v 2c -c public 1.3.6.1.2.1.2.1.0 4. Solution / Remediation Steps
The best way to fix this issue is to disable the SNMP service if it’s not needed, or restrict access using strong community strings and access control lists.
4.1 Preparation
- Ensure you have documented the current SNMP configuration for roll back purposes. A simple roll back plan is to restart the SNMP service with its original settings.
- Changes should be made during a scheduled maintenance window, and approved by the IT security team.
4.2 Implementation
- Step 1: Stop the SNMP service using `systemctl stop snmpd` (Linux) or via services.msc (Windows).
- Step 2: Disable the SNMP service from starting automatically using `systemctl disable snmpd` (Linux) or set Startup type to Disabled in services.msc (Windows).
- Step 3: If you need to keep the service running, configure strong community strings and access control lists to restrict access to trusted sources only.
4.3 Config or Code Example
Before
# snmpd.conf (example)
com2sec public default public
access read localhost
After
# snmpd.conf (example - disabling service)
# com2sec public default public
# access read localhost
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue. Least privilege limits the impact if exploited, and safe defaults reduce the attack surface by disabling unnecessary services.
- Practice 1: Implement least privilege principles, granting only necessary access to SNMP resources.
- Practice 2: Use strong community strings or switch to SNMPv3 for authentication and encryption.
4.5 Automation (Optional)
# PowerShell example to stop SNMP service on remote machines
Invoke-Command -ComputerName -ScriptBlock {
Stop-Service -Name "SNMP" -Force
Set-Service -Name "SNMP" -StartupType Disabled
}
5. Verification / Validation
Confirm the fix by checking that the SNMP service is no longer accessible or that interface information cannot be retrieved without valid credentials.
- Post-fix check: Run `systemctl status snmpd` (Linux) and verify it’s inactive, or check services.msc (Windows) to confirm the service is stopped.
- Re-test: Re-run `snmpwalk -v 2c -c public
1.3.6.1.2.1.2.1.0` and verify it fails with a timeout or authentication error. - Smoke test: Ensure other network services (e.g., SSH, HTTP) are still functioning as expected.
- Monitoring: Monitor system logs for failed SNMP requests on UDP port 161.
snmpwalk -v 2c -c public 1.3.6.1.2.1.2.1.0 (should timeout or fail) 6. Preventive Measures and Monitoring
Update security baselines to include disabling unnecessary services like SNMP, and add checks in deployment pipelines to prevent insecure configurations. For example, CIS control 5 addresses secure configuration of network devices.
- Baselines: Update your system baseline or group policy to disable the SNMP service by default.
- Pipelines: Include static analysis tools in CI/CD pipelines to detect weak community strings or open SNMP ports in infrastructure code.
- Asset and patch process: Review configurations regularly, at least quarterly, to ensure compliance with security standards.
7. Risks, Side Effects, and Roll Back
Disabling the SNMP service may impact network monitoring tools that rely on it. The roll back steps involve re-enabling the service with its original configuration.
- Risk or side effect 1: Network monitoring systems might lose connectivity if SNMP is disabled without alternatives.
- Risk or side effect 2: Some applications may depend on SNMP for specific functionality.
- Roll back: Step 1: Start the SNMP service using `systemctl start snmpd` (Linux) or via services.msc (Windows). Step 2: Re-enable automatic startup using `systemctl enable snmpd` (Linux) or set Startup type to Automatic in services.msc (Windows). Step 3: Restore the original SNMP configuration file if modified.
8. References and Resources
- Vendor advisory or bulletin: [https://support.microsoft.com/en-us/topic/ms08-014-security-update-for-simple-network-management-protocol-snmp-9e236f5a-c7b2-4d88-b4