Infecting Ladder Logic Can Beat a PLC

Tuesday, February 21, 2017 @ 03:02 PM gHale

There is a way to beat programmable logic controllers (PLCs) without having to go after the firmware.

Instead, by introducing malware into ladder logic, it is possible to take over a PLC, researchers said. But being aware of that issue, users can learn to defend that type of attack.

Oil and Gas Security ‘Not Keeping Pace’
ARC: Open, Secure Systems Moving Forward
ARC: Take ‘Crown Jewels’ Offline
Lesson Learned: IT-OT Convergence

The trick for the attacker is not to attempt to change the PLC’s firmware, but to deploy ladder logic bombs (LLBs), said a group of researchers from the International Institute of Information Technology, Hyderabad, and Singapore University of Technology and Design, in a paper on the subject.

“Such malware would be inserted by an attacker into existing control logic on a PLC, and either persistently change the behavior, or wait for specific trigger signals to activate malicious behavior. For example, the LLB could replace legitimate sensor readings with manipulated values. We see the concept of LLBs as a generalization of attacks such as the Stuxnet attack,” the researchers said.

“ICS and Supervisory Control and Data Acquisition (SCADA) systems rely on local programmable logic controllers (PLCs) to interface with sensors and actuators. While PLC devices are available from a range of manufacturers, they are all commonly programmed with the same set of programming languages based on IEC 61131-3. In particular, the IEC 61131-3 standard contains ladder logic, functional block diagram, and sequential text as different languages that are used together to define logic to run on the PLCs. The logic is then interpreted by the firmware running on the PLCs,” they said.

They tried to replace a PLC’s firmware with a malicious version and still keep it working, but discovered that it will accept only legitimate, signed firmware, and faking that signature (spoofing the certificate used to signed the firmware) will get you nowhere.

Lack of Ladder Logic Security
On the other hand, there is a distinct lack of security checks/authentication before new logic downloads onto PLCs, and the actual logic executed on the PLCs is not protected by signatures. This vulnerability can be exploited by attackers who gain local physical access to the PLCs, or remote access over the network.

“The security of Cyber Physical Systems (CPS) and related systems has gained a lot of attention. In particular, CPS such as critical infrastructure including power grids, nuclear power plants, and chemical plants are threatened,” the researchers said.

“In CPS, physical-layer interactions between components have to be considered as potential attack vectors, in addition to the conventional network-based attacks. “PLC programs are typically written in a special application on a local host (personal computer), and then downloaded by either a direct-connection cable or over a network to the PLC. The program is stored in the PLC in a non-volatile flash memory,” the researchers said.

“While details differ for platforms from alternative vendors, it might be required to enable remote change of control software on the PLC through a physical switch (i.e., program mode on ControlLogix devices). We observe that due to convenience, in practical systems PLCs are often kept in that setting to allow easy remote access.”

These ladder logic bombs (LLBs) can end up used to change the PLC’s behavior immediately, or can wait for specific trigger signals to begin their work.

Detecting LLBs is not a trivial task for human operators manually validating the code of the program running in PLCs.

Search for Ladder Logic Bombs
The group asked six teams from academia and industry to connect to a virtual operator machine and physical PLCs in the SWaT industrial control system testbed located at the Singapore University of Technology and Design, and to detect three different ladder logic bombs the researchers deployed.

Only one of the teams found all three, and another found one of the LLBs. One of the teams succeeded through an unrelated side-channel, but the rest didn’t find anything.

“In order to detect LLBs, an operator must have sound knowledge of [specific software used to program the controllers] and programming languages like ladder logic, Structure text, and functional block diagram along with its syntactical and semantic meaning. In practice, that can be challenging if an operator has to inspect code with ill-specified functionality or written by a subcontractor,” they said.

Countermeasures for LLB attacks suggest if an intrusion detection system (IDS) is already on the network to monitor traffic for spreading malware or other malicious traffic, then that IDS could potentially end up used to identify the specific traffic related to logic updates on PLCs connected to the network. If unauthorized logic updates over the network end up observed, that could raise an alarm.

The problem with this proposal relates to the identification of authorized logic updates. As we cannot change the traffic generated by the respective software, there is no way to embed specific authentication information. Thus, we can only use information such as IP source address (supposedly related to the authorized person), which is not ideal (as it can end up spoofed).

Our second countermeasure ends up based on two components: A centralized logic store (CLS) of the latest version of logic running on all PLCs of the ICS, and a tool to periodically download currently running logic from the PLCs, and to validate that against the “golden” copy from the CLS.

Leave a Reply

You must be logged in to post a comment.