Multiple high severity vulnerabilities in CODESYS V3 SDK could lead to RCE or DoS
Microsoft’s cyberphysical system researchers recently identified multiple high-severity vulnerabilities in the CODESYS V3 software development kit (SDK), a software development environment widely used to program and engineer programmable logic controllers (PLCs). Exploitation of the discovered vulnerabilities, which affect all versions of CODESYS V3 prior to version 3.5.19.0, could put operational technology (OT) infrastructure at risk of attacks, such as remote code execution (RCE) and denial of service (DoS). The discovery of these vulnerabilities highlights the critical importance of ensuring the security of industrial control systems and underscores the need for continuous monitoring and protection of these environments.
CODESYS is compatible with approximately 1,000 different device types from over 500 manufacturers and several million devices that use the solution to implement the international industrial standard IEC (International Electrotechnical Commission) 611131-3. A DoS attack against a device using a vulnerable version of CODESYS could enable threat actors to shut down a power plant, while remote code execution could create a backdoor for devices and let attackers tamper with operations, cause a PLC to run in an unusual way, or steal critical information. Exploiting the discovered vulnerabilities, however, requires user authentication, as well as deep knowledge of the proprietary protocol of CODESYS V3 and the structure of the different services that the protocol uses.
Microsoft researchers reported the discovery to CODESYS in September 2022 and worked closely with CODESYS to ensure that the vulnerabilities are patched. Information on the patch released by CODESYS to address these vulnerabilities can be found here: Security update for CODESYS Control V3. We strongly urge CODESYS users to apply these security updates as soon as possible. We also thank CODESYS for their collaboration and recognizing the urgency in addressing these vulnerabilities.
Below is a list of the discovered vulnerabilities discussed in this blog:
In this blog, we provide an overview of the CODESYS V3 protocol structure, highlighting several key components, and describe the main issue that led to our discovery of the vulnerabilities. The full research and the results can be found in our report on Github. We also provide an open-source forensics tool to help users identify impacted devices, security recommendations for those affected, and detection information for potentially related threats.
CODESYS: A widely used PLC solution
CODESYS is a software development environment that provides automation specialists with tools for developing automated solutions. CODESYS is a platform-independent solution that helps device manufacturers implement the international industrial standard IEC 611131-3. The SDK also has management software that runs on Windows machines and a simulator for testing environments, allowing users to test their PLC systems before deployment. The proprietary protocols used by CODESYS use either UDP or TCP for communication between the management software and PLC.
CODESYS is widely used and can be found in several industries, including factory automation, energy automation, and process automation, among others.
Discovering the CODESYS vulnerabilities
The vulnerabilities were uncovered by Microsoft researchers while examining the security of the CODESYS V3 proprietary protocol as part of our goal to improve the security standards and create forensic tools for OT devices. During this research, we examined the structure and security of the protocol that is used by many types and vendors of PLCs. We examined the following two PLCs that use CODESYS V3 from different vendors: Schneider Electric Modicon TM251 and WAGO PFC200.
CODESYS V3 protocol
The CODESYS network protocol works over either TCP or UDP:
- Ports 11740-11743 for TCP
- Ports 1740-1743 for UDP
The CODESYS network protocol consists of four layers:
- Block driver layer: The layer that creates the capability to communicate over a physical or software interface, over TCP or UDP.
- Datagram layer: The layer that enables communication between components and endpoints through physical or virtual interfaces.
- Channel layer: The layer that is responsible for creating, managing, and closing communications channels.
- Services layer: Represents a combination of several layers of the ISO/OSI model session layer, presentation layer, and application layer. It consists of components, each of which is responsible for a portion of functionality of the PLC and has services that it supports. Other tasks of the Services layer include encoding/decoding and encrypting/decrypting the data transmitted on that layer. Additionally, the Services layer is also responsible for tracking the client-server session. Each component is identified by a unique ID, such as:
| Component name | Component ID |
| CmpApp | 0x2 |
| CmpAlarmManager | 0x18 |
| CmpAppBP | 0x12 |
| CmpAppForce | 0x13 |
| CmpCodeMeter | 0x1D |
These components use the Tags layer for data transmission and encoding, which is transmitted over the Services layer.
There are two types of tags: parent and data. Both tags have identical structure but different sizes and purposes. The following table provides the basic structure of tags:
| Field | Parent tag size (in bytes) | Data tag size (in bytes) | Description |
| Tag ID | 2 | 1 | The tag ID. The value of the most significant bit determines the type of tag. For parent tag, the value of the most significant bit is set. |
| Tag size | 2 | 1 | The size of the data. |
| Tag data | (Tag size) | (Tag size) | The data of the tag. |
Tags can represent any type of data, and it is extracted by the component. The difference between a parent tag and a data tag is that a parent tag is used for linking several tags into one logical element.
Tags contain several important structures, including BTagReader and BTagWriter, which include the following fields:
- Data
- Current position in data
- Size of data
These structures are allocated for each request and exist only in the context of the request. Each request handler creates BTagWriter and BTagReader tags and uses them to parse and handle requests. Tag IDs are not unique across services, meaning each service may have its own definition for a tag ID. Tag IDs are handled in the context of each service.
The following figure provides an example of a Tag layer and relevant fields.
This example contains the following tags:
- Tag1 – )TAG ID 0x01( 10 00 00 00
- Tag2 – (TAG ID 0x23) Authentication method type
- Tag3 – (TAG ID 0x81) Parent tag that contains two sub tags
- Tag4 – (TAG ID 0x10) Username tag
- Tag5 – (TAG ID 0x11) Hash of a password tag
CODESYS components
CODESYS consists of components and each component is responsible for a portion of functionality of the PLC. The following is a list of example components:
- CmpAlarmManger – Manages alarm events, registers clients that receive events, etc.
- CmpApp – Manages running applications and application event usage.
- CmpAppBp – Manages breakpoints in IEC tasks.
- CmpCodeMeter – Manages the CodeMeter License containers.
- CmpCoreDump – Manages creating, reading, and printing to file coredumps.
- CMPTraceMgr – Enables tracing of information inside the IEC tasks.
Each component includes a number of services that the client can ask to use. For example, CMPTraceMgrincludes the following:
Each service is identified by a unique number for the specific component.
Tags layer vulnerability
A security issue was discovered inside the tag decoding mechanism that led to multiple vulnerabilities that could put devices at risk of attacks such as RCE and DoS.
In order to understand the security issue, let’s analyze the service TraceMgrRecordAdd of the component CMPTraceMgr by examining the code that activates the relevant service.
The TraceMgrRecordAddByTag appears to correspond to TraceMgrRecordAdd.
As displayed in Figure 5, the following code initializes structure from tags that are sent to the service.
The following figure looks at the code for the TraceMgrAddNewRecordPartByTag method, which copies data from different tags into an output buffer.
The whole tag is copied into the buffer without validating the size, causing buffer overflow.
Fifteen places in CODESYS V3 SDK were found with the same issue in different components that could lead to remote attackers gaining full control over the device.
Exploitation approach
We were able to apply 12 of the buffer overflow vulnerabilities to gain RCE of PLCs. Exploiting the vulnerabilities requires user authentication as well as bypassing the Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) used by both the PLCs. To overcome the user authentication, we used a known vulnerability, CVE-2019-9013, which allows us to perform a replay attack against the PLC using the unsecured username and password’s hash that were sent during the sign-in process, allowing us to bypass the user authentication process.
IEC tasks
IEC tasks are the execution unit of CODESYS runtime. It is the equivalent to thread in operating systems. A single component can have more than one task and will have at least one IEC task. The tasks are managed by CODESYS runtime.
Each IEC task has a memory segment with read, write, and execute permissions. If a threat actor writes code there, it could be run without the data execution prevention mitigation being applied.
The IEC task segment is also where the stack is defined, meaning we don’t need to handle DEP.
Since the IEC tasks are part of the CODESYS code, they are present on all PLCs of all vendors that utilize CODESYS.
Full exploit
By looking for gadgets, we can bypass the ASLR. In the examples below, we can see part of the gadgets that we used in our exploit.
The complete exploit steps:
- Steal credentials with CVE-2019-9013.
- Create a new channel for the attack.
- Sign-in to the device with the stolen credentials.
- Exploit the vulnerabilities with a malicious packet that triggers buffer overflow.
- Gain full control of the device.
We were able to exploit the two PLCs that we researched.
Demo video:
Critical importance of ICS security
With CODESYS being used by many vendors, one vulnerability may affect many sectors, device types, and verticals, let alone multiple vulnerabilities. All the vulnerabilities can lead to DoS and 1 RCE. While exploiting the discovered vulnerabilities requires deep knowledge of the proprietary protocol of CODESYS V3 as well as user authentication (and additional permissions are required for an account to have control of the PLC), a successful attack has the potential to inflict great damage on targets. Threat actors could launch a DoS attack against a device using a vulnerable version of CODESYS to shut down industrial operations or exploit the RCE vulnerabilities to deploy a backdoor to steal sensitive data, tamper with operations, or force a PLC to operate in a dangerous way.
Mitigation and protection guidance
CODESYS V3 versions prior to 3.5.19.0 are vulnerable to the discovered vulnerabilities. It is recommended to first identify the devices using CODESYS in your network and check with device manufacturers to determine which version of the CODESYS SDK is used and whether a patch is available. It is also recommended to update the device firmware to version to 3.5.19.0 or above.
General recommendations:
- Apply patches to affected devices in your network. Check with the device manufacturers for available patches and update the device firmware to version to 3.5.19.0 or above.
- Make sure all critical devices, such as PLCs, routers, PCs, etc., are disconnected from the internet and segmented, regardless of whether they run CODESYS.
- Limit access to CODESYS devices to authorized components only.
- Due to the nature of the CVEs, which still require a username and password, if prioritizing patching is difficult, reduce risk by ensuring proper segmentation, requiring unique usernames and passwords, and reducing users that have writing authentication.
To assist with identifying impacted devices, the cyberphysical systems research team has released an open-source software tool on GitHub that allows users to communicate with devices in their environment that run CODESYS and extract the version of CODESYS on their devices in a safe manner to confirm if their devices are vulnerable. In addition, the cyberphysical system research team also released a tool for performing a forensics investigation on CODESYS V3 devices as part of its arsenal of open-source tools available on GitHub.
Microsoft 365 Defender detections
Microsoft Defender for IoT
Microsoft Defender for IoT with all versions of the sensor and TI package after April 2023 provides the following protections against these vulnerabilities and associated exploits and other malicious behavior:
- Defender for IoT detects and classifies devices that use CODESYS.
- Defender for IoT raises alerts on unauthorized access to devices using CODESYS, and abnormal behavior in these devices.
- Defender for IoT raises alerts if a threat actor attempts to exploit these vulnerabilities. Alert type: “Suspicion of Malicious Activity”
Microsoft Defender Threat Intelligence
Microsoft Defender Threat Intelligence shows devices running CODESYS that are exposed to the internet by searching for “CODESYS” components on IPs.
Vladimir Tokarev
Microsoft Threat Intelligence Community
References
Further reading
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.
To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.
READ MORE HERE