Listen to this Post
Introduction:
Industrial control systems (ICS) are increasingly adopting open-source and cross-platform programmable logic controller (PLC) environments like OpenPLC and CODESYS to streamline development. While this interoperability fosters innovation, it also introduces significant attack surfaces, as demonstrated by a project where code written in CODESYS compiled flawlessly on OpenPLC. This cross-platform compatibility, while convenient, can inadvertently propagate insecure coding practices and vulnerabilities across different vendor platforms, making it a critical area of focus for operational technology (OT) security professionals.
Learning Objectives:
- Understand the architecture and security implications of using open-source PLC editors like OpenPLC in conjunction with proprietary platforms like CODESYS.
- Learn how to identify and mitigate common vulnerabilities in Function Block Diagram (FBD), Structured Text (ST), and Ladder Logic programming.
- Acquire hands-on skills to harden development environments and simulate attacks against PLCs using open-source tools and command-line utilities.
You Should Know:
1. Setting Up a Cross-Platform PLC Testing Environment
This section focuses on replicating the environment used by Giovanni P., utilizing OpenPLC Editor and Simulator alongside CODESYS to analyze cross-platform code compatibility. We will walk through the installation of OpenPLC on both Linux and Windows systems, which is essential for testing industrial control logic in a safe, virtualized environment.
OpenPLC is an open-source Programmable Logic Controller suite that supports multiple industrial protocols (Modbus, DNP3, BACnet). To set up the editor and runtime:
- On Linux (Ubuntu/Debian):
sudo apt update sudo apt install git automake autoconf libtool build-essential git clone https://github.com/thiagoralves/OpenPLC_v3.git cd OpenPLC_v3 ./install.sh linux
The install script compiles the runtime and sets up the web interface. After installation, start the service:
sudo systemctl start openplc
-
On Windows:
Download the OpenPLC Editor from the official repository or use the provided installer. For the runtime, run the OpenPLC Windows installer or use the virtual machine (VM) approach. The editor itself is built on Beremiz, an open-source IDE for IEC 61131-3 languages. -
Installing CODESYS:
While CODESYS is proprietary, a free development license is available. Download it from the official CODESYS store. The key takeaway from the LinkedIn post is that Structured Text (ST) and Function Block code can often be copied directly from CODESYS to OpenPLC with minimal adjustments, highlighting the need for security reviews that transcend platform boundaries.
Step‑by‑step guide explaining what this does and how to use it:
This setup creates a sandbox where an engineer can write vulnerable logic (e.g., hardcoded passwords, unsafe memory access in ST) and see how both platforms handle the same code. Security teams can use this to test for flaws that might exist in both development environments.
2. Analyzing and Exploiting Vulnerable Function Blocks
Industrial control logic often uses Function Blocks (FBs) to encapsulate operations like timers, counters, or PID loops. However, custom Function Blocks written in Structured Text (ST) can introduce security risks if they lack input validation or contain race conditions. Using the environment set up above, we can simulate an insecure Function Block that is vulnerable to a denial-of-service (DoS) attack via network input.
Consider a simple Structured Text Function Block that increments a counter based on an external input:
FUNCTION_BLOCK InsecureCounter VAR_INPUT trigger : BOOL; max_value : INT; END_VAR VAR_OUTPUT count : INT; END_VAR VAR internal_count : INT := 0; END_VAR internal_count := internal_count + 1; IF internal_count > max_value THEN internal_count := 0; END_IF count := internal_count;
If the `trigger` input is driven by an external Modbus register that an attacker can manipulate, they can rapidly toggle the trigger to cause the PLC to execute the function block continuously, leading to increased scan cycle times and eventual PLC CPU exhaustion. To test this, use a Modbus client tool like `mbpoll` on Linux to flood the coil mapped to the trigger.
Step‑by‑step guide explaining what this does and how to use it:
1. Write the vulnerable Function Block in OpenPLC Editor and compile it.
2. Map the `trigger` input to a Modbus coil (e.g., coil 0).
3. Deploy the program to the OpenPLC runtime.
- From a Linux machine, use `mbpoll` to simulate an attack:
sudo apt install mbpoll Rapidly toggle coil 0 while true; do mbpoll -a 1 -0 0 -1 -t 0 -p 502 127.0.0.1; done
- Monitor the PLC’s CPU usage and scan time using `htop` or the OpenPLC web dashboard to observe degradation.
-
Hardening PLC Development Environments with Linux Security Controls
The cross-platform nature of these tools means they are often run on general-purpose operating systems, exposing them to typical OS-level attacks. Hardening the Linux host running OpenPLC is crucial. This involves using AppArmor or SELinux to confine the OpenPLC runtime, and configuring firewall rules to restrict access to the PLC’s communication ports.
OpenPLC uses several critical ports: 80 (web interface), 502 (Modbus/TCP), 20000 (DNP3), and 44818 (EtherNet/IP). Restricting these ports to only trusted IP addresses is a fundamental security measure.
- Using UFW (Uncomplicated Firewall) on Ubuntu:
sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp Allow web access only from management subnet sudo ufw allow from 192.168.1.100 to any port 502 proto tcp Allow Modbus only from HMI sudo ufw enable
-
Applying AppArmor Profiles:
Create a custom AppArmor profile for the OpenPLC runtime binary located at `/usr/local/bin/openplc` to restrict file system access. For instance, the profile should allow write access only to log directories and deny access to/etc/passwd.sudo aa-genprof /usr/local/bin/openplc
During the profiling process, simulate normal operations (uploading code, running the PLC) and then refine the profile to deny any anomalous file accesses.
Step‑by‑step guide explaining what this does and how to use it:
This hardening procedure prevents an attacker who has compromised a network-accessible service (like the web interface) from escalating privileges or pivoting to other systems. It ensures the PLC runtime operates with the principle of least privilege.
4. Simulating Network Attacks on PLC Protocols
To truly understand the security posture of cross-platform PLCs, one must simulate attacks on industrial protocols. Since OpenPLC supports Modbus/TCP, it is highly susceptible to reconnaissance and command injection attacks if not properly secured. Using tools like Nmap and Metasploit, we can assess the security of the deployed logic.
- Modbus Reconnaissance:
Use Nmap to identify all Modbus devices on the network:nmap -p 502 --script modbus-discover 192.168.1.0/24
-
Modbus Coil Manipulation:
Using the Metasploit framework, we can read or write coils to manipulate the industrial process.msfconsole use auxiliary/scanner/scada/modbusclient set RHOSTS 192.168.1.100 set ACTION READ_COILS set DATA_ADDRESS 0 set DATA_VALUE 1 run
Step‑by‑step guide explaining what this does and how to use it:
These tools demonstrate how an attacker can identify and manipulate the Function Blocks and logic developed in environments like OpenPLC and CODESYS. By performing these scans on your own lab setup, you can validate whether access controls are effective and whether the logic includes any “safety” redundancy that might be bypassed by unauthorized write commands.
5. Securing Code Migration Between CODESYS and OpenPLC
The core insight from the LinkedIn post is the seamless migration of code between CODESYS and OpenPLC. Security-wise, this means a vulnerability discovered in a CODESYS project can be exploited in any OpenPLC implementation that uses the same logic. To mitigate this, implement a secure code review process that is environment-agnostic.
- Version Control with Security Hooks:
Store your PLC projects in a Git repository. Use pre-commit hooks to scan for hardcoded credentials or unsafe function calls.Example: pre-commit hook to scan for strings like "password" in .st and .ld files if grep -r "password" .st .ld; then echo "Error: Hardcoded password found in code." exit 1 fi
-
Automated Unit Testing:
Use OpenPLC’s Python-based testing framework to automatically simulate inputs and verify outputs, ensuring that security-related invariants hold. For instance, test that a safety function block cannot be disabled by a malicious Modbus command.Snippet for automated testing using pyModbus from pymodbus.client import ModbusTcpClient client = ModbusTcpClient('192.168.1.100') Test: Write to a coil that should be read-only response = client.write_coil(0, True) assert response.isError() == True, "Read-only coil was writable!"
Step‑by‑step guide explaining what this does and how to use it:
This approach integrates security into the development lifecycle (DevSecOps for OT). By validating that security controls (like read-only registers) are enforced at the protocol level, you ensure that the migration of code does not inadvertently create new vulnerabilities.
What Undercode Say:
- Cross-Platform Code is a Double-Edged Sword: The ability to move code seamlessly between CODESYS and OpenPLC accelerates development but also means security flaws are portable. Security teams must audit code for platform-agnostic vulnerabilities like input validation and race conditions, not just vendor-specific issues.
- Homogeneous Vulnerabilities Across OT Environments: The widespread adoption of open-source PLC runtimes on Linux means attackers can develop exploits once and deploy them against numerous targets. Hardening the underlying OS (using firewalls, AppArmor, and regular patching) is as critical as securing the ladder logic itself.
Prediction:
As open-source PLC platforms continue to gain traction in both educational and industrial settings, we will see a convergence of IT and OT attack patterns. Expect a rise in cross-platform malware that targets the IEC 61131-3 runtime environment itself, rather than specific hardware, similar to how modern ransomware targets operating systems regardless of the application. The future of OT security will involve not just securing the logic, but also hardening the development pipelines and deployment hosts to prevent the propagation of vulnerabilities across the entire industrial software supply chain.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Giovanni P – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
