“Evil PLC Attack” arms PLCs to infect engineering workstations

Most attack scenarios against industrial facilities, whether in manufacturing or critical infrastructure, focus on compromising programmable logic controllers (PLCs) to alter the physical processes they control and automate. One way to run malicious code on PLCs is to first compromise a workstation that engineers use to manage and deploy programs on it, but this can be a two-way street: a hacked PLC can also be used to compromise engineering workstations, and this opens the door to powerful lateral movement attacks.

In a new paper published 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 who work on industrial networks every day, configuring and troubleshooting programmable logic controllers to ensure process safety and reliability in critical industries such as utilities, power, water and utilities. wastewater, heavy industry, manufacturing and automotive, among others,” the researchers said.

From malicious bytecode to malicious metadata

A PLC is basically an embedded computer that controls machines, a physical process, or a production line. It has its own processor 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 using specialized engineering software that can be used to write logic code, compile it into a format that the PLC interpreter understands, and deploy it.

With compiled bytecode, also known as ladder logic, PLCs store a complete 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 source code that engineers developed. The PLC doesn’t technically need all of this extra information to function, but it is stored there so that any other engineer connecting to the PLC can get a complete copy of the project running on it so to be able to debug or modify it.

This means that engineering software not only sends data to PLCs, but also reads lots of data and analyzes 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 claim that this proprietary software was not designed on the assumption that the PLCs they connect to and their stored data can be fully trusted, so they lack many security checks for the data analysis that a modern desktop application would have.

That doesn’t mean it’s easy to find vulnerabilities, because each vendor uses their own proprietary communication protocol to write and read data from their controllers, and project files are stored in different packaging formats, some of which are also owners. The researchers had to reverse engineer these protocols and file formats for each of the engineering software analyzed to understand what and how an attacker could modify it on the PLC to attack the connecting workstation.

This resulted in the discovery and reporting of vulnerabilities in:

  • TwinSoft, the engineering software used for OVARRO’s TBOX platform
  • Automation Studio used for the X20 system from B&R (ABB)
  • EcoStruxure Control Expert (Unity Pro) used for Modicon PLCs from Schneider Electric
  • ToolBoxST used by GE’s MarkVIe platform
  • Connected Components Workbench (CCW) used by Rockwell Automation’s Micro Control Systems PLC
  • PAC Machine Edition used by Emerson PAC systems
  • The XD PLC program tool used by XDPPro from Xinje

The flaws ranged from path traversals to heap overflows and insecure deserializations, all leading to the execution of arbitrary code on the engineering machine.

“For each target/platform, we tried to understand the whole upload/download mechanism by reverse engineering the engineering workstation firmware and software,” the researchers said in their article. “Our goal was to find discrepancies between what the PLC uses and what the engineering workstation uses. If we were to find such inconsistencies, we could weaponize the PLC via a malicious download procedure to store a specially crafted data that will not affect the PLC, but when analyzed by the engineering platform will trigger and exploit a vulnerability.”

Lateral movement is the biggest risk

The most obvious goal of such an attack is lateral movement within an organization’s OT (operational technology) network to achieve persistence. Attackers could compromise an engineering workstation that has not been isolated from the organization’s general computer 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 power plant was reportedly deployed by an insider who worked as a mechanic for a third-party company doing work in the central. 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 may have zero-day Windows exploits to create stealthy and sophisticated malware like Stuxnet. They may therefore need another way to spread across the network once they manage to infect a single workstation or poison project files on a PLC. 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 Shodan’s analysis, tens of thousands of SCADA and PLC devices are connected to the Internet. In April 2020, attackers managed to gain remote access to systems used to control water treatment in Israel. In 2021, a similar attack hit Oldsmar’s water treatment facility in Florida.

“Our research suggests that attackers could use internet-connected automata as a pivot point to infiltrate the entire OT network,” the Claroty researchers said. “Instead of simply connecting to the exposed PLCs and altering the logic, attackers could arm those PLCs and deliberately cause a failure that will draw an engineer to them. The engineer, as a diagnostic method, will perform a download procedure that will compromise their machine. Attackers now have their foothold on the OT network.”

Lateral movement via an Evil PLC attack can even occur in all organizations, as many companies rely on system integrators or third-party 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 is maintained by a systems integrator or contractor, they could trigger a fault in the PLC to lure the traveling engineer there and then compromise their computer. This engineer is likely to then connect to other organizations’ OT networks and distribute the malicious payload.

On the other hand, the same attack vector could be turned against potential attackers in a honeypot type scenario where researchers or organizations could intentionally leave a weaponized automaton exposed to the internet and see if attackers target it. Since attackers must use the same engineering software to interact with the PLC, their own machines could be exposed.

“This method can be used to detect attacks at the early stage of enumeration and could also deter attackers from targeting internet-connected automata, as they will need to protect against the target they plan to attack,” said Claroty researchers.

Mitigation of malicious PLC attacks

All vulnerabilities found by Claroty researchers have been reported to the affected manufacturers, who have 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 when available, so that the controller verifies the identity of each engineering workstation that connects to it and can accept connections from specific systems only. .

Network segmentation and hygiene where the 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, if available, is also a good practice, as well as general monitoring of network traffic for suspicious connections.

Copyright © 2022 IDG Communications, Inc.

Comments are closed.