Claroty's Team82 has researched the exploitability of cloud-based management platforms responsible for monitoring and configuring industrial control systems (ICS).
The momentum of adopting cloud for industrial control systems (ICS) is undeniable, motivating Team82 to examine the security of these platforms and architectures.
Team82 developed techniques to exploit vulnerabilities in automation vendor CODESYS's Automation Server through two unique attack vectors.
The research also included the discovery of vulnerabilities in the WAGO PLC platform and the development of a complex exploit chain to attack a single cloud-managed PLC and eventually take over the cloud-based host account.
All of the vulnerabilities found and disclosed by Team82 have been fixed or mitigated by CODESYS and WAGO. Please reference the table below.
Bottom Up: From a Single PLC to the Entire Cloud-Based Network
Adding a Malicious User to the Management Console Using a Compromised PLC
Vendor | CVE | CWE | Product |
| CODESYS | CVE-2021-29241 | CWE-476: NULL Pointer Dereference | Gateway V3 |
| CODESYS | CVE-2021-29240 | CWE-345: Insufficient Verification of Data Authenticity | Package Manager |
| CODESYS | CVE-2021-29238 | CWE-352: Cross-Site Request Forgery (CSRF) | Automation Server |
| WAGO | CVE-2021-34566 | CWE-120: Shared Memory Overflow | WAGO PFC iocheckd service |
| WAGO | CVE-2021-34567 | CWE-125: Out-of-bounds Read | WAGO PFC iocheckd service |
| WAGO | CVE-2021-34568 | CWE-770: Allocation of Resources Without Limits or Throttling | WAGO PFC iocheckd service |
| WAGO | CVE-2021-34569 | CWE-787: Out-of-bounds Write | WAGO PFC diagnostic tools |
Industry 4.0—the automation of industrial processes—is putting pressure on operational technology (OT) to stay relevant in today's interconnected world.
Many organizations are eager to enjoy the benefits of centralized cloud-based management of industrial control systems (ICS) and OT. But doing so without security considerations can bring unnecessary risk. A vulnerability in a Purdue Model Level 0/1 device such as a programmable logic controller (PLC) can be leveraged to launch attacks targeting a cloud-based management system. And the reverse is also true: weaknesses in the cloud platform and its peripherals can put an attacker in the driver's seat for uncontrolled access to field devices and industrial processes.
The momentum behind bringing cloud capabilities to ICS is undeniable for a number of reasons, including better telemetry and analysis of device performance, management of logic and remote device configuration, improved diagnostics and troubleshooting, a centralized view of processes, and redundancy, which is critical to business continuity.
These realities are what motivated Claroty's Team82 to research the exploitability of cloud-based management systems for ICS and examine the viability of both top-down and bottom-up attacks against cloud implementations to gain access to field devices, as well as exploits of field devices such as PLCs in a manner that would allow an attacker to use them to overtake a cloud-based management system.
Team82 was able to find critical vulnerabilities in market-leading PLCs sold by WAGO Corp., as well as CODESYS's Automation Server platform that manages industrial devices from the cloud. Team82 was able to leverage those vulnerabilities and turn them into innovative attacks that could put threat actors in position to remotely control a company's cloud OT implementation and threaten any industrial process managed from the cloud. The flaws Team82 disclosed are remotely exploitable and can be used to target a cloud-based management console from a compromised field device or take over a company's cloud and attack PLCs and other devices to disrupt operations.
This report examines what makes up a cloud-based OT and SCADA infrastructure and the attack surface available to attackers, before diving into Team82's research, the vulnerabilities we disclosed, the attacks we developed, and recommendations to keep OT cloud implementations safe.
When referring to the cloud, we are usually referring to the portion of a company's IT or OT infrastructure that is hosted on the remote, internet-facing servers of predominant providers, such as Amazon Web Services, Google Cloud Platform, or Microsoft Azure. Part of that infrastructure includes hosted applications that leverage a cloud-based management console supporting different users, including OT engineers, managers, and administrators. Each user has a specific role, and the management console needs to support different kinds of functionality to the SCADA network based on the offered services declared by the vendor. Those functionalities include the ability to download configuration files to PLCs, collect tags data from PLCs, or provide HMI-like web-based screens.
There are many ways to integrate SCADA devices with the cloud, but overall the idea is the same. At the top of the architecture, we have the different users and their machines which interact with the cloud-based management console. Through the management console, operators and administrators tune settings, including specifications for which devices are commissioned and configured. These settings also dictate the logic that needs to be executed by the PLCs and configure what data points (tags) will be collected and presented by the management console's view screens.
At a low level of the architecture are Level 1 devices, such as PLCs, which are located at the site level and execute logic that eventually controls Level 0 devices, such as actuators and sensors. The logic can be hosted on the PLC, which transfers data to the cloud.
Traditional attacks against cloud-based platforms are valid against OT infrastructure too, and similarly, are focused on exposing the internal network to new types of attacks. In general, the risk can be divided into a couple of categories, including:
Loss of control over data: If data is stored outside the network, it may be exposed to unauthorized third parties. In addition, there is no guarantee the data lies encrypted and its owner has control over what happens with the data on the cloud provider's servers.
Expanded internet-facing attack surface: Since the cloud platform must be managed, typically using a cloud-based management console interface, this also introduces a newly expanded attack surface. Attackers interact with the internet-accessible management console to find web-based vulnerabilities, such as SQL injection and path-traversal vulnerabilities (see for example our Cassia Networks Access Controller server vulnerability), or even utilize zero-day exploits against cloud instances. All of this was not possible when infrastructure was located internally on the OT network, behind network address translation (NAT) and firewalls.
This is the context behind Team82's research into exploiting cloud-based platforms responsible for managing OT and ICS devices. The goal was to find innovative attack vectors that allowed us to control not only devices, but also management interfaces in the cloud. These are real risks to organizations adopting cloud for OT management, and threats that attackers would likely try to exploit. Here are two approaches Team82 developed:
Top-Down: Team82's top-down approach starts with obtaining unauthorized access to an operator account using different methods. For example, one of the methods used involves exploits against the platform peripherals, such as software that communicates with the cloud-based management console. Another option to obtain unauthorized access to the management console is through social engineering in order to steal credentials. From the cloud-based management console, an attacker can control all managed devices and exploit these further to get unrestricted access to the endpoints.
Bottom-Up: Team82's bottom-up approach, meanwhile, begins with attacks against endpoint devices, such as PLCs. The assumption is that attackers will gain network access to an edge-device and will exploit it using a remote code execution vulnerability. Next, they will use the hacked device as a trap to go upstream to the cloud-based console management. There are many options here, depending on the specific architecture of the platform. For example, one would be the injection of a malicious payload onto a web page hosted on the endpoint device that will be later viewed by one of the system operators. Once viewed by a platform user, the malicious payload will steal credentials and take control of—or add—an administrator account to the cloud-based console. Finally, the attacker will leverage the power of the management console to interact with and modify logic, data, and configurations on the managed devices.
We will demonstrate the discussed concepts by showing our attacks against the cloud-based CODESYS Automation Server platform and WAGO PLCs.
CODESYS is a development environment for programming controller applications according to the international industrial standard IEC 61131-3. The main product of the software suite is the CODESYS Development System, which enables programming and configuration of PLCs.
To ease development cycles, CODESYS also released a dedicated application store, from which developers can download packages and libraries to integrate with their PLC application logic. This greatly shortens development cycles and allows developers to sell their work for a price through the marketplace.
Recently, CODESYS has also developed a cloud-based platform named Automation Server to manage PLCs remotely. OT engineers using this platform can download logic and configure their PLCs through the cloud-based Automation Server management console.
WAGO PFC100/200 is a series of PLCs that make heavy use of the CODESYS runtime, and in fact, most of the communication, configuration, and programming of these PLCs is done through the CODESYS platform. These devices can also be managed by the CODESYS Automation Server platform, and engineers can remotely download logic to them.
In a bottom-up version of Team82's attack, endpoint devices (Level 1 of the Purdue Model) are targeted, and attackers move their way up to the cloud-based management console. This means they will first try to find vulnerabilities to exploit in the PLC. By taking a "red-team" approach, Team82 tried to do the same, starting with its research into the WAGO platform.
Team82 was able to achieve this on the CODESYS Automation Server and WAGO PLC platforms through the following steps:
Exploit a pre-auth remote code execution vulnerability on a WAGO PLC.
Exploit a bug in the integrated CODESYS WebVisu feature to add a new user to the cloud-based platform.
Take over the CODESYS Automation Server account.
WAGO PFC devices use the iocheckd management protocol on TCP port 6626. The management protocol is used for initial setup and configuration of the PFC device, is active by default, and remains open after the initial configuration.
In order to achieve a pre-auth remote code execution on the WAGO device, we used two vulnerabilities that we found in the iocheckd protocol: CVE-2021-34566 and CVE-2021-34567. We were able to chain exploits together in a unique way that enabled us to remotely attack the device and implant a webshell for further interaction and command execution.
The management protocol allows for reading and writing variables; some variables store or read the data from shm memory. This lets us read or write to the shm memory using some of the protocol commands. Table99 is one of the tables stored in the shm memory, and it is possible to read and write to/from it from other processes for inter-process communications.
Through reverse-engineering the iocheckd binary, we found that the size of table99 in the shared memory is 1400 bytes long. The WriteRegister99 protocol command allows writing data to table99, but it fails to verify that the write length defined in the count parameter is less than 1400 bytes, thus making it possible to overflow into other memory segments of the iocheckd process. This can lead to the crash of the iocheckd process and the writing of large memory sections in the attacker's control.
The data of the protocol response is copied to the frameBytes variable without checking its length before the copy; frameBytes is a stack-based buffer that is 1400 bytes long. Therefore, any response longer than 1400 bytes will overflow onto the stack. This can lead to remote code execution by smashing the stack.
Using the write overflow in table99, we are able to write memory, that when read by the read_register, will overflow with data we control. We were able to write a full proof-of-concept exploit demonstrating pre-auth remote code execution using these two primitives.
Now that we have a pre-auth remote code execution, we are ready to target the cloud-based management console and gain control over the entire network. To achieve this, we exploited a flaw in the WebVisu feature of the CODESYS Automation Server.
The CODESYS cloud integration allows users to view the WebVisu web page of their PLC from the cloud, allowing them to limit the remote access to the PLC's HTTP server. This is a useful cloud feature, but during our research, we found a way to use it to obtain cloud credentials from a compromised PLC.
Before fixing CVE-2021-29238, CODESYS Automation Server pages did not contain CSRF tokens. This means that if attackers were able to control JavaScript/HTML on any page that contains the user's CODESYS cloud-based Automation Server cookie (CAS), they could issue HTTP requests on the user's behalf and, for example, add a secret user to the CODESYS cloud platform on behalf of the currently logged on CODESYS user. In our proof-of-concept, below, we showed how WebVisu HTML pages can be used in such an attack.
When an authenticated user views the webvisu page, a request with his CAS cookie will be made to the cloud server. In case of the example shown below, a new user with admin permissions will be created.
An attacker that obtains access to a PLC managed by the Automation Server Cloud can modify the webvisu.js file and append JavaScript code to the end of the file that will send a malicious request to the cloud server on behalf of the logged-in user. When a cloud user views the WebVisu page, the modified JavaScript will exploit the lack of CSRF token and run in the context of the user viewing it; the request will include the CAS cookie. Attackers can use this to POST to /api/db/User with a new administrator user, giving them full access to the CODESYS cloud platform, below.
In a typical, isolated OT network, attackers would need to first gain access to an air-gapped industrial network in order to control and manage PLCs. To compromise the entire operation at each site, attackers would need to gain access to each site individually. However, in the new Industry 4.0 era where Level 1 devices are connected to the cloud, attackers would only need to obtain the credentials to the cloud in order to take over the entire network.
In the second attack vector we used, Team82 demonstrated how compromising the CODESYS engineering machine could allow attackers to steal cloud credentials. Once an attacker is able to log in to the cloud, it's game over. The attacker will have the ability to deploy malicious applications to ALL connected devices.
From a high-level perspective, the attack goes as follows:
The attackers create a malicious package that, once installed, leaks the saved cloud username and password.
Attackers manage to get OT engineers to install the malicious package (by social engineering, or by submitting a malicious code package to the CODESYS store, for example).
Using the OT engineer's leaked Automation Server credentials, attackers modify the currently configured projects and add a malicious task that will, for example, run a reverse shell on the PLC.
Attackers deploy a rogue project to all connected PLCs and get unauthorized access to the entire PLC fleet.
CODESYS packages are ZIP-based files with the *.package extension. They are used to extend the standard installation of the CODESYS development environment platform with additional features and configuration settings. These packages can be purchased from the CODESYS store; before CODESYS added signature verification in response to Team82's disclosure, it was also possible to receive unsigned packages from individual developers.
Some packages from the CODESYS Store contain library (.DLL) dependencies. If attackers are able to submit a package to the store or convince an operator to install their package with social engineering, they are able to execute code on the targeted Windows machine.
In our proof-of-concept, we demonstrate how a modified CODESYS "Package Designer" package could be maliciously modified to retrieve the user's cloud credentials after they install it. The vulnerability we exploited stems from a lack of verification of the package source and its contents. This makes it trivial to create a legitimate-looking CODESYS package that executes malicious code.
Once attackers gain access to the cloud-based management console, they have a wide attack surface to work with. The simplest thing attackers can do is modify or even stop the logic currently running on managed PLCs. For example, an attacker could stop a PLC program responsible for temperature regulation of the production line, or change centrifuge speeds as was the case with Stuxnet. These types of attacks could lead to real-life damage and affect production times and availability.
Another, more complex option, is to find an exploit in the PLC logic execution in order to escape the PLC sandbox where code executes, as we recently demonstrated with Siemens PLCs. We will not discuss details of sandbox escapes in this report, but similar types of attacks can be found in recent publications on CODESYS v2 vulnerabilities. These types of attacks enable attackers to gain complete access to the PLC and execute native code without PLC logic-execution restrictions.
The momentum behind OT adopting cloud is moving at a brisk pace. In the past, we've learned difficult lessons about other technologies that were quickly evolved and adopted without adequate consideration for security. We'd do well to heed those lessons again, today. Organizations moving forward with cloud-based management of OT and ICS devices must be aware of inherent risks, and increased threats against industrial targets using ransomware, or sophisticated attacks causing physical damage.
In response, Claroty's Team82 researched the exploitability of cloud-based management platforms responsible for monitoring ICS, and developed techniques to exploit vulnerabilities in automation vendor CODESYS' Automation Server and vulnerabilities in the WAGO PLC platform. Team82's research mimics the top-down and bottom-up paths an attacker would take to either control a Level 1 device in order to eventually compromise the cloud-based management console, or the reverse, commandeer the cloud in order to manipulate all networked field devices.
Companies in the Industry 4.0 era are adopting cloud technology as it relates to IIoT and OT to reap the rewards of simplified management, better business continuity, and improved performance analytics, among others. They must also implement stringent security measures to secure data in transit and at rest, in addition to locking down permissions. At a minimum, credentials must be secured using two-factor authentication, roles must be defined, permissions carefully orchestrated, and identities managed as a crucial defense-in-depth step for cloud.
In addition, Team82 makes the following recommendations:
Treat all cloud-connected solutions as a trusted communication to your industrial network, and implement a supply chain risk management program that includes gaining insights into supplier's security program.
Know that existing solutions that aren't cloud-connected may be connected in their next upgrade—active monitoring of industrial assets are critical to detect unexpected connections to vendors' networks, so you can re-assess the risk and take steps to mitigate as required.
Implement a zero-trust architecture and policies to limit unexpected communications from traversing the industrial network.
While an in-line exploit of a trusted cloud connection is almost impossible to detect, an attacker will likely next attempt to move laterally to compromise other systems within the industrial network. Ensure you have monitoring capabilities established to identify unexpected lateral movement communications from critical assets.
Ensure your security operations center (SOC) and incident response teams are ready to respond in a timely and appropriate manner to industrial network incidents. SOC teams are often IT-centric, and some of their playbooks may need to be updated for OT environment considerations. Consider a retainer incident-response service as well to ensure rapid response in the event of an incident.
Team82 would like to thank the CODESYS and WAGO teams for their swift response, not only on our coordinated disclosure, but also with their updates and mitigations—including CODESYS rolling out multi-factor authentication—that benefit their customers and the ICS domain.
CWE-345: INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY
The Package Manager of the CODESYS Development System does not check the validity of packages before installation and may be used to install CODESYS packages with malicious content.
Read more: "Top-Down and Bottom-Up: Exploiting Vulnerabilities in the OT Cloud Era"
CVSS v3: 7.8
CWE-476: NULL POINTER DEREFERENCE
Crafted communication requests may cause a Null pointer dereference in the affected CODESYS products and may result in a denial-of-service condition.
CVSS v3: 7.5
CWE-352: CROSS-SITE REQUEST FORGERY
Manipulated files of a CODESYS Web Visualization deployed on a controller can lead to a privilege escalation when the Web Visualization is opened with the CODESYS Automation Server.
Read more: "Top-Down and Bottom-Up: Exploiting Vulnerabilities in the OT Cloud Era"
CVSS v3: 8.0
CWE-125 OUT OF BOUNDS READ:
An attacker can send a specially crafted packet containing OS commands to provoke a denial of service and an out-of-bounds read.
Read more: "Top-Down and Bottom-Up: Exploiting Vulnerabilities in the OT Cloud Era"
CVSS v3: 8.2
CWE-787 OUT OF BOUNDS WRITE:
An attacker can send a specially crafted packet containing OS commands to crash the diagnostic tool and write memory.
CVSS v3: 10
CWE-770 ALLOCATION OF RESOURCES WITHOUT LIMITS OR THROTTLING:
An attacker can send a specially crafted packet containing OS commands to provoke a denial of service.
CVSS v3: 7.5
CWE-120 SHARED MEMORY OVERFLOW:
An attacker can send a specially crafted packet containing OS commands to crash the iocheck process and write memory.
CVSS v3: 9.1
