Research on PLC Attack Paths in Industrial Control Systems Security

With continuous technological advancements, PLC is evolving towards intelligence, with an increasing number and types of interfaces and an ever-expanding range of functions. Current PLCs are generally based on trimmed embedded systems, transferring communication protocols originally located on serial links to TCP/IP, thereby providing convenient pathways for hackers to implement attacks.

1. Attacking Through Embedded System Vulnerabilities

The majority of PLCs use trimmed real-time operating systems (RTOS), such as Linux RT, QNX, Lynx, VxWorks, etc. These operating systems are widely applied in fields requiring high precision and real-time performance, such as communications, military, aviation, and aerospace. However, their security issues cannot be overlooked. Common operating systems used by PLCs are shown in Table 1.

Table 1 Common Operating Systems for PLCs

Beresford et al. [1] pointed out that Simatic PLC runs on an x86 Linux system, which means that if a payload is inserted, the shell can be compromised, connecting to the device. It is particularly important to note that all programs running on the PLC operate with root privileges; once compromised by an attacker, the consequences could be severe. As shown in Figure 1:

Figure 1 Shell System Compromise

Many PLC devices from Siemens and Schneider run software on the VxWorks system, where wdbrpc is the remote debugging port that communicates via UDP, with port number 17185. This protocol is based on sun-rpc and primarily supports remote interaction through the integrated development environment Tornado (as shown in Figure 2). According to data published by Lighthouse Labs [2], hackers can use the wdbrpc protocol to dump all memory space data, finding all ftp and telnet login passwords in memory, which can lead to further attacks such as modifying the bootline to bypass login verification and dumping memory data to capture login passwords. This allows control over the normal operation of the PLC through attacks on the embedded real-time operating system.

Figure 2 Tornado Development Environment and VxWorks System Diagram

2. Attacking Through PLC Communication Protocol Vulnerabilities

Common industrial control protocols contain a large number of command words, such as reading and writing data. However, some advanced or custom functions defined by the protocol often pose greater security threats to users. For example, the slave diagnostic command of the Modbus protocol can cause the slave device to switch to listening mode, certain command words in the CIP protocol can cause direct device reboots, and the STOP CPU function of the S7 protocol can halt the operation of the PLC program. In most cases, users only utilize certain data reading functionalities and fixed-range, fixed-address writing functionalities when configuring the upper computer, while many more functionalities on the protocol stack are not applied in system integration.

Langner et al. [3] pointed out that no internal knowledge of the control system or programming skills are needed to execute an attack. By exploiting vulnerabilities in the S7 protocol, attackers can inject code before the configuration OB1 (equivalent to the main function), so that the PLC will execute malicious code before each scan, and can terminate the execution of legitimate code at any time by calling the BEC (block end condition) instruction. In the case of Stuxnet, the termination conditions were based on time and industrial processes.

Meixell et al. [4] noted that simple serial protocols (like Modbus and DNP3) have been encapsulated in IP datagrams, allowing attackers to construct an IP-based control data packet and send it to the PLC, resulting in serious consequences. For instance, with the Modbus protocol, the commonly used function code is shown in Table 2, where function code 0x05 can set all registers to 1, opening all valves.

Table 2 Modbus Data Packet Structure and Main Function Codes

Tzokatziou et al. [5] pointed out that since PLC communication protocols transmit in plaintext and do not authenticate communication parties, attackers can use the CoDeSys system to connect directly to the PLC, capture the data packets exchanged between them, and then send the modified control commands to the PLC, achieving arbitrary start and stop operations.

3. Attacking Through PLC Software Vulnerabilities

The software systems of PLCs include system monitoring software and user configuration software; the former is used to monitor the operation of the controller itself, while the latter is used to write user programs. For example, Siemens PLC uses STEP 7 programming software for programming, parameter settings, and online debugging, while WinCC is primarily used for process monitoring.

A typical attack case is the 2010 Stuxnet virus attack on the Iranian nuclear power plant [6]. The Stuxnet virus exploited four 0-day vulnerabilities in the Windows operating system and also utilized two vulnerabilities in Siemens WinCC: (1) A hard-coded vulnerability in the WinCC system saved the default account name and password for accessing data, which Stuxnet tried to use to access the SQL database of the system; (2) In the Step7 project needed for WinCC, there was a flaw in the DLL loading policy when opening project files, leading to a DLL preloading attack. Stuxnet replaced the s7otbxsx.dll in the Step7 software with its own version to hook some query and read functions.

Other attack pathways include targeting the Human-Machine Interface (HMI), causing operators to lose visibility. A typical attack case is the 2015 cyber attack on the Ukrainian power grid [7]. Attackers gained control of workstation nodes, obtaining an operational interface and permissions identical to the operators, allowing them to remotely control the PLC for switching operations or changing operational parameters, leading to power grid failures or outages. Lighthouse Labs pointed out [8] that Unity Pro is the programming software for Schneider PLCs, and the OSLoader software that comes with Unity Pro can perform firmware upgrades for the PLC. Once OSLoader logs into the device, it attempts to read the file system remotely, enabling remote uploads and downloads, allowing attackers to easily cause the PLC to crash by replacing the firmware.

4. Attacking Through PLC Interconnections

