PLCs / Networking / Remote Monitoring & Access

How to hack programmable logic controllers

PLC cyber attacks become models for security

By Dr. Siv Hilde Houmb, Norwegian University of Science and Technology (NTNU)

Since the late 1980s when the Morris worm, one of the first-ever Internet worms, was launched by a Cornell graduate student from a computer system at the Massachusetts Institute of Technology, cyber attacks have become big business.

The Morris worm’s creator has indicated his virus was designed to be random and harmless, despite its unintended destructiveness, but today’s attacks are targeted and represent a significant threat to economic growth and safety. Cyber attacks have even been adopted as war strategies by some nations. Cybercrime will cost the world $6 trillion annually by 2021, up from $3 trillion in 2015, according to Cybersecurity Ventures’ Official 2017 Annual Cybercrime Report, which also predicts that investments in cybersecurity products and services will exceed $1 trillion cumulatively over the next five years.

Gartner estimates that cybersecurity spending will reach $96 billion in 2018. Part of the reason for this increase in spending is the expansion of interconnectivity and remote connection to earlier isolated industrial automation and control systems, as well as critical infrastructure, which is a fundamental necessity in the modern digitalized society.

Critical infrastructure comprises a number of automation systems, controls and other types of computerization. Programmable logic controllers (PLCs) are vital components to these systems. For example, PLCs are used for automating and controlling machinery for manufacturing, assembly and conveyance, as well as power grids, railways and airports.

There are billions of unsecured PLCs, most of which are older PLCs with very little or no built-in protection mechanisms. This represents a major cybersecurity challenge. As PLCs are used to control power grids, it could be possible to shut down the power by taking control over the PLCs in the power grid, causing a similar situation as with the Ukraine power-grid attack, which took place on December 23, 2015. Several hundred thousands of subscribers lost power for several hours, and the operators were rendered unable to take control of the shutdown without first taking control of the cyber attack.

Securing PLCs was earlier not considered a priority; these components are built to run in isolation and in an air-gapped environment. This is no longer the case in many circumstances, due to the increase in real-time and remote data collection, as well as the increase in remote monitoring and efficient maintenance.

Some PLCs are even exposed to the Internet. Since the Ukraine power-grid attack, it has become clear that no system is resilient to cyber attack and that PLCs could be targeted. For example, numerous PLC cyber attacks have been presented at Black Hat, the world´s largest hacker conference, in 2016 and 2017. Currently, the following types of PLC attacks are of concern to the industry: remote-access attacks on Internet-facing PLCs; PLC worms; payload sabotage attacks; and PLC rootkits.

White Paper: Guide to the Industrial Internet of Things

What’s a PLC for?

PLCs makes up part of Level 1: Basic Control in the Purdue model (ISA99), which is a reference architecture for the industrial automation and control system (IACS) security (Figure 1). The Purdue model provides a structured architectural overview of IACS by dividing it into four zones: safety, cell/area, manufacturing and enterprise. While the actual deployment of an IACS in the field might differ from the Purdue model, the principle of separating safety systems from the control and automation systems are most often followed.

The air-gapped approach to cybersecurity in these cases is implemented by ensuring multiple layers between the PLCs and the enterprise network and Internet access. However, as real-time-data and remote-access needs have increased, so has the number of connections into the control and automation systems. This is further enhanced by introducing the Industrial Internet of Things (IIoT) and its components into both the control and process layers (Level 0 and Level 1), as these often require an Internet connection to distribute sensor, process and controls data in real time or near real time.

When implementing such devices, the layered approach is very often compromised and, rather than providing the connection through the enterprise and manufacturing zones, sometimes Internet access or private- or public-cloud access is provided directly into the controls layer. This bypasses the perimeter defense often established around the cell or area zone, and therefore the cyber-resilience capabilities need to be built into these devices.

Another cybersecurity challenge is the presence of insiders, who either knowingly or unknowingly introduce cybersecurity issues by using their own laptops, which might be infected; downloading software or patches to the engineering laptop or programming devices in the controls layer; or introducing malware through USB, smart phones or similar lightweight or personal devices. In fact, most of the cyber attacks targeting PLCs have been introduced by an insider, either directly or indirectly.

As with other types of computerized systems, a cyber attack on a PLC could target confidentiality, integrity, availability or any combination of these. Confidentiality in this respect would most likely target the details on the PLCs itself—hardware, logic and firmware—and the PLC program with the intention of preparing a follow-up attack, such as various forms of sabotage of the equipment controlled by the PLC.

Such espionage software could be planted remotely on the engineering station, programming device or HMI, for example, or could be introduced through a USB or a software update locally on the PLC. The new generation of cyber attacks, also referred to as advanced persistent threats (APTs) very often first plant espionage software and then use this to set up a connection from the PLC or the engineering station to a command and control center for the purpose of downloading additional malware. This was done in the Stuxnet attack, for example, and is an essential component of a stealthy APT.

Another alternative to gain access is to search for Internet-facing PLCs using the tool Shodan—an online tool that enables a rather extensive search for PLCs that can somehow be reached from the Internet. For PLCs that are directly accessible, even though it is only the PLC Web server that is accessible, directly from the Internet there are a number of remote-access attacks that could be carried out, including denial-of-service (DoS) attacks and integrity attacks such as downloading and overwriting the PLC program with a sabotage PLC program. Doing so compromises the integrity of the PLC.

