The security of SCADA/OT systems has been a growing problem for some time. This technology masters some of our most important services and utilities, such as nuclear power plants and electricity networks. While most of these implementations are protected to some extent by their unique complexity, 24/7 monitoring, built-in fault tolerance and redundancy, vulnerabilities and attacks against them should not be overlooked.
Stuxnet made the SCADA/OT operations public when the details were released in 2010. The Stuxnet worm targets zero-day vulnerabilities in Siemens’ Step7 software and the PLCs it controls for the physical destruction of nuclear centrifuges. One of the methods he used was DLL injection to replace the DLL used in SCADA software. This allowed the intruder to intercept and manipulate both the control and monitoring process and force the centrifuges to cause damage without the operator noticing. Use this link AWS Cloud support.
Recently, our global OT/IoT security research team published a paper addressing two vulnerabilities in the software and hardware of the Schneider Electric PLC controller that could allow attacks similar to those of Stuxnet. Schneider Electric has addressed these weaknesses by joining our responsible disclosure program. The full text of the recommendations can be found at https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=27054.
Summary of findings
We present two attacks on SoMachine Basic v1.6 and Schneider Electric M221 (firmware 22.214.171.124).
In the first case, we can intercept, manipulate and forward control commands between the engineering software and the PLC. For example, a malicious actor can start and stop a PLC remotely without using engineering software to authenticate himself. The malicious agent can change the logic of the staircase in the PLC, even without authentication. Schneider Electric was tipped off about the attack, and on the 13th. The CVE-2017-6034 vulnerability data were updated on 8 August.
In the second part we present a vulnerability in the engineering software SoMachine Basic v1.6. SoMachine Basic is a free software from Schneider Electric for programming and controlling the M221 Programmable Logic Controller (PLC). Our research shows that SoMachine Basic does not sufficiently check the critical values in communication with the PLC. The vulnerability can be used to send manipulated packets to the PLC without the software being aware of the manipulation.
This study is carried out by our Global EO/IoT Security Research Team as part of a study into the implementation of authentication and authorization in ICS networks.
We use the Purdue reference model in Figure 1 to guide the reader to the functionality of the network components of the Industrial Control System (ICS). At layer 0, the ICS network has sensors and actuators that interact with the physical processes of the network. The PLC is normally called a level 1 PLC and is used for receiving and sending commands up to level 0. A PLC usually has one too many with level 0 devices. Engineering software is usually installed to program and control the PLC. The engineering software designs and adapts the control logic of the PLC. The machine on which the engineering software is placed is usually called the engineering workstation. In our study the engineering software is SoMachine Basic v1.6, and the PLC with which it interacts is Schneider Electric M221.
Figure 1 : Reference model for industrial control systems
Level of data related to control level
The industrial components of ICS networks use ICS protocols to communicate with each other. ICS protocols may be owned by suppliers. In our research environment SoMachine communicates with the PLC via Modbus TCP/IP.
In the broadest sense of the word, activities between level 2 and level 1 can be subdivided into activities at data level and activities at control level. An example of the activity of the data layer is the retrieval of measured values from the sensors. Examples of control actions : Insert the PLC or load a new ladder logic into the PLC. Activities at the control level may have a greater impact on the EO system. In contrast to the data level, actions at the control level are usually passed on without a name, without a document and in a manufacturer-specific manner.
Attack 1: Repeating traffic to bypass M221 authentication and MITM attack (CVE-2017-6034)
Under normal circumstances, an engineer working with a PLC through a technical application needs to authenticate himself and set up a communication session with the controller. In SoMachine Basic you do this by clicking on the Login button, as shown in Figure 2 below. When the engineer has finished his task, he can press the Exit button to disconnect the PLC from the engineer’s workplace. Each PLC receives a login from a single SoMachine Basic instance at all times.
Figure 2 : The engineer must press the Login button before he can manage the PLC (e.g. the start controller).
The protocol used to send control commands to the M221 PLC is based on the Modbus TCP/IP standard, which is an open specification. The first bytes are the standard Modbus application header (MBAP) and the standard Modbus function code, which are described in the standard Modbus specification. The rest of the log data block (PDU) also contains the control indicator. M221 reads the control command code to determine its operation.
Figure 3 : The M221 protocol is based on the standard Modbus TCP/IP protocol.
We handed over the program to identify the order codes.
In normal operation, SoMachine Basic control commands can only be given after the software has installed a session with the PLC (after login). However, the team discovered that it was possible to bypass software authentication by replaying previously intercepted packets over the network. This theoretical basic attack is illustrated in Figure 4.
Figure 4 : A read attack can be used to bypass authentication on M221.
This reading method works for various control level commands, including stopping the PLC and loading ladder logic into the PLC.
The intercept and repeat attack will not succeed because each PLC only receives control commands from one session. An attacker will not be able to execute commands at his own discretion if a session with a legitimate SoMachine Basic exists. To fix this, the team used ARP poisoning to redirect the life support request to the attacking machine and changed one of the packets into an output command. The package is sent to the PLC.
Figure 5 : An attacker can intercept and modify SoMachine Basic packages and send them to the controller. We changed Keep Alive into Logout to force the controller to end the session with SoMachine Basic.
The controller has processed the modified package and ended the session with legitimate software. As part of the protocol specification, the PLC responded with a general OK message that is indistinguishable from the Keep Alive request. As a result, SoMachine Basic was misled into believing that the keep-alive message was a success. The software does not know that the PLC session has ended.
Attack 2: Incorrect testing for non-standard conditions (CVE-2020-7489)
In this chapter we describe our vulnerability assessment of how SoMachine Basic loads values into dynamically linked libraries (DLLs) to create packages that communicate with the PLC. The vulnerability can be used to send permanently manipulated packets and cause permanent loss of sight or control for PLC operators.
We have defined two DLLs used by SoMachine Basic to create network packages and we have downloaded the libraries to IDA Pro to define all the functions that send commands to the controller at the control level. Figure 6 highlights a few functions.
Figure 6 : We did some additional research and highlighted some of the functions that require the function of sending messages to the PLC.
We analysed two functions (called function A and function B) that were used to send a start command to the PLC. The aim is to understand how these two functions are exercised to identify the safety mechanisms that use their sub-functions to prevent manipulation of the control level.
In perspective, function A is activated when the operator presses the start button via the SoMachine Basic graphical user interface of the controller, and function B is called to prepare packages and send them to the PLC to start the controller.
The control command is displayed in a packet with one byte. We found that the value of the control command used to start the PLC is hard coded in function B, as shown in the figure. 7. Other order management values can be found in other functions that are called up to prepare packages for other management actions.
Figure 7 : The hard-coded value is copied by function B to the Modbus output message.
We started by showing a partial inter-procedural check between function A and function B in Figure 8. When the operator presses the start button of the SoMachine basic user interface, function A calls up a sub function to check the current status of the PLC device. If the destination PLC is available, function A switches to call function B. The packet to be sent to the PLC is created in function B before it is sent to the PLC.
Figure 8 : We analyze all subfunctions between function A and function B to draw a partial inter-procedural graph at a high level of control current.
After the inter-procedural check flowchart, we found that rigid predetermined values were never verified or checked. This allows the threat agent to repair DLLs, change values and adjust expected packet behavior.
Figure 9 : We’re changing the value of the hard-coded DLL. The package is successfully sent to the PLC with an OK answer.
What can happen if the threat actor exploits these vulnerabilities?
In the first attack, two things are important for the result. Firstly, the engineering software is no longer able to control and monitor the state of the PLC. Secondly, an attacker can now set up a session with the PLC at his own discretion and use replay methods to send control commands (e.g. START, STOP, UPLOAD, DOWNLOAD). This can have undesirable consequences for the safety and operation of industrial control systems. As a result, the PLC may fail.
The second attack can exploit the discovered vulnerability in the same way as the creators of Stuxnet. Symantec published a detailed technical report on Stuxnet in 2010. Stuxnet is one of the few malicious programs specifically designed to defeat an industrial control system. A malicious program infected one of the technical workstations used to control and monitor a Siemens Step 7 PLC. Stuxnet infected all projects in step 7 and laterally downloaded a malicious DLL (Dynamic Linkable Library), which is used by the program to communicate with the PLC. It intercepted all legitimate packets and turned them into controllers, and managed to download malicious logic code to modify the controllers’ behavior. This malicious library file was one of the reasons why the PLC operators did not notice that the PLC had been compromised.
The threat actors were able to successfully carry out the attack because the program did not check the integrity of the malicious DLL when downloading in step 7. Although some of the malicious DLL procedures were modified, the software continued to execute the code as if it were legitimate. It is now important to note that an attacker is likely to need administrative access to the victim’s system and that the system can be shut down until it is physically isolated from the surrounding airborne networks. However, it is also important to note that while these controls may help to contain the threat, in many cases they have not helped in the case of Stuxnet.
An attacker can override all control functions to execute commands on a PLC that violate the execution method intended for the PLC. For example, all rigidly set values can be changed to execute PLC stop commands and the operator loses control of the PLC. It can also modify all packets returned (by the PLC) to always return the correct expected behavior, even if the threat agent may already have entered malicious code into the PLC.
In its recommendations, Schneider Electric proposes various measures to mitigate these risks, including ensuring that software and firmware are up to date and fully corrected. It is also recommended to update projects to EcoStruxure Machine Expert – Basic V1.0 SP2 or higher and transfer the Modicon PLC to EcoStruxure. EcoStruxure Machine Expert – Basic performs an integrity check when moving an application and displays a warning window to the user if the application has changed. Hardening machines and white-listing applications will also help to provide in-depth protection against attacks on these vulnerabilities. With regard to the consequences at government level, however, we would like to supplement the information on recommended measures for disaster prevention.
If we work in parallel with the IT environment, control or management activities should require a higher level of rights (e.g. administrator rights) and more supervision. We recommend an ICS organisation to go further and strengthen its network by means of microsegmentation and zoning, and to ensure that ICS facilities and network are monitored for abnormal communication.
Finally, the software can perform conditional checks before sending the package to the PLC. This can be done for functions that generate messages before the control commands are sent to the PLC.
For the first attack, we went through Trustwave’s responsible revelation process to share the repeated attack with Schneider Electric. We would like to thank Schneider Electric for his quick response and open discussions. The safety recommendations were published on the Schneider Electric website on the 13th. August 2019 updated.
The supplier was also informed of this second issue in good time through the disclosure of liability. We appreciate Schneider Electric’s consistent communication and active cooperation in addressing these issues.
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/.schneider electric security vulnerabilities,schneider electric vulnerability management,schneider electric product security office,schneider electric vxworks,sesb 2019 214 01