How to remediate – Modbus/TCP Coil Access

1. Introduction

The Modbus/TCP Coil Access vulnerability allows reading binary output settings, known as coils, from devices using the Modbus protocol. This affects systems that use SCADA and DCS field devices like PLCs, RTUs, and IEDs. Successful exploitation could allow an attacker to profile a system and identify registers for further manipulation. A compromise may impact confidentiality through information disclosure, integrity via potential alteration of actuators, and availability if critical settings are misconfigured.

2. Technical Explanation

The Modbus protocol uses function code 1 (Read Coils) to access coil data on a slave device. This functionality is often exposed without sufficient authentication or restriction. An attacker can use this to read the state of coils, which represent actuator settings and other binary outputs. Knowing these states helps them understand the system’s operation and identify potential targets for write operations.

• Root cause: Lack of access controls on Modbus TCP port 502 allows unrestricted reading of coil data.
• Exploit mechanism: An attacker sends a Modbus request using function code 1 to read coils from the target device. The response reveals the current state of those coils. For example, an attacker could use `modpoll` to query coils on a PLC.
• Scope: Affected devices include industrial control systems (ICS) utilising Modbus/TCP, specifically PLCs, RTUs and IEDs.

3. Detection and Assessment

Confirming vulnerability involves checking for open port 502 and identifying Modbus devices on the network. A thorough assessment requires analysing coil data to understand its meaning.

• Quick checks: Use `nmap` to scan for port 502. For example, `nmap -p 502 `.
• Scanning: Nessus plugin ID 16897 can identify Modbus devices and check for coil access vulnerabilities. This is an example only; results may vary depending on configuration.
• Logs and evidence: Check firewall logs for connections to TCP port 502 from unknown sources. Look for unusual patterns of requests or responses related to function code 1.

nmap -p 502 

4. Solution / Remediation Steps

Restricting access to the Modbus port is the primary mitigation. Implement network segmentation and authentication where possible.

4.1 Preparation

• A change window may be required depending on system criticality and impact. Approval from the operations team is recommended.

4.2 Implementation

1. Step 1: Configure your firewall to allow connections to TCP port 502 only from authorized Modbus clients.
2. Step 2: If possible, enable authentication on the Modbus device itself.
3. Step 3: Review and update network segmentation rules to isolate critical ICS networks.

4.3 Config or Code Example

Before

# Allow all traffic on port 502 (example firewall rule)
iptables -A INPUT -p tcp --dport 502 -j ACCEPT

After

# Allow only specific IP addresses to access port 502 (example firewall rule)
iptables -A INPUT -s /32 -p tcp --dport 502 -j ACCEPT
iptables -A INPUT -p tcp --dport 502 -j DROP

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege access reduces the impact if an attacker gains control of a Modbus client.
• Practice 2: Network segmentation isolates critical ICS networks, limiting the spread of attacks.

4.5 Automation (Optional)

# Example Ansible playbook to restrict port 502 access
- name: Restrict Modbus TCP Access
  hosts: firewalls
  tasks:
    - iptables:
        chain: INPUT
        protocol: tcp
        destination_port: 502
        jump: DROP
    - iptables:
        chain: INPUT
        protocol: tcp
        destination_port: 502
        source: /32
        jump: ACCEPT

5. Verification / Validation

Confirm the fix by checking firewall rules and attempting to connect from an unauthorized host.

• Post-fix check: Use `iptables -L INPUT` to verify that only authorized IPs are allowed access to port 502.
• Re-test: Attempt to connect to port 502 from a non-authorized IP address; the connection should be blocked.
• Smoke test: Verify that authorized Modbus clients can still communicate with devices on port 502.
• Monitoring: Monitor firewall logs for dropped connections to port 502 from unexpected sources as an example alert.

iptables -L INPUT

6. Preventive Measures and Monitoring

Regular security assessments and baseline configurations are important.

• Baselines: Update your network security baseline to include restrictions on Modbus TCP access, for example using a CIS control.
• Pipelines: Include checks in CI/CD pipelines to ensure that firewall rules are correctly configured during deployment.
• Asset and patch process: Implement a regular review cycle for ICS assets and configurations to identify potential vulnerabilities.

7. Risks, Side Effects, and Roll Back

Incorrectly configuring the firewall could disrupt legitimate Modbus communication.

• Risk or side effect 2: Incorrect rule order may allow unintended access. Mitigation: Review and validate all rules carefully.
• Roll back: Restore the original firewall configuration or remove the newly added rules.

8. References and Resources

Links to relevant resources.

• Vendor advisory or bulletin: http://www.modbus.org/
• NVD or CVE entry: No specific CVE is associated with this general vulnerability, but searching for Modbus vulnerabilities on the NVD website may provide further information.
• Product or platform documentation relevant to the fix: Refer to your firewall vendor’s documentation for instructions on configuring access control rules.