Introduction
SCADA/OT security has been a growing concern for quite some time. This technology controls some of our most essential services and utilities, like our nuclear plants and electric grids. While most of these implementations are protected to a certain extent by unique complexity, 24/7 monitoring, and built-in fault tolerance and redundancy, vulnerabilities and attacks targeting them should not be discounted.
Stuxnet gave SCADA/OT exploits a major spotlight publicly when the details were exposed back in 2010. The Stuxnet worm targeted zero-day vulnerabilities in Siemens Step7 software and the PLCs under its control to physically destroy nuclear centrifuges. One of the methods it used was DLL injection to replace a DLL used by the SCADA software. Doing so allowed the attacker to intercept and manipulate both the control and monitoring process forcing the centrifuges to damage themselves undetected by the operator.
Recently our Global OT/IoT security research team released an advisory covering two vulnerabilities in Schneider Electric PLC controller software and hardware that could allow for attacks similar to those in Stuxnet. Schneider Electric has patched these vulnerabilities through coordination with our Responsible Disclosure program. You can read the full advisory here: https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=27054
Findings Summary
We present two attacks on SoMachine Basic v1.6 and Schneider Electric M221 (Firmware 1.6.2.0) Programmable Logic Controller (PLC).
In the first, we are able to intercept, manipulate, and re-transmit control plane commands between the engineering software to the PLC. The impact is that a malicious actor can start and stop the PLC remotely without authenticating with the engineering software. The malicious actor can also change the ladder logic in the PLC without authentication. The attack was disclosed to Schneider Electric and the details on vulnerability CVE-2017-6034 were updated on 13 August.
In the second, we present a vulnerability in the SoMachine Basic v1.6 engineering software. SoMachine Basic is free software provided by Schneider Electric to program and control M221 Programmable Logic Controller (PLC). Our research shows that SoMachine Basic does not perform adequate checks on critical values used in the communications with PLC. The vulnerability can potentially be used to send manipulated packets to the PLC, without the software being aware of the manipulation.
This research work is performed by our Global OT/IoT security research team as part of our research into authentication and authorization implementations in ICS networks.
Introduction
We use the Purdue Reference Model shown in Figure 1 to orientate the reader to the functionalities of the components in an industrial control systems (ICS) network. At Level 0, an ICS network has sensors and actuators that interact with the physical processes of the network. A PLC is typically referred to as being in Level 1 and is used to receive and send commands to Level 0. A PLC typically has a one-to-many relationship with the Level 0 devices. There is usually an engineering software installed to program and control the PLC. The engineering software designs and sets the control logic of the PLCs. The machine that hosts the engineering software is usually referred to as the engineering workstation. In our research, the engineering software is SoMachine Basic v1.6 and the PLC it communicates with is Schneider Electric M221.
Figure 1: Purdue Reference Model for Industrial Control Systems
Data-plane vs Control-plane
Industrial components in ICS networks use ICS protocols to communicate with one another. ICS protocols may be proprietary to vendors. In our research environment, SoMachine communicates to the PLC using Modbus TCP/IP.
Broadly speaking, the activities between Level 2 and Level 1 can be categorized into data plane activities and control plane activities. An example of data plane activity is to retrieve the readings from the sensors. Examples of control plane activities are to stop the PLC or download new ladder logic to the PLC. Control plane activities can potentially have a larger impact on the OT system. Unlike data-plane activities, control plane activities are usually communicated in ways that are unnamed, undocumented, and specific to the OT vendor.
Attack 1: Traffic Replay to Bypass Authentication on M221 and MITM Attack (CVE-2017-6034)
Under normal circumstances, an engineer working with a PLC through an engineering application needs to authenticate and establish a session with the controller. In SoMachine Basic, this is done by clicking the “Login” button as shown in figure 2 below. When the engineer completes his task, he can click the “Logout” button to disconnect the PLC from the engineering workstation. At any time, each PLC will only accept login from one instance of SoMachine Basic.
Figure 2: An engineer needs to click “Login” before he can administer the PLC (e.g. start controller)
The protocol used to send control commands to M221 PLC is based on standard Modbus TCP/IP, which is an open specification. The first few bytes are the standard Modbus Application Header (MBAP) and standard Modbus Function Code that are described in the standard Modbus specification. The remainder of the proprietary Protocol Data Unit (PDU) also contains the control command code. M221 reads the control command code to determine its action.
Figure 3: The M221 protocol is based on the standard Modbus TCP/IP protocol
We reversed engineered the software to identify the command codes.
Under normal operations, control commands can only be issued by SoMachine Basic after the software establishes a session with the PLC (after logging in). However, the team has found that it is possible to bypass software authentication by replaying previously captured packets in the network. That basic theoretical attack is shown in Figure 4.
Figure 4: Replay attack can be used to bypass authentication on M221
This method of replay works for various control plane commands, including stopping the PLC and downloading ladder logic to the PLC.
As is, the captured-replay attack will not be successful because each PLC will only accept control commands from a single session. An attacker will not be able to execute commands at will if there is an existing session with a legitimate SoMachine Basic. To overcome this, the team used ARP poisoning to redirect “Keep Alive” request to the attacker machine and modified one of the packets to the logout command. The packet is forwarded to the PLC.
Figure 5: Attacker can intercept packets from SoMachine Basic, modify and retransmit the packets to the controller. We modified “Keep Alive” to “Logout” to force the controller to end the session with the SoMachine Basic
The controller processed the modified packet and terminated the session with the legitimate software. As part of the protocol specification, the PLC responded with a generic “OK” message that was indistinguishable from the response to the “Keep Alive” request. As a result, SoMachine Basic was tricked into thinking that “Keep Alive” message is executed successfully. The software is unaware that the session with the PLC had ended.
Attack 2: Improper Check for Unusual Conditions (CVE-2020-7489)
In this section, we describe our analysis of a vulnerability in the way SoMachine Basic loads the values in the dynamic linked libraries (DLL) to create packets that communicate with the PLC. The vulnerability can potentially be used to persistently send manipulated packets and cause permanent loss of views or controls to the PLC operators.
We identified two DLLs that were used by SoMachine Basic to build network packets and loaded the libraries in IDA Pro to identify all the functions that send control-plane commands to the controller. Figure 6 highlighted some of the functions.
Figure 6: We investigated further and highlighted some functions that called the function to send messages to the PLC
We analysed two functions (dubbed as Function A and Function B) that were used to send the command to start the PLC. The idea is to understand the execution between the two functions to identify the security mechanisms that their sub-functions deploy to prevent manipulations of control-plane activities.
To put into perspective, Function A is triggered when an operator clicks “Start controller” using SoMachine Basic graphical user interface, and Function B is called to prepare and send the packets to the PLC to start the controller.
A control command is represented by a single byte in the packet. We realised that the control command value that is used to start the PLC is hardcoded in Function B as shown in Figure 7. The other command control values can be found in other functions that are called to prepare the packets for other control actions.
Figure 7: Hardcoded value is copied from Function B to the egress Modbus message
We proceeded to map out the partial inter-procedural control flow graph between Function A and Function B in Figure 8. When the operator clicks “Start Controller” on SoMachine Basic UI, Function A will call a sub-function to check for the current status of the PLC device. If the targeted PLC is available, Function A will proceed to call Function B. The packet that will be sent to the PLC will be created in Function B before sending it to the PLC.
Figure 8: We analyse all the sub-functions between Function A and Function B draw a high-level partial inter-procedural control flow graph
Following the inter-procedural control flow graph, we found that the hard-coded values were never checked or verified. This enables a threat actor to patch the DLL, modify the values, and change the intended behaviors of the packets.
Figure 9: We modify the hard-coded value on the DLL. The packet is sent to the PLC successfully with an “OK” response.
Consequences
What could possibly happen if a threat actor exploits these vulnerabilities?
In the first attack, there are two things significant about the outcome here. First, the engineering software is no longer able to control and track the status of the PLC. Second the attacker is now able to establish a session with the PLC and, using replay techniques, send control commands (e.g. START, STOP, UPLOAD, DOWNLOAD) at will. This could cause an undesirable impact on the safety and operation of the industrial control systems. The PLC can potentially malfunction as a result.
In the second attack, the vulnerability that we discover can be similarly misused like the Stuxnet creators. Symantec released a detailed technical report about Stuxnet in 2010. Stuxnet is one of the first few malware that is created especially to target the industrial control system. The malware infected one of the engineering workstations, which is used to manage and control the Siemens Step 7 PLC. Stuxnet infected all the Step 7 projects and side-loaded a malicious dynamic linked library (DLL), which is used by the software to communicate with the PLC. It intercepted and modified all the legitimate packets to the controllers and successfully uploaded malicious logic codes to change the controller behaviors. This malicious library file was one of the reasons why the PLC operators did not realise that the PLCs were compromised.
The threat actors managed to execute the attack successfully because the Step 7 software did not check for the integrity of the malicious DLL when it was loaded. Even though some of the routines on the malicious DLL are modified, the software continued to execute the codes as though it was legitimate. Now it's important to note that an attacker will likely require administrative access to the victim system and that the system may be locked down to the point of being physically air-gapped from the surrounding networks, but it's also important to note that while these controls can help mitigate the threat, it did not help in many Stuxnet cases.
The attacker could replace all the command functions to execute commands on PLC that violates how the PLC is designed to do. For instance, he could modify all the hard-coded values to run “Stop PLC” commands and the operator will lose control over the PLC. He could also modify all the return packets (from PLC) such that it will always return the expected good behavior even though the threat actor might have already injected malicious codes into the PLC.
Mitigations
Schneider Electric provides several steps to help mitigate these risks in their advisory including making sure your software and firmware are up to date and fully patched. They also recommend updating your projects to EcoStruxure Machine Expert - Basic V1.0 SP2 or above and transferring your Modicon PLCs to EcoStruxure. EcoStruxure Machine Expert – Basic will perform integrity check when transferring the application and will display a warning pop-up to the user if the application has been altered. Machine hardening and application whitelisting will also help provide defense in depth against attacks targeting these vulnerabilities. However, due to the impact on the control plane, we will like to add on to the recommended mitigations provided.
If we draw a parallel to IT environments, control or administrative activities should require higher privilege levels (e.g. administrator privilege) and increased monitoring. We recommend that ICS the organisation go a step further and harden the network through micro-segmentation and zoning, and ensure that ICS assets and network are monitored for abnormal communications.
Lastly, the software can do conditional checks before the packet is sent out to the PLC. This could be done at the functions that construct the messages before the control commands are sent to the PLC.
Disclosure
For the first attack, we went through Trustwave’s Responsible Disclosure process to share the replay attack with Schneider Electric. We thank Schneider Electric for their quick response and open discussions. The security advisory was published on Schneider Electric’s website and updated on 13th August 2019.
This second issue was also disclosed to the vendor in a timely manner under the Responsible Disclosure process. We appreciate the consistent communication from Schneider Electric and their active partnership in fixing these issues.
References
Trustwave Advisory TWSL2020-001: https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=27054
Schneider Electric Advisory for CVE-2017-6034: https://www.se.com/ww/en/download/document/SEVD-2017-065-01/
Schneider Electric Advisory for CVE-2020-7489: https://www.se.com/ww/en/download/document/SEVD-2020-105-01/
