Dilemma of smart factory 2: Attack scenarios
This series of blog posts explains the design security risks involved in legacy languages and risk mitigation measures that all users of industrial robots should take. This part explains three attack scenarios that can directly lead to damage.
Save to Folio
Industrial robots are the core of the automation of manufacturing processes in smart factories, and are the most important components as they support the manufacture of all kinds of products such as automobiles, aircraft, processed foods, and pharmaceuticals. In addition, as equipment that realizes unmanned manufacturing in the post-COVID-19 world where minimal or no contact is a necessity, the importance of industrial robots that can repeatedly execute specified movements with high accuracy is regaining attention. However, it is not commonly known that industrial robots are programmed using languages designed decades ago. Trend Micro has been conducting cybersecurity research on smart factories since 2017, and discovered vulnerabilities in "task programs" that define the behavior of industrial robots and also design flaws in "programming languages." Despite being legacy languages that were designed decades ago, these languages are still used in modern smart factories because they are difficult to replace with other languages. What happens when the field of security requirements that have not been deeply discussed for a long time are incorporated into the trend toward smarter systems? In this series, based on the results of our third joint research project with the Polytechnic University of Milan, from a short to long-term perspective, we analyze the design security risks involved in legacy languages and risk mitigation measures that all users of industrial robots should take. In this second installment, based on the results of our proof of concept, we explain in detail three attack scenarios that can directly lead to damage through theft of money and theft of information.
3 attack scenarios
Trend Micro verified around 100 task programs available from public code repositories (GitHub and online communities), and we could confirm the presence of vulnerabilities such as "defective input value verification," "lack of authentication functions," and "remote code execution" in most of the code. We have demonstrated three attack scenarios that exploit these vulnerabilities. These scenarios are:
- Changing of robot operation via the network: By exploiting defective input value verification of the motion server and transmitting invalid coordinate value data via the network, robots are made to perform unintended operations.
- Information theft via robots: Confidential information is stolen by launching a path traversal attack that exploits a vulnerability in a task program.
- Targeted, self-spreading malware: These exploit the network communication functions and code dynamic loading functions inherent in programming languages to make task programs function as droppers that take in malicious programs from external sources. In addition, defective input value verification in task programs is exploited to cause industrial robots to execute functions corresponding to invalid external input. By combining these, self-spreading malware written in a programming language for industrial robots is generated and executed.
Cyber attackers with advanced technology are assumed
The attack scenarios presented in this article are assumed to be feasible by highly skilled and budgeted cyber attackers targeting well-defined targets. The reason for this is the placement characteristics of the industrial robots that are the target of attacks over a network. Industrial robots are usually not directly connected to the Internet, instead they are located on a field network in a factory environment. As a result, external attackers inevitably go through many other IT and OT assets before they actually reach an industrial robot, and it takes a considerable amount of time and effort to complete such attacks, and obviously, the clear intention to attack. Therefore, it is reasonable to assume that the people who perform the attack scenarios presented in this article are advanced attackers who are familiar with the specific facilities being targeted, including industrial robots. For reference, looking at recent security case studies targeting industrial control systems (ICS), it can be seen that highly-skilled attackers (or state-sponsored attackers) are prepared to spend a long time attacking specific targets. In addition, state-level attackers and other attackers have budgets of 2.2 to 27 million JPY (20,000 to 250,000 USD, equivalent to the price of a small lab facility) for experiments such as those used in this survey, and it is assumed that they have the used industrial robot systems installed.
Damage caused by attacks
Figure 1 shows the attack scenarios demonstrated in this study and the impacts of the attacks.
<Fig. 1> The three attack scenarios and their effects
By exploiting the vulnerabilities in the task program identified in this study, cyber attackers could physically damage production lines, steal confidential information, or even steal money. For example, exploiting "Attack Scenario 1: Changing of robot operation via the network" could trigger incidents that can lead to reduced productivity, such as causing physical damage to manufacturing equipment. In addition, if you were an attacker aiming to steal information, you could use "Attack scenario 2: Information theft via robots" and "Attack scenario 3: Targeted and self-spreading malware" in combination to obtain confidential information from a factory environment, and use it as a hostage to extract or demand money from the factory.
As mentioned above, the vulnerabilities used in these tests were found in code found on GitHub and online communities. It cannot be said that such code is definitely used as-is on the manufacturing floor, but it can be said that some of these codes are taken from technical materials such as manuals and programming references used by novice programmers. Therefore, it cannot be said that it is completely harmless to workplaces. In addition, previous research has shown that vulnerabilities in open-source code can spread and ultimately affect products. Therefore, we assume that the attack scenarios presented in this article are reproducible on the manufacturing floor.
Now let's take a closer look at three attack scenarios that can directly lead to damage of a factory environment.
Attack scenario 1: Changing of robot operation via the network
The movement of an industrial robot is defined programmatically and the values input to the controller. Photo 1 is an open-source task program created for the industrial robot "Kuka," which is a motion server task program that defines the movement of the robot. This allows the robot to receive coordinate information over the network, regulating the robot's movements. Therefore, the input to the robot must always be complete in order to ensure physical safety. Normally, an area for safety protection is set for an industrial robot (hereinafter referred to as a safety area), and the maximum operation of an industrial robot is limited to within this area. Therefore, if the safety area is set properly, inputs with coordinates outside the area will be invalidated. On the other hand, in cases where invalid coordinates are specified for the "inside" of the safety area, the integrity of the input must be ensured by the input value verification and access control functions for the robot.
<Photo 1> An example of an open-source task program in which a vulnerability was found (Kuka).
However, "defective access authentication" and "defective input value verification" were found in the program investigated this time. In other words, this task program is not configured to receive commands only from a specific partner, does not judge the validity of the input coordinate information, and determines the movement of the robot based only on the received data. By exploiting these vulnerabilities, an attacker can spoof network packets and move the targeted robot at will. This attack can affect manufacturing quality and create delays in the manufacturing process due to unintended robot movements. If the safety area is not configured correctly, the damage will be more serious. Photo 2 is the result of running this attack scenario without correctly configuring the safety area.
<Photo 2> Results of an experiment without an appropriate safety area configured. The arm part of the industrial robot was damaged by an unintended operation change.
Programs that define behavior over networks in this way are common as motion server task programs used to drive connected industrial robots. Large-scale projects, such as ROS-Industrial software, make extensive use of motion servers to provide a vendor-neutral interface common to various OEM industrial robots.
In general, there is appropriate network level protection (such as IP address or MAC address filtering), and industrial robots are guaranteed to receive coordinate values from only designated controllers. However, if the task program does not have a mechanism other than the network level protection described above to authenticate the source, or if it is affected by an input value verification vulnerability, as long as the received coordinate value is from a valid IP address or MAC address, it will be automatically trusted even if the source is spoofed. In either case, this makes it easy for an attacker residing on the local network to perform this attack scenario. As a result, an attacker can simply send arbitrary coordinates and the industrial robot will be driven accordingly, resulting in poor product quality and delays or stoppages in the manufacturing process. In addition, improperly configured safety areas can result in more serious physical damage as shown in Photo 2.
Attack scenario 2: Information theft via robots
This attack scenario exploits a path traversal vulnerability in a task program on a Web server that is executed to display coordinate information on an industrial robot controller provided by a manufacturer. The program discovered in this research was an app that can be used via "ABB-Robot Apps Robot Studio" and operates as a web server on an industrial robot. And it was implemented using Rapid, ABB's own language. Exploitation of this vulnerability could enable an attacker on a network to create a file containing potentially sensitive data (such as a log file containing coordinate information from when an industrial robot operates) on an industrial robot, and leak it using the controller of an industrial robot. Confidential industrial information is traded at very high prices in the underground market and is one of the main targets for cybercriminals. In response to our report, ABB has removed the relevant app from their app store.
Path traversal is an attack method and vulnerability in which attempts are made to access a directory that should not be accessible by exploiting a vulnerability. This attack exploits a server specification that adheres to instructions in a tree structure, but in most cases, there is code that allows unintended access by the developer. Photo 3 is the ABB program mentioned earlier, with line 493 being the code that most clearly shows the path traversal vulnerability. Line 493 calls the sendFile function to send the requested file to the client. Of note here is the concatenation with the page string, which includes the higher-level directories, which also allows access to other files across the file system.
<Photo 3> A line of code that clearly shows the path traversal vulnerability of the Web server (line 493)
Also, photo 4 shows the results of an experiment in which the vulnerability was exploited to steal confidential sample information. It has been shown that a path traversal attack can access "secret.txt." The code also provides an excerpt of the vulnerable web server code, along with comments left by the developer. In this case, it shows that all requests come from a benign browser and are reliable, but in reality, this is by no means secure coding.
<Photo 4> Demonstration results showing that a sample confidential information file was stolen by exploiting a path traversal vulnerability
In security-conscious software development, it is always assumed that "external input is unreliable." Therefore, it is necessary to verify the input values on the server side in advance so that unauthorized access is not performed by input that the developer did not expect.
Attack scenario 3: Generation of targeted and self-spreading malware
By preparing a Trojan horse malicious program in a task program and having it act as a dropper, an attacker can create self-spreading malware on an industrial robot and spread the threat throughout the entire factory. Once the malware is created according to the steps shown in Figure 2, the worm-capable malware begins scanning the network for other potential targets, exploiting network vulnerabilities, and spreading itself.
<Figure 2> Unauthorized loading into automated code to create malware with dropper and self-spreading capabilities
Photo 5 is a screenshot showing the network scanning operation of the worm-type malware presented as a proof of concept in this survey. The basic operation is simple. In this case, the network is scanned (intentionally limiting the scope to three IP addresses in order to make the proof of concept as specific as possible) and whether the target port is open or not is checked. The Command and Control (C&C) server can then communicate with the infected industrial robot and execute commands such as network scans and spread infection to other industrial robots.
<Photo 5> The network scanning operation of the worm-type malware presented as a proof of concept in this survey
Thus, while industrial robots and their automation technologies are totally different from traditional web applications running on Windows servers, there are well-known types of vulnerabilities such as path traversal and code injection, meaning you could be infected with a virus and you could be targeted by malware.
In addition, most of the issues analyzed in this survey are so-called "normal programming problems," so if we focus only on individual vulnerabilities, it may seem that we are only presenting the risk of "any attack is possible if the attacker can change the task program." However, these risks are not the only ones that give the full picture of the issues covered in this survey. The essence of the problem is that the programming languages we investigated in this survey continue to be used despite being designed in an era when none of them would have been assumed to be actively used for attacks.
Next time, I'll look at the root causes of flaws that have come to light from an analysis of eight robot-programming languages.