There are also examples of more sophisticated integrity attacks on PLCs, such as payload sabotage and PLC rootkits, which were presented at Black Hat Europe 2016. The PLC rootkit attack comprises three main attack steps (Figure 2). Step 1 focuses on gaining authorized access to the PLC. Step 2 focuses on mapping the input and output modules and their locations in the memory with the purpose of overwriting input and output parameters. Finally, Step 3 is manipulating the input and output initialization sequence and by doing so taking control over the input and output handling of the PLC. This attack has also been referred to as a PLC ghost attack.

The PLC rootkit attack and similar cyber attacks on PLCs are made possible through gaining access to the PLC, either directly or through the engineering station where the PLCs are programmed and where the PLC program is being updated and pushed to the PLC.

The main purpose of a PLC in an IACS is to control or automate mechanical equipment of some sort. The PLC is therefore connected to the mechanical equipment and often monitored and maintained through an HMI, which could be embedded in the PLC or run on a separate entity such as a standard Windows computer (Figure 3). The HMI is the entity communicating with the operator.

The Stuxnet attack was made possible because of a Windows-based HMI and multiple zero-day vulnerabilities—previously unknown vulnerabilities, which means that no patch for the vulnerabilities exists as the vulnerability had not been discovered yet. The PLC was manipulated such that the mechanical equipment—in this case, centrifuges—misbehaved and eventually broke, while the HMI did not report the abnormal situation to the operator leaving them unaware of the situation. This way the attack was executed without the operator having any chance of discovering it before the equipment was already damaged.

To take control of a PLC using a cyber attack requires a deep understanding of the architecture of a PLC. A PLC has different types of internal components. Some of these are a processor, memory, power supply, backup battery and input/output modules (Figure 4). A PLC is a dedicated controller, which will execute the same program in a loop. Running the program once is defined as a scan time. The scan time is processed in milliseconds by the central processing unit (CPU). The output modules are controlled by the results of the input module. If certain conditions are met within the ladder program and input devices, the PLC executes commands on its output module. The memory is stored within the CPU while executing the program. However, the PLC also stores the results from the I/O modules.

The PLC rootkit attack manipulated input and output initialization and could therefore control all input and output processing, and it therefore had full control of the PLC.

Internal affairs

By manipulating input and output, the attacker can take control of the behavior of the mechanical equipment and can sabotage or destroy it.

The CPU has two modes: programming mode and run mode. During programming mode, the PLC downloads code remotely from a computer, while the run mode executes the actual code.

By gaining access to the PLC or the programming device, an attack can download malware code to the PLC. The memory within the CPU stores the program received from the programming device, and the malware would then be stored in the memory of the PLC and be executed instead of the original program.

The programming device is a separate engineering computer or an HMI and contains programming software provided by the PLC manufacturer. Switches and sensors are some of the components which can be connected to the PLC’s input module.

When the criteria are met within the program located in the PLC memory, the output module will release an output signal, triggering an internal relay. Both the input module and the output module are capable of processing digital and analog signals. A digital signal is referred to as “on and off,” which is either a 0 or 24-V signal. The analog signal is thoroughly regulated between 0-10 V, depending on the component’s value. The 24-V output signal can trigger, for example, relays, frequency converters and electric motors.

By manipulating input and output, the attacker can take control of the behavior of the mechanical equipment and can sabotage or destroy it. This was demonstrated in the PLC rootkit attack in a manner that would not be detected by the operator before it would be too late.

Snug as a bug?

Modern PLCs, meaning thosemanufactured after the Stuxnet attack, have some built-in security protection, especially authorization and access control. Some modern PLCs also support integrity checking and encryption of communication. This provides basic protection from manipulating firmware or memory blocks in cases where integrity checking is enforced on both firmware and the memory blocks. However, this does not prevent taking control of the PLC through the Web server to shut down the PLC.

Attacking the PLC Web server could also be a method for gaining knowledge on the administrator username and password through using modified brute-force dictionary attacks on the login form.

Protecting PLCs from cyber attacks requires a multi-layered approach. The earlier isolation assumption and the notion of IACS being air-gapped can no longer be the basis for cyber-attack protection, or cyber resilience. It is necessary to build cyber resilience into the PLC itself, as well as the surrounding devices, including the programming device and HMI. Although newer-generation PLCs provide solutions for authentication, authorization, integrity control and encryption, it is essential to remember that these mechanisms only represent a subset of the necessary security mechanisms to ensure sustainable cyber resilience.

It is not merely enough to aim for compliance with ISA/IEC 62443, as this standard is still under development and as cyber attacks on PLCs are a new venue for the hacking community. It will be necessary to adopt an approach to securing PLCs that is based on any given point in time’s newest knowledge on PLC cyber attacks, which is a major challenge due to the 24/7/365 requirement of the IACS.

ALSO READ: DOD-backed DMDII Cyber Hub for Manufacturing enables cybersecurity technology experimentation for factory floor