Unveiling the Secrets of Codesys V3: ZeroDays, Forensic Artifacts and More

Unveiling the Secrets of Codesys V3: ZeroDays, Forensic Artifacts and More

Speakers: Ori Perez, Principal Security Researcher, Microsoft; Maayan, Researcher, Microsoft; Vladimir, Researcher, Microsoft

Conference: RSAC 2024

YouTube: https://www.youtube.com/watch?v=e8u1uMjC31g

Overview

This talk, presented by Ori Perez, Maayan, and Vladimir from Microsoft, delves into the intricate world of Codesys V3, a widely adopted Software Development Kit (SDK) for industrial control systems (ICS). The researchers share their extensive work on reverse engineering Codesys V3 compiled binaries and firmware, driven by a critical need to establish robust forensic methodologies for Operational Technology (OT) environments. Their investigation not only uncovers the internal workings of Codesys-based PLCs but also exposes multiple zero-day vulnerabilities, including remote code execution (RCE) flaws, with a live demonstration of an exploit.

The motivation behind this research stems from the increasing sophistication and frequency of cyberattacks targeting critical infrastructure, often leveraging the very OT systems that underpin these operations. While IT forensics has well-established practices, a standardized methodology for OT forensics remains largely absent, leaving a significant gap in incident response capabilities. By dissecting Codesys V3, a platform prevalent across diverse sectors like automotive, energy, and building automation, the Microsoft team aims to equip defenders with the knowledge and tools necessary to detect, analyze, and respond to threats within these vital industrial environments.

The findings presented are crucial for enhancing the security posture of countless industrial organizations. The talk highlights the inherent risks associated with the widespread deployment of complex, often opaque, proprietary software in OT. The discovery of exploitable vulnerabilities underscores the urgency for vendors to improve security and for asset owners to implement advanced defensive strategies, moving beyond traditional network segmentation to deep analysis of PLC logic and firmware for signs of compromise.

Background

▶ Watch: Introduction to Codesys V3 and research motivation (0:00)

The landscape of Operational Technology (OT) has become an increasingly attractive target for sophisticated cyber adversaries, including nation-state actors. Historical incidents like Stuxnet, Industroyer, and CosmicEnergy serve as stark reminders of the devastating impact that cyberattacks can have on critical infrastructure, often by manipulating the logic and behavior of Programmable Logic Controllers (PLCs). Despite this escalating threat, the field of OT forensics lags significantly behind its IT counterpart, lacking a common, standardized methodology for investigating compromises within industrial environments.

Codesys V3 is at the heart of this challenge. As a versatile SDK, it supports a vast array of CPUs (ARM, PowerPC, MIPS) and operating systems (QNX, VxWorks, Windows Embedded, Linux), making it a cornerstone for numerous vendors in automotive, energy, chip manufacturing, and building automation sectors. This ubiquity, while beneficial for development, simultaneously positions Codesys-based devices as a prime target for attackers. The researchers observed a significant number of Codesys devices exposed online, underscoring the broad attack surface. Furthermore, prior incidents, such as the "Code of in controller" (a nation-state sponsored tool with a Codesys module capable of scanning, communication, and logic modification), illustrate the real-world implications of compromising these platforms. The ability to modify PLC logic grants attackers complete control, enabling potential damage or disruption to industrial processes.

The research was specifically driven by the need to develop OT forensics capabilities that could address several key challenges:

• Tracking Third-Party Implementations: Verifying the integrity of software delivered to PLCs.
• Lack of Tools: The absence of dedicated OT forensics tools for cybersecurity professionals.
• Vulnerability Remediation: Addressing dozens of existing, unpatched vulnerabilities in Codesys devices.

To establish a forensic foundation, the team first examined the structure of PLC programs, which adhere to the IEC 61131-3 standard. This standard defines several programming languages, including Ladder Logic (LD), Structured Text (ST), Function Block Diagram (FBD), Instruction List (IL), and Sequential Function Chart (SFC). The research primarily focused on Ladder Logic, which resembles an electrical ladder diagram, executing commands sequentially in "ranks" based on inputs (contacts) and outputs (coils).

A typical PLC project consists of hardware, an operating system, and an application. The application is structured around tasks, which are the main execution units, and each task contains one or more Program Organizational Units (POUs). POUs are the actual code sections written by OT engineers. Understanding this hierarchy is crucial for dissecting the compiled binary.

The desired forensic artifacts in an OT context parallel those in IT but with industrial specificities:

