Schneider Electric SE recently fell victim to a breach of its safety system, which crippled operations at a critical infrastructure facility in the Middle East. It’s the first reported attack on a safety instrumented system (SIS) – and it won’t be the last.
Attackers, believed to work for a nation state, used sophisticated malware – called Triton – to infiltrate one of Schneider’s Triconex safety systems. It’s these safety systems that shut down operations in nuclear facilities, oil and gas plants, water treatment facilities and more when hazardous conditions are detected.
The attackers leveraged diverse technologies to develop the malware, from Windows-based attack vectors to reverse engineering of microprocessor-based firmware and communications. It was clearly created to target that specific production plant and those specific systems.
This blog post examines the attack and explains how it evolved and what mitigations can be offered to fence off such attacks in the future.
Understanding Industrial Control Systems
Industrial control systems (ICS) are autonomous, computer-based devices, used extensively in oil refining, chemical processing, electrical generation and other industries where the creation of a product is based on a continuous series of processes being applied to raw materials. By deploying and programming ICS devices, engineers have the ability to remotely monitor and control the different variables of the industrial process.
A subcategory of ICS, an SIS is used to protect humans, industrial plants and the environment in case of a monitored process going beyond the allowed control margins. These devices are not intended for controlling the process itself, but rather provide an overriding signal, so that immediate actions are taken if the process control systems fail.
An SIS consists of three elements: a sensor, logic solver and final control element. The sensor is used to collect information necessary to determine if an emergency situation exists. Sensors measure process parameters such as temperature, flow and pressure. A logic solver is typically a controller that reads signals from sensors and executes pre-programmed actions, intended to prevent hazardous situations by providing output to final control elements. Final control elements are typically actuated on-off switches or valves, designed to execute the logical decisions of the logic solver.
Consider the case where an SIS has detected an unacceptable risk of explosion as a result of a pressure build-up inside a vessel. This may be the result of a failure in one of the process control systems. The SIS sensors would sense that and activate pressure relief valves that act as a “last line of defense” and vent the gasses out, essentially halting processes.
The Attacker’s Intent
Now that the clouds are beginning to clear over the incident, we can try to better describe the malware internals and hypothesize the intent of the attackers.
According to the Schneider Electric Analysis and Disclosure[1], released on Jan 23, it seems that the attackers were trying to implant a remote access Trojan (RAT) inside the Triconex SIS.
RATs are computer programs designed to provide attackers with complete control over the victim’s system. They can be used to steal sensitive information, spy on victim’s system, and ultimately remotely control infected devices.
How the Triton RAT Made its Way to the Tricon Engineering Station
Figure 1 shows a typical ICS Ethernet Network. In the center of the network are the industrial process controller and SIS devices. Although these are stand-alone devices, they must be connected to engineering station PCs – in this case, running Windows – for software updates and maintenance.
The traditional approach to ICS networking is to segregate the communication infrastructure from the control assets. However, there has been a trend in the past decade toward integrating network infrastructure, placing the process control systems and the SIS controllers on the same general purpose network.
Obtaining access to the process control network, by gaining access to one of the PCs on that network, can be detrimental to the SIS because any machine on that network can access the SIS controllers. The danger is compounded by the fact that engineering station’s users are usually local administrators, leaving an attacker with an infinite attack surface to leverage.
This architecture can be much more dangerous when combined with engineering remote access. A common practice at many sites is to allow engineers to access the operational network via Remote Desktop Protocol (RDP). Compromise of the engineer’s RDP credentials will allow an attacker access to both the industrial process devices and the safety network, further increasing the attack surface.
Either by leveraging the network infrastructure or by physical access to engineering stations, the attackers in the Triton malware case gained access to the SIS engineering station and planted their first stage malware – a Windows executable called “Triton.exe” on the SIS network.
First Stage Malware: Delivering Code to the SIS Controller
The Triton executable, planted by the attackers on the SIS engineering station, is a partial implementation of the TriStation protocol. The TriStation protocol is a Schneider Electric proprietary protocol, implementing user datagram protocol (UDP) serial-over-ethernet and used by the engineering stations to download application code to the SIS device.
Apparently, the attackers reverse-engineered this protocol’s details and wrote their own version of it to embed in the Triton executable[2]. The implemented protocol is used by the malware to download new malicious code to the SIS.
Although attackers can now implant code inside the SIS device, they still have two weak points:
- The Triconex SIS controller is protected by a physical key switch (Figure 2)
.
Figure 2: Triconex Key Switch (source)
The Triconex SIS firmware will only accept new software when this key switch is in the ‘program’ position. Attackers then must either wait for someone at the victim’s site to switch the mode to ‘program’ or have an accomplice inside switch it for them. - The byte code downloaded by the TriStation protocol is not persistent. The normal function of the SIS device will only allow writing code to the user area of the SIS memory. This means that whenever an engineer initiates a ‘download all’ command from an engineering station, all byte code software previously downloaded to the SIS will be erased, and new byte code software loaded. This will consequently erase the attacker’s code previously downloaded by the malware and thwart the attack.
Second Stage Malware: Gaining Persistence
In order to overcome these two weak points, the attackers prepared a second stage code. This code, running inside the SIS device, was designed to write itself on to the firmware memory area of the device (in contrast to the user memory area) and hook onto the communications main loop, thus also overcoming the switch position problem.
How? The second stage code is using what Schneider Electric defines as a “zero day” in the Triconex operating system, which causes a privilege escalation for the running process. The zero day allows the malware code to elevate from user to supervisor, obtain read/write/execute privileges and then copy itself into the firmware memory.
The malware code is designed to find a free location for the payload, and then copy the payload into that area of the firmware memory. Although the malware payload is written to the firmware’s RAM, a volatile memory in nature, the malware has now gained a de-facto persistency. This is because SIS units do not get rebooted very often. In fact, a SIS unit will not normally be restarted by its operators.
By leveraging what appears to be another weakness in the Triconex operating system, the supervisor malware was then able to hook itself into the network communications process of the SIS. The malware code registered itself to be called by the operating system every time it received a certain network command, so that the malware payload would be called before the normal Tricon communications process takes place, thus bypassing the key switch problem, and enabling code injection, regardless of the physical key switch position.
The attackers now have a RAT in place waiting to be activated. It is wired before the communications process as part of the Triconex operating system, and it’s ready to accept commands from any PC connected to the SIS network, masqueraded as a diagnostics command used for debugging the Tricon SIS devices.
Detecting the Attack
The RAT allows the attacker to read and write memory and execute code freely. However, it seems that after implanting the RAT, the industrial process governed by the SIS was shut down as a result of the controllers entering a failed safe state[3].
This prompted the asset owner to start an investigation, which eventually led to the discovery of the Triton malware and stopped the attack altogether.
The Schneider report clearly asserts that the attackers were not there to fail. On the contrary, the attackers were in a position to inflict serious damage, and they would have had the attack had not been thwarted.
The fact that the attack compromised both the industrial process devices and the SIS systems suggests that the attackers intended to inflict serious damage, rather than merely shutting down processes. An attacker that controls the process units and the safety valves, intended to be the last line of defense, can only point to that conclusion.
Mitigations
Here are several best practices that can help mitigate this type of attack:
- Network segmentation
We understand that engineers must have full access to the engineering network in order to facilitate programming the IPC and SIS devices. However, their access must be isolated, controlled and monitored across the network access points. Privileged RDP sessions must be isolated by using single-sign-on for initiating sessions without the need to expose privileged credentials to third party engineers, and all privileged sessions. - Least privilege over antivirus software
Antivirus software (AV) is, at its core, designed to detect malware by comparing code signatures and known patterns of mal-behavior. Malware designed to attack a third party device, such as industrial controller, is not likely to raise the suspicions of antivirus, and therefore relying on AV software for the protection of industrial systems is not only useless but also dangerous on the part of the defending organization.
A new set of rules must be enforced on industrial control networks. These rules should enforce the least privilege principle across the board with specific monitoring in place. The principle of least privilege (POLP), an important concept in computer security, is the practice of limiting access rights for users to the bare minimum permissions they need to perform their work in order to dramatically reduce the attack surface of the organization. Under POLP, users are granted permission to read, write or execute only the files or resources they need to do their jobs. In other words, the least amount of privilege necessary. Part of the POLP implementation is restricting execution of unknown apps and tightly controlling the installation of new apps.
By using strict privilege management, enhanced application whitelisting and controlled execution privileges we can better protect diverse assets from cyber attacks on a forward-looking basis by shrinking the attack surface. - Virtual machines
Consider using virtual machines in development of future SIS devices for application code. Downloading executable byte code to the SIS device, as well as other industrial process controls, is dangerous and this attack exemplifies it.
Conclusion
Triton is an example of a two-headed attack on critical infrastructure systems with devastating potential consequences.
The attack started by implanting a Windows executable into a strategic machine, which then injected a sophisticated RAT into SIS and other process control devices.
Fortunately, in this case, due to some bug in the malware, the SIS devices stopped the process and entered a failed safe state. If the attackers had not tripped that wire and revealed themselves, much dreaded physical damage could have been inflicted.
References:
- A YouTube video was released by Schneider Electric on Jan 23rd 2018.
- An important point about the Triconex system is the fact that human readable code (such as Ladder Diagrams) coded on the TriStation 1311 software is being compiled and linked to PowerPC machine readable byte-code. This is one of the points the malware developers leveraged in order to gain full control over the SIS device.
- For more information on that see the Midnight Blue Security Consultancy report.
Note: This article is based upon research and contributions by CyberArk Labs Researchers including Lavi Lazarovitz and Nimrod Stoler.
