How to remediate – Modbus/TCP Discrete Input Access

1. Introduction

The Modbus/TCP Discrete Input Access vulnerability allows reading binary data, such as switch states and sensor readings, from Modicon field devices like PLCs. This can help an attacker understand the system’s operation and potentially identify targets for further attacks. Systems commonly affected are those using SCADA or DCS systems with exposed Modbus ports. A successful exploit could compromise confidentiality by revealing process information.

2. Technical Explanation

Modbus/TCP uses function code 2 to read discrete inputs from a slave device. If access isn’t properly restricted, anyone on the network can request this data. An attacker needs network connectivity to TCP port 502 on the target Modbus device. A simple example is using a Modbus client tool to query for the status of various input registers.

• Root cause: Unrestricted access to Modbus/TCP discrete inputs via function code 2.
• Exploit mechanism: An attacker sends a Modbus request (function code 2) to read discrete inputs from the target device, then analyses the returned data. For example, using `modpoll -t slave -r 0-15` to read registers 0 through 15.
• Scope: Modicon PLCs, RTUs and IEDs running Modbus/TCP are affected. Specific versions aren’t known to be more vulnerable than others; the issue is related to configuration.

3. Detection and Assessment

You can confirm vulnerability by checking for an open port 502 and then attempting a read request. A thorough method involves using a Modbus scanner tool to identify accessible discrete inputs.

• Quick checks: Use `netstat -an | grep :502` on Linux or `netstat -ano | findstr :502` on Windows to check if port 502 is listening.
• Scanning: Nessus plugin ID 93861 can identify Modbus/TCP discrete input access. This is an example only, and may require updates.
• Logs and evidence: Check firewall logs for connections to TCP port 502 from unknown sources. Look for unusual patterns of requests.

netstat -an | grep :502

4. Solution / Remediation Steps

Restrict access to the Modbus port to authorized clients only. This limits the potential attack surface and prevents unauthorized data collection.

4.1 Preparation

• Dependencies: Ensure you have access to the firewall or network device configuration. Roll back plan: Revert the firewall rule change.
• Change window: A standard maintenance window is recommended. Approval from a system owner may be needed.

4.2 Implementation

1. Step 1: Create a firewall rule to allow traffic on TCP port 502 only from trusted IP addresses or networks.
2. Step 2: Deny all other inbound connections to TCP port 502.
3. Step 3: Test the new rules by attempting a connection from an untrusted source.

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 trusted IP address X.X.X.X to connect on port 502 (example iptables)
iptables -A INPUT -s X.X.X.X -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 key here, limiting access only to necessary clients. Network segmentation can also isolate Modbus devices from untrusted networks.

• Practice 1: Least privilege reduces the impact if an attacker gains access.
• Practice 2: Network segmentation limits the blast radius of a successful attack.

4.5 Automation (Optional)

If using infrastructure-as-code, you can automate firewall rule updates to enforce restricted Modbus access.

# Example Ansible snippet
- name: Allow Modbus from trusted network
  firewalld:
    port: 502/tcp
    source: X.X.X.X/24
    permanent: true
    state: enabled
- name: Deny all other Modbus traffic
  firewalld:
    port: 502/tcp
    permanent: true
    state: disabled

5. Verification / Validation

Confirm the fix by attempting a connection from an untrusted source and verifying it is blocked. Then, re-scan using the earlier detection method to ensure no accessible inputs are found.

• Post-fix check: `netstat -an | grep :502` should show only connections from trusted sources.
• Re-test: Run Nessus plugin ID 93861 again; it should not report any vulnerabilities.
• Smoke test: Verify authorized Modbus clients can still connect and read data.
• Monitoring: Check firewall logs for blocked connection attempts to port 502 from unknown IPs.

netstat -an | grep :502

6. Preventive Measures and Monitoring

Update security baselines to include restricted Modbus access as a standard configuration setting. Implement regular vulnerability scanning in CI/CD pipelines.

• Baselines: Update your network device or firewall baseline to enforce the least privilege rule for port 502.
• Pipelines: Add a vulnerability scan step to your deployment pipeline that checks for open Modbus ports.
• Asset and patch process: Review firewall rules quarterly as part of a regular security review.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Blocking legitimate clients – carefully test allowed IP addresses.
• Risk or side effect 2: Service disruption if firewall is misconfigured – have a rollback plan ready.
• Roll back: Remove the new firewall rules and restore the previous configuration.

8. References and Resources

• Vendor advisory or bulletin: http://www.modbus.org