How to remediate – Modbus/TCP Device Identification

1. Introduction

The Modbus/TCP Device Identification vulnerability allows an attacker to read identifying information from devices using the Modbus protocol. This can reveal details about the device’s vendor, product code and revisions which could assist in further attacks. Systems commonly affected are industrial control systems (ICS) and SCADA equipment that implement Modbus/TCP communication. A successful exploit may allow attackers to gather intelligence for targeted attacks, potentially leading to confidentiality, integrity, or availability compromise of connected devices.

2. Technical Explanation

This vulnerability occurs because some Modbus/TCP devices respond to read requests for device identification data using function code 43 and MEI type 14. An attacker can send these requests to obtain Vendor Name, Product Code, Major and Minor Revision information. If the device does not support this functionality, it may still respond with error codes that reveal its presence.

• Root cause: Devices unnecessarily responding to Modbus Encapsulated Interface read requests with MEI type 14.
• Exploit mechanism: An attacker sends a Modbus Encapsulated Interface read request (function code 43, MEI type 14) to the target device and analyses the response for identifying information.
• Scope: Devices implementing Modbus/TCP communication are affected. Specific versions or configurations aren’t known from this report.

3. Detection and Assessment

You can confirm vulnerability by attempting to read device identification data, or by observing responses to invalid requests.

• Quick checks: Check network firewalls for open TCP port 502.
• Scanning: Nessus plugin ID 16839 may identify vulnerable devices. This is an example only.
• Logs and evidence: Network traffic captures may show Modbus Encapsulated Interface read requests (function code 43, MEI type 14) being sent to or from the target device.

nmap -p 502 --script modbus-discovery 

4. Solution / Remediation Steps

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

4.1 Preparation

• Ensure you have firewall administration access. A roll back plan is to restore the previous firewall configuration.
• Change windows may be required depending on your organisation’s policies. Approval from a senior engineer might be needed.

4.2 Implementation

1. Step 1: Create a firewall rule blocking inbound connections to TCP port 502 except from trusted IP addresses or networks.
2. Step 2: Verify the new firewall rule is active and correctly filtering traffic.

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 on port 502 (example iptables)
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

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Least privilege network segmentation to limit the blast radius if exploited.
• Practice 2: Network monitoring and intrusion detection systems (IDS) can identify malicious Modbus traffic.

4.5 Automation (Optional)

# Example Ansible playbook to block port 502 except for trusted IPs
- name: Block Modbus port except for trusted IPs
  firewalld:
    port: 502/tcp
    permanent: true
    state: enabled
    source: /32
    zone: public
- name: Reload firewalld
  command: firewall-cmd --reload

5. Verification / Validation

Confirm the fix by attempting to read device identification data from an untrusted source and verifying it is blocked.

• Post-fix check: Attempt a Modbus Encapsulated Interface read request (function code 43, MEI type 14) from an untrusted IP address. The connection should be refused or the request rejected.
• Re-test: Re-run the Nessus scan and confirm it no longer reports the vulnerability.
• Smoke test: Verify authorized Modbus clients can still communicate with the device.
• Monitoring: Check firewall logs for blocked connections to port 502 from untrusted sources.

nmap -p 502 --script modbus-discovery 

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update network security baselines to include restrictions on Modbus port access.
• Asset and patch process: Regularly review network configurations for unnecessary open ports or permissive rules.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Blocking legitimate Modbus traffic if trusted IP addresses are incorrectly configured. Mitigation is to carefully document authorized clients.
• Roll back: Restore the previous firewall configuration from backup.

8. References and Resources

• Vendor advisory or bulletin: No specific vendor advisory available in the provided context.
• NVD or CVE entry: No CVE identified in the provided context.
• Product or platform documentation relevant to the fix: http://www.modbus.org/