1. Introduction
The Modbus/TCP Report Slave ID vulnerability allows an attacker to read a device’s Slave ID using function code 17. This can reveal information about your industrial control systems, potentially aiding reconnaissance and further attacks. Systems commonly affected are those running Modbus TCP, often found in manufacturing, energy, and building automation environments. A successful exploit could lead to the disclosure of system details, impacting confidentiality.
2. Technical Explanation
The vulnerability occurs because devices respond to unsolicited Modbus Report Slave ID requests (function code 17). An attacker can send this request over TCP port 502 and receive a response containing the device’s Slave ID. There is no known CVE associated with this specific issue, but it represents a common misconfiguration in Modbus deployments. For example, an attacker could use a simple Python script to query a vulnerable PLC for its Slave ID.
- Root cause: The device does not restrict access to the Report Slave ID function code 17.
- Exploit mechanism: An attacker sends a Modbus TCP request with function code 17 to the target device on port 502 and receives the response containing the Slave ID. Example payload (hex): 00 03 00 00 00 17.
- Scope: Devices running Modbus TCP, including PLCs, HMIs, and SCADA systems. Affected versions depend on the manufacturer’s implementation.
3. Detection and Assessment
You can confirm vulnerability by attempting to read the Slave ID from a device. A quick check is to see if port 502 is open. A thorough method involves sending a Modbus Report Slave ID request and analysing the response.
- Quick checks: Use `nmap` to scan for open TCP port 502:
nmap -p 502 - Scanning: Nessus plugin ID 16789 can detect this vulnerability. Other Modbus scanners may also identify it.
- Logs and evidence: Check firewall logs for connections to TCP port 502 from unknown sources. Look for unusual outbound requests on that port.
nmap -p 502 4. Solution / Remediation Steps
Restrict access to the Modbus port (TCP/502) to only authorized clients. This prevents unauthorized devices from querying device information.
4.1 Preparation
- Ensure you have access to the firewall configuration and understand its rules. A roll back plan involves restoring the original firewall snapshot.
- A change window may be needed depending on your environment. Approval from a system owner might be necessary.
4.2 Implementation
- Step 1: Create a firewall rule to allow traffic only from known Modbus clients to TCP port 502.
- Step 2: Deny all other inbound connections to TCP port 502.
- Step 3: Test connectivity from authorized clients to confirm the service still functions correctly.
4.3 Config or Code Example
Before
# Allow all inbound connections on port 502 (example iptables)
iptables -A INPUT -p tcp --dport 502 -j ACCEPT
After
# Allow only specific IP address to connect to port 502 (example iptables)
iptables -A INPUT -s -p tcp --dport 502 -j ACCEPT
iptables -A INPUT -p tcp --dport 502 -j DROP
4.4 Security Practices Relevant to This Vulnerability
Least privilege is crucial here, limiting access only to necessary clients. Network segmentation can also isolate Modbus devices from untrusted networks.
- Practice 1: Least privilege – restrict network access based on the principle of least privilege.
- Practice 2: Network segmentation – separate critical systems like industrial control systems into isolated network segments.
4.5 Automation (Optional)
If using a configuration management tool, you can automate firewall rule updates to enforce access restrictions.
# Example Ansible playbook snippet
- name: Restrict Modbus port 502 access
firewalld:
port: 502/tcp
permanent: true
state: enabled
source:
5. Verification / Validation
Confirm the fix by attempting to read the Slave ID from an unauthorized device. You should no longer receive a response. Verify authorized clients can still connect.
- Post-fix check: Use `nmap` or a Modbus client tool from an untrusted IP address. No response should be received on port 502.
- Re-test: Re-run the Nessus scan (plugin ID 16789). It should no longer report the vulnerability.
- Smoke test: Verify authorized clients can still read data from Modbus registers as expected.
- Monitoring: Monitor firewall logs for blocked connections to port 502 from unknown sources.
nmap -p 502 6. Preventive Measures and Monitoring
Update security baselines to include restrictions on Modbus access. Consider adding checks in your CI/CD pipeline to prevent insecure configurations.
- Baselines: Update firewall rulesets or CIS benchmarks to enforce least privilege for Modbus TCP.
- Pipelines: Implement Infrastructure as Code (IaC) scanning to detect open port 502 and overly permissive firewall rules.
7. Risks, Side Effects, and Roll Back
Incorrectly configured firewall rules could block legitimate Modbus traffic. The roll back steps involve restoring the original firewall configuration.
- Risk or side effect 2: Service disruption – ensure authorized clients are correctly identified and allowed through the firewall.
8. References and Resources
- Vendor advisory or bulletin: Check your PLC/SCADA vendor's security website for specific guidance on Modbus TCP configuration.
- NVD or CVE entry: No specific CVE is associated with this issue, but search for related Modbus vulnerabilities on the NVD website (https://nvd.nist.gov/).
- Product or platform documentation relevant to the fix: http://www.modbus.org/ provides detailed information on Modbus protocol and security considerations.