Current industrial control networks are evolving towards a “one network to the end” direction, with tighter horizontal and vertical connections in industrial control systems: the business layer can directly access control layer data and even control devices; devices at the same level are linked together due to their collaborative work. For PLCs, since they are primarily used for process control, and production processes often consist of multiple control processes, multiple PLCs need to work together to complete a specific production task.

Figure 3 Attacking PLC Processes via Human-Machine Interface

Radvanovsky et al. [9] pointed out that the SHINE (SHodan Intelligence Extraction) project initiated by the US aims to extract information about SCADA and ICS devices accessible from the Internet (especially PLCs and RTUs). The SHODAN search engine operates by searching common TCP/UDP ports, as shown in Table 3:

Table 3 Common Protocols and Port Correspondence

Newman [10] pointed out that control room staff in prisons introduce viruses and worms by browsing pictures and movies online. Some prisons provide internet access to inmates, which, while not directly connected to prison control and monitoring systems, is still a vulnerable point of attack. Additionally, patrol vehicles in the prison use wireless signals, requiring connection to the prison network to upload data, representing another attack entry point.

Klick [11] noted at the 2015 USABlackHat that PLCs lack security mechanisms, allowing code uploads to these Internet-facing PLCs. This can be exploited as gateways to infiltrate production networks and even the company’s IT network. Klick used the PLC programming language STL to write a port scanner and SOCKS proxy, then utilized the infected PLC to scan the local network and act as a gateway, connecting to other PLCs or even penetrating into the company’s business network, as shown in Figure 4:

Figure 4 Company System Hierarchy Diagram

McLaughlin [12] designed a piece of malware targeting PLCs capable of generating dynamic data packet payloads. Attackers using this tool can execute attacks without prior knowledge of the control system, significantly lowering the barriers to attacking PLCs. Initially, the generated payload infects one or more hosts, then performs industrial process analysis, decodes binary files, and finally trims the generated payload, uploads it to the PLC, and executes it, as shown in Figure 5:

Figure 5 Dynamic Malware Payload Generation Process

McLaughlin, in another article [13], developed a tool called Sabot that automatically generates PLC payloads, identifies PLC logic control, and generates malicious PLC code, as shown in Figure 6:

Figure 6 Sabot Attack Process Diagram

Spenneberg et al. [14] demonstrated a worm that resides solely on the Siemens SIMATIC S7-1200 PLC at the 2016 Asia BlackHat. This worm does not rely on a PC to spread; it operates and runs within the PLC, discovering new targets (PLCs) through network scanning, attacking these targets, and replicating itself to new PLCs. The main program of the infected PLC does not change, allowing for target discovery and carrying malicious payloads. Moreover, removing these worms is very challenging; currently, it can only be done by restoring factory settings or rewriting the function block where the worm resides. The infection process is illustrated in Figure 7:

Figure 7 Worm Infection Process on PLC

The code execution process is shown in Figure 8:

Figure 8 Worm Malicious Code Execution Process

In summary, the security situation of PLCs is not optimistic; there are many attack paths targeting PLCs, and the levels of attacks are gradually deepening. There is still a long way to go in ensuring the security of PLCs.

References:

[1] Beresford D. Exploiting Siemens Simatic S7 PLCs[J]. Black Hat USA, 2011, 16(2): 723-733.

[2] Kimon. Uncovering VxWorks – Directly Targeting IoT Security Holes [EB/OL]. http://chuansong.me/n/1864339, 2015-11-01

[3] Langner R. A time bomb with fourteen bytes[J]. Available: http://www.langner.com/en, 2011.

[4] Meixell B, Forner E. Out of control: Demonstrating SCADA exploitation[J]. Black Hat USA, 2013.

[5] Tzokatziou G, Maglaras L, Janicke H. Insecure by design: using human interface devices to exploit SCADA systems[C]//Proceedings of the 3rd International Symposium for ICS & SCADA Cyber Security Research. British Computer Society, 2015: 103-106.

[6] Chen T M, Abu-Nimeh S. Lessons from Stuxnet[J]. Computer, 2011, 44(4):91-93.

[7] Case D U. Analysis of the cyber attack on the Ukrainian power grid[J]. Electricity Information Sharing and Analysis Center (E-ISAC), 2016.

[8] Z-One. Schneider PLC Ethernet Module Backdoor Account Decryption [EB/OL]. http://plcscan.org/blog/2014/06/schneider-electric-quantum-ethernet-module-hard-coded-credentials/, 2014-06-12

[9] Radvanovsky B. Project shine: 1,000,000 internet-connected SCADA and ICS systems and counting[J]. Tofino Security, 2013, 19.

[10] Newman T, Rad T, ELC networks LLC, et al. SCADA & PLC vulnerabilities in correctional facilities[J]. Core Security, 2011.

[11] Klick J, Lau S, Marzin D, et al. Internet-facing PLCs – a new backdoor[J]. Blackhat USA, 2015.

[12] McLaughlin S E. On Dynamic Malware Payloads Aimed at Programmable Logic Controllers[C]//HotSec. 2011.

[13] McLaughlin S, McDaniel P. SABOT: specification-based payload generation for programmable logic controllers[C]//Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012: 439-449.

[14] Spenneberg R, Brüggemann M, Schwartke H. PLC-blaster: A worm living solely in the PLC[J]. Black Hat Asia, Marina Bay Sands, Singapore, 2016.