By Lucian Constantin
CSO Senior Writer, CSO |
Most attack scenarios against industrial installations, whether in manufacturing or in critical infrastructure, focus on compromising programmable logic controllers (PLCs) to tamper with the physical processes they control and automate. One way to get malicious code running on PLCs is to first compromise a workstation that engineers use to manage and deploy programs on them, but this can be a two-way street: A hijacked PLC can also be used to compromise engineering workstations, and this opens the door to powerful lateral movement attacks.
In a new paper released over the weekend, researchers from industrial control systems (ICS) cybersecurity firm Claroty documented proof-of-concept “Evil PLC Attacks” against engineering software from seven ICS manufacturers: Rockwell Automation, Schneider Electric, GE, B&R, Xinje, OVARRO, and Emerson.
“The attack targets engineers working every day on industrial networks, configuring and troubleshooting PLCs to ensure the safety and reliability of processes across critical industries such as utilities, electricity, water and wastewater, heavy industry, manufacturing, and automotive, among others,” the researchers said.
A PLC is essentially an embedded computer that controls machinery, a physical process, or a production line. It has its own CPU and runs a real-time operating system (RTOS) with vendor modifications and a bytecode interpreter. Engineers monitor and program PLCs from computers connected to them by using specialized engineering software that can be used to write the logic code, compile it to a format the PLC interpreter understands and deploy it.
Along with the compiled bytecode, also known as the ladder logic, the PLCs store a full copy of the developed project, including metadata such as program names and symbols, configuration files for hardware and network, memory mappings, I/O settings, variable declarations, parameters, and the source-code that the engineers developed. The PLC technically doesn’t need all this additional information to function, but it is stored there so that any other engineer connecting to the PLC can obtain a full copy of the project running on it so they can debug it or change it.
This means engineering software not only sends data to PLCs but also reads a lot of data back and parses it. Historically parsing data in different formats has been the source of many memory vulnerabilities and this case is no exception. In fact, the researchers argue that this proprietary software was not designed under the premise that the PLCs they connect to and their stored data can be fully trusted, so they lack many of the security checks for data parsing that a modern desktop application would have.
That doesn’t mean that finding vulnerabilities is easy since every vendor uses its own proprietary communication protocol to write and read data from their PLCs and the project files are stored using different packaging formats, some of them also proprietary. The researchers had to reverse-engineer these protocols and file formats for each of the analyzed engineering software so they could understand what and how an attacker could modify it on the PLC to attack the connecting workstation.
This resulted in vulnerabilities being discovered and reported in:
The flaws ranged from path traversals to heap overflows and unsafe deserializations, all resulting in arbitrary code execution on the engineering machine.
“For each target/platform we tried to understand the whole download/upload mechanism by reverse engineering the firmware and the engineering workstation software,” the researchers said in their paper. “Our goal was to find discrepancies between what the PLC is using and what engineering workstation is using. If we were to find such inconsistencies, we could weaponize the PLC through a malicious download procedure to store a specifically crafted piece of data that won’t affect the PLC, but when parsed by the engineering platform it will trigger and exploit a vulnerability.”
The most obvious goal of such an attack is lateral movement inside an organization’s OT (operational technology) network to achieve persistence. Attackers could compromise one engineering workstation that has not been isolated from the organization’s general IT network or could even use an insider to plant malware on it.
For example, the Stuxnet worm that was used to destroy uranium enrichment centrifuges inside Iran’s Natanz nuclear plant is believed to have been deployed by an insider who worked as a mechanic for a third-party company doing work at the plant. Once deployed on a machine inside, the worm found its way to the PLCs controlling the centrifuges using a chain of zero-day exploits and sophisticated techniques.
Not all attackers might have Windows zero-day exploits available to build stealthy and sophisticated malware like Stuxnet, so they might need another way to spread through the network once they manage to infect a single workstation or poisoning the project files on a PLC is one way to do it.
PLCs can also be compromised remotely because many of them are connected to the internet through various remote management interfaces. According to scans on Shodan there are tens of thousands of SCADA and PLC devices connected to the internet. In April 2020, attackers managed to remotely gain access to systems used to control water treatment in Israel. In 2021, a similar attack impacted Oldsmar water treatment facility in Florida.
“Our research suggests that attackers could use the internet-facing PLCs as a pivot point to infiltrate the entire OT network,” the Claroty researchers said. “Instead of simply connecting to the exposed PLCs and modifying the logic, attackers could arm these PLCs and deliberately cause a fault that will lure an engineer to them. The engineer, as a method of diagnostics, will perform an upload procedure that will compromise their machine. The attackers now have their foothold on the OT network.”
The lateral movement through an Evil PLC attack can even happen across organizations because many companies rely on third-party system integrators or contractors to manage their PLCs, especially those deployed in remote locations. If attackers compromise such a PLC in a less secure location and know that it’s being serviced by a systems integrator or contractor, they could trigger a fault in the PLC to lure the traveling engineer to it and then compromise their computer. That engineer is likely to then connect to the OT networks of other organizations and spread the malicious payload.
On the other hand, the same attack vector could be turned against would-be attackers in a honeypot-like scenario where researchers or organizations could intentionally leave a weaponized PLC exposed to the internet and see if attackers target it. Since attackers have to use the same engineering software to interact with the PLC, their own machines could be exposed.
“This method can be used to detect attacks in the early stage of enumeration and might also deter attackers from targeting internet-facing PLCs since they will need to secure themselves against the target they planned to attack,” the Claroty researchers said.
All the vulnerabilities found by the Claroty researchers have been reported to the impacted manufacturers, who released patches or mitigation instructions. However, deploying patches inside OT networks can be a slow process. The researchers recommend that organizations deploy client authentication mechanisms where available, so that the PLC verifies the identity of every engineering workstation connecting to it and can accept connections from only specific systems.
Network segmentation and hygiene where different segments of the network that don’t need to talk to each other are isolated is also very important. Enabling traffic encryption and public-key authentication between PLCs and engineering workstations, where available, is also a good practice as well as general network traffic monitoring for suspicious connections.
Lucian Constantin is a senior writer at CSO, covering information security, privacy, and data protection.
Copyright © 2022 IDG Communications, Inc.
Copyright © 2022 IDG Communications, Inc.