• Timestamp Outliers: Identifying unusual modification or execution times for code.
• Author Information: Verifying the legitimacy of the code author.
• Task Usage: Understanding what triggers tasks and how they execute.
• Network Capabilities: Highlighting code sections with network functionalities, which could indicate malware or misconfigurations.
• Online/Offline Project Comparison: Crucially, being able to compare the code running on the PLC with a known good version from an engineering station, without relying on a potentially compromised IDE. This last point formed a core objective of the research.

Key Findings

▶ Watch: The critical need for OT forensics methodology (2:00)

The Microsoft research team successfully pioneered a comprehensive methodology for dissecting Codesys V3, leading to several significant findings:

1. OT Forensics Framework: The development of a systematic approach to extract forensic artifacts from Codesys V3 compiled binaries, addressing the long-standing gap in OT forensics. This framework allows for the reconstruction of program execution flow, identification of key components like POUs and tasks, and the extraction of metadata such as build dates and author information.
2. Codesys V3 Protocol Reverse Engineering: A deep dive into the Codesys V3 protocol and firmware execution flow, revealing how PLC projects are loaded, executed, and how internal data structures (like protocol tags and symbol tables) are organized within the compiled binary and the PLC's firmware.
3. Discovery of Multiple Zero-Day Vulnerabilities: The identification and responsible disclosure of several critical vulnerabilities within the Codesys V3 protocol, including Denial of Service (DoS) and Remote Code Execution (RCE) flaws. A specific stack-based overflow vulnerability was detailed as a prime example.
4. Proof-of-Concept RCE Exploit: The successful development and demonstration of an RCE exploit that bypasses common mitigations like Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP), showcasing the real-world impact of the discovered vulnerabilities. This exploit was shown to reboot a targeted Wago PLC, confirming the ability to achieve arbitrary code execution.
5. Open-Source Tools: The commitment to publishing open-source tools to enable broader community engagement and enhance OT security research and defensive capabilities, allowing others to perform similar analyses and artifact extraction.

These findings collectively contribute to a deeper understanding of Codesys V3's internal architecture, provide concrete methods for forensic analysis in OT environments, and highlight the urgent need for improved security practices in industrial control systems.

Technical Deep Dive

▶ Watch: Explaining Ladder Logic (LD) and PLC execution principles (3:45)

The research journey commenced with a structured approach to reverse engineering Codesys V3, outlined in a clear timeline: project parsing, dynamic firmware analysis, vulnerability discovery and disclosure, automated data extraction, and finally, plugin development for forensic artifact collection.

Project Parsing: Deconstructing the Compiled Binary

The initial phase involved analyzing compiled Codesys V3 projects. The team utilized a Wago PLC based on Codesys V3, writing example projects and then examining their compiled binaries. Tools like IDA Pro and a hex editor (O&O editor) were instrumental. Knowing the target PLC's CPU was ARM with little-endian byte order guided the disassembly process.

Initial insights revealed a consistent file structure:

• Header: Contains metadata like the application name, GUID, and pointers.
• Footer: Located at the end of the file, holding critical forensic information such as the project name (distinct from application name), version, build date/time, author name, and description.
• Project Data: The bulk of the file, segmented by protocol tags. These are integer values that act as identifiers, indicating the data type that follows.

The core objective in this phase was to reconstruct the entire call execution flow of the PLC project, specifically identifying and mapping POUs, functions, and tasks.

1. Program Organizational Units (POUs):

• POUs are the actual code blocks written by engineers. By creating a simple POU (e.g., an IF statement assigning a hardcoded value and calling another POU), the researchers could locate its compiled representation in IDA by searching for the hardcoded value.
• Jumps between POUs were observed to be implemented as pointer offsets loaded into the Program Counter (PC) register.
• To correctly resolve these jumps and map them to specific POUs, the team leveraged the symbol table. A symbol table is a data structure containing essential identifiers, variable names, function names, and crucially, function pointers. By cross-referencing the pointer offsets with entries in the symbol table, the exact POU being called could be identified.

1. Functions:

• Codesys projects often use built-in functions (e.g., if_is_first_mass_cycle). Similar to POUs, calls to these functions were identified.
• A dedicated function symbol table was discovered, mapping function names to their respective pointer offsets, enabling the patching and resolution of these function calls within the compiled binary.

1. Tasks:

• Tasks are the "main functions" of a PLC project, driving its overall execution. Every Codesys project must have at least one task.
• Tasks were identified by observing their calls to POUs. Since POU calls could now be resolved, tasks could be spotted.
• However, static analysis of the compiled binary proved insufficient to extract all task-related parameters (e.g., name, type, priority, cycle time). This limitation necessitated dynamic analysis of the PLC firmware.

Firmware Analysis: Unveiling the Execution Environment

The need to understand the complete mapping of protocol tags and the application's entry point led to a deep dive into the PLC's firmware. The target was a Wago PLC.

