How to remediate – Modicon Modbus/TCP Programming Function Code Access

1. Introduction

The Modicon Modbus/TCP Programming Function Code Access vulnerability affects programmable logic controllers (PLCs) using the Modbus TCP protocol on port 502, specifically allowing access via function code 126. This allows an attacker with network access to reprogram PLC logic, potentially disrupting or damaging physical processes controlled by the PLC. Systems commonly affected include industrial control systems and SCADA environments utilising Modicon PLCs. A successful exploit could compromise the confidentiality, integrity, and availability of the controlled process.

2. Technical Explanation

The vulnerability arises from unrestricted access to the Modbus TCP interface on port 502, enabling proprietary function code 126 for programming functions. An attacker can send crafted requests to this port to modify PLC program logic without authentication if network access is granted. There is no known CVE associated with this specific issue, but it relates to insecure-by-default configurations common in industrial control systems. For example, an attacker could upload malicious code that alters the behaviour of a manufacturing process or safety system.

• Root cause: The Modbus TCP interface allows programming function code 126 access without sufficient authentication or authorisation checks.
• Exploit mechanism: An attacker sends a crafted Modbus TCP request using function code 126 to upload and execute malicious PLC program logic. A simple example payload would involve sending a modified ladder diagram file via the TCP connection.
• Scope: Affected platforms are those running Modicon PLCs with an exposed Modbus TCP interface on port 502, typically older models or systems without network segmentation.

3. Detection and Assessment

Confirming vulnerability requires checking for open port 502 and the responsiveness of function code 126. A quick check involves a simple port scan; thorough assessment needs Modbus protocol analysis.

• Quick checks: Use `nmap` to check if port 502 is open on the PLC’s IP address.
• Scanning: Nessus plugin ID 139847 may detect this issue, but results should be verified manually.
• Logs and evidence: Examine firewall logs for connections to TCP port 502 from unexpected sources. Look for unusual Modbus traffic patterns.

nmap -p 502 

4. Solution / Remediation Steps

Restrict incoming traffic on port 502 to only authorized Modbus TCP clients. This limits the attack surface and prevents unauthorized modification of PLC logic.

4.1 Preparation

• Ensure you have access to restore the previous configuration if needed. A roll back plan involves restoring from the pre-change backup.
• A change window may be required depending on the criticality of the controlled process and approval should be sought from operations teams.

4.2 Implementation

1. Step 1: Configure the firewall to allow incoming traffic on TCP port 502 only from trusted Modbus client IP addresses or networks.
2. Step 2: Verify that all other incoming connections to port 502 are blocked.
3. Step 3: Test connectivity from authorized clients to ensure functionality is not impacted.

4.3 Config or Code Example

Before

# Firewall rule allowing all traffic on port 502
iptables -A INPUT -p tcp --dport 502 -j ACCEPT

After

# Firewall rule allowing only trusted IP address to port 502
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 directly address this vulnerability type. Least privilege limits the impact of exploitation, while network segmentation isolates critical systems.

• Practice 1: Implement least privilege access controls for all PLC components and networks. This reduces the potential damage if an attacker gains control.
• Practice 2: Network segmentation to isolate PLCs from untrusted networks. This limits the attack surface and prevents lateral movement.

4.5 Automation (Optional)

If using infrastructure-as-code, firewall rules can be automated.

# Example Ansible playbook snippet to configure firewall rule
- name: Allow Modbus TCP traffic from trusted IP
  iptables:
    chain: INPUT
    protocol: tcp
    destination_port: 502
    source: /32
    jump: ACCEPT
- name: Drop all other Modbus TCP traffic
  iptables:
    chain: INPUT
    protocol: tcp
    destination_port: 502
    jump: DROP

5. Verification / Validation

Confirm the fix by verifying that only authorized clients can connect to port 502 and that unauthorized attempts are blocked. A service smoke test ensures functionality remains intact.

• Post-fix check: Use `nmap` again from an untrusted IP address; it should not show port 502 open.
• Re-test: Re-run the initial `nmap` scan to confirm that only authorized clients can connect to port 502.
• Smoke test: Verify that authorized Modbus clients can still read and write data to the PLC as expected.
• Monitoring: Monitor firewall logs for any blocked connections to TCP port 502 from unexpected sources.

nmap -p 502  # Should show "filtered" or no response

6. Preventive Measures and Monitoring

Regular security baselines and patch management are essential to prevent this issue. Consider adding checks in CI/CD pipelines for insecure configurations.

• Baselines: Update a security baseline (for example, CIS control 10) to include restrictions on Modbus TCP access.
• Pipelines: Add static analysis or configuration scanning tools to your CI/CD pipeline to detect open port 502 and insecure configurations.
• Asset and patch process: Implement a regular review cycle for PLC configurations and firmware updates.

7. Risks, Side Effects, and Roll Back

Blocking legitimate traffic is the primary risk; careful IP address management is crucial. Roll back involves restoring the original firewall rules or PLC configuration.

• Risk or side effect 2: Service interruption if the PLC cannot be reached by authorized clients. Mitigation: Have a documented roll back plan and access to restore the previous configuration.
• Roll back: Step 1: Restore the original firewall rules. Step 2: Verify connectivity from all authorized Modbus clients.

8. References and Resources

• Vendor advisory or bulletin: [https://www.se.com/ww/en/work/support/](https://www.se.com/ww/en/work/support/) (Search for Modicon PLC security advisories)
• NVD or CVE entry: No specific CVE exists for this exact issue, but search NVD for Modbus vulnerabilities.