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

1. Introduction

The Modicon Modbus/TCP UnityPro Programming Function Code Access vulnerability affects programmable logic controllers (PLCs) using Schneider Electric’s UnityPro software. A PLC’s Modbus TCP interface listening on port 502 allows access to function code 90, potentially enabling an attacker with network access to reprogram the PLC or compromise its integrity. This could lead to disruption of industrial processes and potential safety issues. The vulnerability impacts confidentiality, integrity, and availability of affected systems.

2. Technical Explanation

The Modicon PLC exposes a Modbus TCP interface on port 502 which allows access via the UnityPro function code 90. This function code is intended for legitimate programming and configuration but lacks sufficient access controls when exposed to untrusted networks. An attacker can send crafted requests to this port to modify PLC logic or extract sensitive data.

• Root cause: Insufficient restriction of incoming traffic on TCP port 502, allowing unauthorized access to the UnityPro function code 90.
• Exploit mechanism: An attacker sends Modbus TCP requests containing malicious commands via function code 90 to reprogram PLC logic or read internal data. For example, an attacker could alter control parameters causing a process shutdown.
• Scope: Schneider Electric Modicon PLCs running UnityPro software with the Modbus TCP interface enabled are affected. Specific versions were not provided in the context.

3. Detection and Assessment

Confirming vulnerability involves checking for an open port 502 and testing access to function code 90. A thorough assessment requires network traffic analysis.

• Quick checks: Use `netstat -an | grep :502` on the PLC or a network monitoring device to check if TCP port 502 is listening.
• Scanning: Nessus plugin ID 139784 may identify this vulnerability, but results should be verified manually.
• Logs and evidence: Examine PLC logs for Modbus TCP connections originating from unexpected IP addresses or unusual function code requests. Log file locations vary by PLC model.

netstat -an | grep :502

4. Solution / Remediation Steps

The primary solution is to restrict incoming traffic on port 502 to authorized Modbus TCP clients only.

4.1 Preparation

• Stopping services isn’t usually required, but ensure no active programming sessions are running during implementation. A roll back plan involves restoring the backed-up configuration.
• Changes should be approved by a senior automation engineer or security team member.

4.2 Implementation

1. Step 1: Configure the PLC’s firewall to allow Modbus TCP traffic only from trusted IP addresses or networks. This is typically done through UnityPro software or the PLC’s web interface.
2. Step 2: Verify that all other incoming connections on port 502 are blocked.
3. Step 3: Restart the PLC if required by the firewall configuration process.

4.3 Config or Code Example

Before

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

After

# Firewall rule allowing only trusted IP address X.X.X.X on port 502 (example)
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

Several security practices can help prevent this type of issue.

• Practice 1: Least privilege – restrict network access to only necessary devices and services, reducing the impact if a system is compromised.
• Practice 2: Network segmentation – isolate critical systems like PLCs on separate networks with strict firewall rules.

4.5 Automation (Optional)

If using configuration management tools, automate firewall rule updates to enforce port restrictions consistently across all PLCs.

# Example Ansible playbook snippet (example only - requires adaptation)
- name: Restrict Modbus TCP access
  iptables:
    chain: INPUT
    protocol: tcp
    destination_port: 502
    jump: DROP
    state: present

5. Verification / Validation

Confirm the fix by verifying that only authorized clients can connect to port 502 and execute UnityPro function code 90 requests.

• Post-fix check: Use `netstat -an | grep :502` again to confirm port 502 is still listening, but attempt a connection from an unauthorized IP address; the connection should be refused.
• Re-test: Repeat the initial detection steps (port scan) from both authorized and unauthorized IPs to verify access restrictions are working as expected.
• Smoke test: Verify that legitimate PLC programming and monitoring functions continue to operate normally from authorized clients.
• Monitoring: Monitor firewall logs for any blocked connections on port 502 originating from unexpected IP addresses.

netstat -an | grep :502

6. Preventive Measures and Monitoring

Regular security assessments and patch management are crucial to prevent similar vulnerabilities.

• Baselines: Update a security baseline or policy to include restrictions on Modbus TCP access, based on the principle of least privilege.
• Pipelines: Integrate SAST/SCA tools into CI pipelines to identify insecure configurations in PLC code and projects.
• Asset and patch process: Implement a regular review cycle for PLC configurations and firmware updates.

7. Risks, Side Effects, and Roll Back

Incorrect firewall configuration could disrupt legitimate PLC operations.

• Risk or side effect 2: Service disruption – incorrect rules may prevent essential monitoring or control functions from working.
• Roll back: Restore the backed-up PLC configuration to revert firewall changes. If using a snapshot, restore the virtual machine.

8. References and Resources

• Vendor advisory or bulletin: No link provided in context.
• NVD or CVE entry: No CVE ID was provided in the context.
• Product or platform documentation relevant to the fix: No specific documentation was provided in the context.