1. Firmware Extraction and Initial Analysis:

• Binwalk was used to extract files from the firmware image.
• The most relevant files were found in the image CSOS directory.
• strings command helped quickly identify files containing Codesys components.
• Physical inspection of the PLC revealed its CPU as a Spear 680, confirming the ARM little-endian architecture.
• A magic value, 55 CD, served as a crucial foothold, with numerous references found in the binaries.

1. IDA Pro Enhancements:

• To effectively analyze the complex firmware binaries, custom IDA Python scripts were developed. These scripts facilitated better binary parsing, function renaming based on logs and suffixes, and inheritance logic.
• A key discovery was a reference table at the end of the file, consisting of double D word entries pointing to strings (function names) followed by double D word entries pointing to methods. This allowed for automated and accurate renaming of functions in IDA.

1. Component app and Execution Flow:

• The firmware comprised various components, each managing different services. The component app was identified as central to understanding how compiled ST projects execute on the PLC. It handles operations like uploading, downloading, and deleting "boot projects" (projects executed when the PLC starts).
• By analyzing app's code flow, the researchers successfully identified the application tags and, critically, the application entry point, which was linked to the IC_task execution. This filled the gaps left by static analysis, enabling automated extraction of all required information.

Vulnerability Discovery: The Stack-Based Overflow

During the analysis of the component app's code, a critical vulnerability was uncovered. A specific code pattern involving B_TagReader_GetContent and memcpy caught their attention:

Here, B_TagReader_GetContent copies content from an imported tag into PPB_area, with its size stored in PPB_area_size. Subsequently, memcpy copies data from PPB_area to New_AB_area. The critical flaw lay in New_AB_area being a stack variable with a fixed, limited size. If PPB_area_size (controlled by the attacker through the imported tag) exceeded the buffer size of New_AB_area, a stack-based overflow would occur.

This vulnerability, if exploited with a sufficiently long payload, would cause the PLC to crash (a DoS condition). The researchers noted that this was one of many vulnerabilities found, including other DoS and Remote Code Execution (RCE) flaws.

Demo / Proof of Concept

▶ Watch: Overview of the reverse engineering research timeline (6:00)

The ultimate goal of discovering the stack-based overflow was to achieve Remote Code Execution (RCE). This required bypassing two common security mitigations: Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP).

1. Bypassing ASLR:

• ASLR randomizes the memory addresses of executable images and other memory regions, making it harder for an attacker to predict the location of specific code.
• The team employed a classic technique: Return-Oriented Programming (ROP). This involves chaining together small, existing code sequences (called ROP gadgets) within the legitimate program's memory. By controlling the return address on the stack, an attacker can redirect execution through these gadgets to achieve desired functionality, effectively bypassing ASLR by using code that is already loaded, even if its base address is randomized.

1. Bypassing DEP:

• DEP prevents code execution from data-only memory regions, such as the stack or heap, making it difficult to execute injected shellcode.
• The crucial insight for bypassing DEP came from the inner workings of the IC_task, the primary execution component of Codesys. It was discovered that IC_task segments possess execute, read, and write primitives. More importantly, the stack segment of the component being executed fell within this R/W/X (Read/Write/Execute) region. This meant that if the researchers could successfully write their shellcode onto the stack (via the stack-based overflow), they could then execute it directly, effectively bypassing DEP.

1. RCE Exploit Construction:

• Leveraging the IC_task's internal structure also allowed the team to pinpoint the exact entry point for the execution of the ST (Structured Text) code, crucial for orchestrating the exploit.
• The Proof of Concept (POC) exploit payload was structured as follows:
• Noise Data: Padding to align the stack and reach the desired overwrite location.
• Register Values: Controlled values for specific CPU registers, to be used by the shellcode.
• Program Counter (PC) Jump: The critical part, redirecting execution to a BLX gadget. The BLX instruction (Branch with Link and Exchange) is commonly used in ARM to jump to an address and switch instruction sets (e.g., from ARM to Thumb). In this context, it was used to jump to the attacker's shellcode placed on the stack, which had execution permissions.
• Shellcode: The actual malicious code. For the Wago PLC used in the demonstration, the Lib-C library was located at a fixed, non-randomized memory address. This allowed for a Return-to-Lib-C attack, where the shellcode simply called a function from Lib-C (e.g., system() or reboot()) to achieve its objective. In the demo, the exploit was designed to reboot the PLC.

The demonstration showcased the exploit in action. The researchers initiated the exploit, sending specially crafted packets over the network to the target Wago PLC. The Putty connection to the PLC was observed to disconnect, and the physical lights on the PLC blinked off and then on again, confirming a successful reboot and thus, remote code execution. This visually compelling demonstration highlighted the severe impact of the discovered vulnerabilities.

