Nozomi Networks Labs recently found four vulnerabilities in Beckhoff Automation’s TwinCAT/BSD operating system that, in the right conditions, could leave PLCs vulnerable to logic tampering or Denial-of-Service (DoS) attacks, significantly impacting the supervised industrial process. As a matter of fact, the issues we discovered present impactful cyber threats, such as the potential to execute commands with root privileges on the PLC, or the possibility to induce OS-level freezes, necessitating a power cycle to resolve.
A successful attack requires obtaining access to a valid local account on the operating system. However, no specific privileges are necessary, meaning that even users or third-party applications with the lowest possible allowance on the PLC could exploit these flaws, if left unaddressed.
Upon sharing our findings with Beckhoff Automation, they took fast action to resolve the issue, demonstrating an impressive and remarkable 2-month response time. Patches and mitigations for these vulnerabilities are now available on Beckhoff’s official Advisories page.
Below, we present the results of the security research that led to the discovery of these four new vulnerabilities. Once again, we would like to thank Beckhoff for their quick response and continuous professionalism throughout the disclosure process.
Research Scope
TwinCAT/BSD is an operating system developed by Beckhoff Automation, designed to combine the real-time control capabilities of TwinCAT with the robust and versatile features of the BSD Unix-based operating system. TwinCAT, short for “The Windows Control and Automation Technology”, is a software system that transforms almost any PC-based system into a real-time controller with multi-PLC system capabilities, with the added benefit of being highly compatible with standard IT infrastructure.
Among the software that can be installed on TwinCAT/BSD is Beckhoff Device Manager (Figure 1), a comprehensive suite of features for overseeing the operational status, performance, and configuration of Beckhoff devices remotely from a centralized location.
All security flaws presented in this blog were identified after analyzing this software. For a detailed list of the vulnerable packages and versions, refer to the section “Vulnerability List and Affected Versions.”
![](https://cdn.prod.website-files.com/645a45d56fc4750d4edd96fe/66b17c9a55260ca2a2384321_66b17c2cd744997479997be9_12440269323__Web%2520copy.webp)
What Are the Impacts of These Vulnerabilities?
These vulnerabilities have notable repercussions on affected devices. Should an attacker achieve some kind of access to the operating system of the PLC (further details are provided later in this section), regardless of the privilege obtained , they would be able to enact attack scenarios such as:
- Tampering with the PLC logic: An attacker with limited credentials could exploit one of the identified vulnerabilities to reset the PLC administrator's password without needing the original one. This would allow them to connect to the PLC with administrative access via standard engineering tools and to reprogram the device as desired, potentially subverting the supervised industrial process.
- PLC denial-of-service: An attacker with limited credentials may exploit another vulnerability to make the device unresponsive and unavailable, both remotely from the network as well as locally through mouse and keyboard access, until a power reset is performed. This may be combined with other attacks against the device: for instance, a threat actor may perform the previously cited manipulation of the PLC programming to initiate the disruption of the industrial process, then enact this scenario to prevent access to the device, blocking any attempt to regain control.
One of the simplest methods for an adversary to carry out these attack scenarios is by acquiring (e.g., sniffing, stealing via phishing, cracking, etc.) valid credentials for one of the PLC's operating system accounts, and then logging in to the device via SSH. Attackers do not need to target heavily protected administrative credentials, but may focus on lesser-privileged ones, like those used by auditors or external contractors to access the device and perform maintenance activities. As a matter of fact, it’s not so uncommon for these kinds of credentials to have weaker password protections, such as less complexity, infrequent rotation, or reuse across devices. However, this strategy requires direct interaction with the device, likely necessitating prior internal network access, as PLCs are rarely exposed on the public internet.
Another route a threat actor may leverage to attack the vulnerable PLC could be by compromising the supply chain of one of the third-party applications or libraries on a device and then waiting for the poisoned software update to be installed, in a similar fashion to what happened with liblzma and SSH servers. Although far from trivial (in the case of liblzma, it took the attacker roughly three years of work to establish enough trust to become a co-maintainer), this attack scenario may be perpetrated remotely, without the need to acquire a set of credentials or be able to exchange network packets with a target system.
Vulnerability List and Affected Versions
The following table lists the four vulnerabilities found, ordered by CVSS v3.1 base score.
CVE-2024-41173 and CVE-2024-41175 affect the IPC-Diagnostics package included in TwinCAT/BSD up to version 2.0.0.1 (not included).
CVE-2024-41174 affects the IPC-Diagnostics-www package included in TwinCAT/BSD up to version 2.1.1.0 (not included).
CVE-2024-41176 affects the MDP package included in TwinCAT/BSD up to version 1.2.7.0 (not included).
Vulnerability Spotlight
Of the four vulnerabilities found, CVE-2024-41173 and CVE-2024-41175 merit some additional considerations.
CVE-2024-41173 is an authentication bypass vulnerability resulting from an oversight that we have similarly detected in other OT and IoT equipment. Notably, by tracing the flow of HTTP requests received externally from the Beckhoff Device Manager, we discovered that administrative requests are validated by Authelia through Nginx before being forwarded to other internal services, which are only exposed on the loopback interface. However, these latter services omit the authentication level re-verification step, focusing only on dispatching or executing the command received. Consequently, lesser-privileged users who cannot directly send administrative requests from the outside due to Authelia authentication can bypass this protection mechanism simply by authenticating via SSH (SSH access is in fact granted even for low-privileged users through Beckhoff Device Manager as soon they are created) and issue the requests to the internal services.
As one of the administrative requests permits arbitrary deletion and creation of accounts without requiring credentials, an attacker may exploit this vulnerability by deleting the account “Administrator” – the one with the highest privileges on the device – and re-creating it with a new password. At this stage, full control of the device is obtained, and the attacker can reprogram it at will. This attack scenario is represented in Figure 2.
![](https://cdn.prod.website-files.com/645a45d56fc4750d4edd96fe/66c3e9fcca98306f86b07606_66c3e9e9ca98306f86b06944_Beckhoff-Attack-PLC-Tampering.webp)
CVE-2024-41175, by contrast, serves as a yet-another-example of the subtleties to be taken into account when designing a robust parser for externally-received input.
All administrative requests are sent in the form of HTTP POST requests that contain a serialized, base64-encoded payload adhering to a structure defined by Beckhoff. As often happens, strings are serialized using two fields: a fixed-size number representing the length of the string, followed by the actual content of the string itself.
Presumably to handle as many scenarios as possible without requiring continuous code changes, the length of the string was chosen to be represented by a 4-byte unsigned integer. Thus, the maximum possible size of a string that can be communicated to the parsing routine is "0xffffffff", equivalent to approximately 4 GB.
According to tests conducted in our lab on a Beckhoff CX5130 PLC with 4 GB of RAM, if a request containing a string with a declared size of 4 GB is sent to the PLC (without actually including a 4 GB string in the request—merely declaring the string size suffices), the parsing routine attempts to allocate space for this large string. This quickly exhausts the resources available to the PLC and causes it to freeze within seconds. When this happens, the PLC is neither available through the network nor even locally through mouse and keyboard.
Figure 3 contains a snapshot of the output of “ps” a few seconds after sending a similarly crafted request.
![](https://cdn.prod.website-files.com/645a45d56fc4750d4edd96fe/66b17c9a55260ca2a2384319_66b17c7c0fa2f16d9ed2c781_Screenshot%25202024-07-26%2520at%252015.51.51%2520copy.webp)
Remediations
After reporting these vulnerabilities, Beckhoff promptly provided fixed versions of the vulnerable packages. Asset owners can address these vulnerabilities by updating the affected software in their TwinCAT/BSD installations to the following versions:
- IPC-Diagnostics: at least version 2.0.0.1
- IPC-Diagnostics-www: at least version 2.1.1.0
- MDP: at least version 1.2.7.0
If updating these vulnerable packages is not feasible, the following mitigations can be applied to reduce the chances of successful exploitation:
- Keep the number of local accounts entitled to access the PLC running TwinCAT/BSD to the minimum – regardless of their privilege. Ensure that only trusted ones are allowed, and that their passwords are thoroughly protected;
- Log and regularly audit successful logins to the device;
- Thoroughly review third-party applications and packages before installing them on TwinCAT/BSD or updating them.
Asset owners may find all official patches and mitigations for the affected configurations in the official Advisories page in the Beckhoff Information System web portal.