Defensive Implications

▶ Watch: Initial steps: project parsing and binary examination (7:00)

The detailed research into Codesys V3 and the discovery of zero-day vulnerabilities carry significant implications for the security of Operational Technology (OT) environments. Defenders must adopt a multi-layered approach to mitigate these risks:

1. Prioritize Patching and Firmware Upgrades: The most direct defense against discovered vulnerabilities is to apply vendor-provided patches and firmware updates. However, the speakers acknowledged that propagating these updates in highly controlled and often air-gapped OT networks can be a lengthy process. This necessitates alternative or supplementary defensive measures.
2. Robust Network Segmentation and Hygiene: While not a silver bullet, strict network segmentation remains foundational. Isolating critical OT assets from enterprise networks and implementing granular access controls significantly reduces the attack surface and limits lateral movement for attackers who manage to breach perimeter defenses. Good network hygiene, including disabling unnecessary services and ports, is also crucial.
3. Implement OT-Specific Forensic Capabilities: The core motivation of this research was to address the lack of OT forensics. Defenders should invest in developing methodologies and acquiring tools that allow for offline analysis of PLC project files and firmware. The open-source tools released by the Microsoft team are a starting point for this. The ability to perform online/offline project comparisons without relying on potentially compromised engineering stations is paramount.
4. Validate API Usage: One speaker noted that many of the 31 vulnerabilities observed could have been prevented if API usages were rigorously validated against their intended purpose. This implies a need for developers to adhere to secure coding practices and for organizations to potentially implement automated tools or processes to audit how Codesys APIs are being used in their custom applications.
5. Monitor for Anomalous Logic and Configuration: Defenders should actively monitor PLC logic for unauthorized modifications, unusual task triggers, or the presence of network capabilities in unexpected code sections. This requires deep understanding of the normal operating parameters and behavior of their industrial processes.
6. Supply Chain Security: Given the reliance on third-party SDKs like Codesys, organizations must scrutinize their supply chain for OT software and hardware. This includes vetting vendors' security practices, requesting security attestations, and ensuring that components are free from known vulnerabilities before deployment.
7. Consider Hardware-Level Protections: While not explicitly discussed as a defense in the talk, the nature of RCE on PLCs points to the importance of hardware-level security features where available, such as secure boot, trusted platform modules (TPMs), and memory protection units (MPUs) that could enforce stronger DEP and ASLR.

Ultimately, while the research demonstrates worst-case scenarios, the speakers emphasized that adopting proper takeaways can dramatically reduce the attack surface. A combination of proactive measures, robust network architecture, and enhanced forensic readiness is key to protecting critical OT infrastructure from sophisticated threats.

Key Takeaways

• Codesys V3 is a Critical Target: Its widespread adoption across diverse industrial sectors makes it an attractive and high-impact target for cyber adversaries, including nation-state actors.
• OT Forensics is Lagging: There's a significant gap in standardized methodologies and dedicated tools for forensic analysis in Operational Technology (OT) environments, leaving organizations vulnerable and blind to compromises.
• Deep Reverse Engineering Reveals Secrets: Thorough reverse engineering of compiled PLC binaries and firmware can uncover intricate details about project execution, data structures, and critical vulnerabilities, which are often opaque in proprietary industrial software.
• Common Vulnerabilities Lead to Severe Impacts: Even seemingly common vulnerabilities like stack-based overflows can be leveraged to achieve Remote Code Execution (RCE) on industrial controllers, bypassing advanced mitigations like ASLR and DEP, with potentially devastating consequences for critical infrastructure.
• Proactive Defense is Essential: Effective protection requires a multi-faceted approach, including timely patching, robust network segmentation, rigorous validation of API usage, and the development of OT-specific monitoring and forensic capabilities.
• Open-Source Tools Empower Defenders: The release of open-source tools for Codesys V3 analysis is a crucial step towards democratizing OT security research and enabling a broader community of defenders to analyze, understand, and secure industrial control systems.

About the Speaker(s)

Ori Perez is a Principal Security Researcher at Microsoft. He led the research into Codesys V3, focusing on understanding its internal workings and developing forensic methodologies for Operational Technology (OT) environments. His work aims to bridge the gap between IT and OT security, addressing critical vulnerabilities in industrial control systems.

Maayan and Vladimir are security researchers who collaborated with Ori Perez on this Codesys V3 research at Microsoft. Their contributions were instrumental in the reverse engineering efforts, dynamic analysis of PLC firmware, and the discovery and exploitation of zero-day vulnerabilities. They are part of a team dedicated to enhancing cybersecurity in industrial contexts.