In 2019, we found a store on the Internet that distributes software for heavy industrial machines. We downloaded some of these apps and reverse-engineered them to understand how they work. Their code was written in one of the proprietary programming languages used to automate industrial robots that assemble cars and pack food on conveyors. A vulnerability was discovered in one of these applications, which started our research on Rogue Automation: Vulnerable and Malicious Code in Industrial Programming .
After examining the technical details and weaknesses of eight of the most popular industrial programming environments (ABB, Comau, Denso, Fanuc, Kawasaki, Kuka, Mitsubishi, and Universal Robots), we found that these languages can be used to create worm malware that will move from one vulnerable robot to another, obeying the remote commands of their operators.
The deficiencies found are the result of a design choice made several decades ago. These solutions defined the technology, methods and tools that are still used today for programming industrial equipment. Consider the implications of this choice in the context of modern cyber threats.
Stealing data from a robot
We found a real case of a vulnerable web server implemented as an application to run on an industrial robot. The web server, written in ABB Rapid, contained a traversal vulnerability that allowed an attacker to connect to the robot over the network and copy any files from the robot's controller, including the logs. Such files most likely contain various confidential data and know-how, so they can be profitably sold in underground markets.
If an attacker manages to hack into a computer on the same network as the robot, he will be able to connect to the controller's web server disguised as an agent, request a file of interest, and retrieve it without authorization, since the program fulfills any requests from the agent.
A fragment of the vulnerable application code. Source (hereinafter, unless otherwise noted): Trend Micro
Line 493 calls the sendFile function to send the requested file to the client. The pageString is not filtered in any way, so it can contain "... /" or some other path. This allows you to traverse the file system and download almost any file.
Vulnerability exploitation scheme
Notable in this case was the comment left by the developer of the vulnerable web server in the code. He knew that the code he had written was vulnerable, but did nothing to fix the problem, because he assumed that all requests would come from the "correct" browser, which would validate the input data and would not allow a string like ".. . \\ ... \\ ":
,
Exploitation of some vulnerabilities can lead to consequences in the physical world, for example, harm finished products or even people around them.
In the open-source project for industrial robots Kuka, we discovered a vulnerability that allows you to change the trajectory of a moving part. The program receives a stream of coordinates over the network and transfers them to the actuator, which performs the specified movements. For this, a special class of procedures is used - motion automation servers. It is a standard interface that allows industrial robot OEMs to provide a consistent way to control the movement of their products.
The vulnerable code of the traffic automation server does not contain any checks for the legitimacy of the data transferred to it
The server code does not in any way check where the next portion of coordinates for the robot's movement came from; it does not provide for internal authentication. The only protection is checking the sender's MAC address and IP address, any of which can be easily spoofed by an intruder who has entered the network.
At our laboratory bench, we made sure that using spoofing, it is possible to falsify traffic between a robot and an engineering workstation. An attacker could send arbitrary coordinates, and the robot simply executed them, which in a real production would lead to an accident.
By injecting network packets with incorrect coordinates into traffic, we were able to push the manipulator out of the security zone several times and hit the physical object with the robot's “hand”. As a result, the "arm" with which the robot picks up objects fell off: The fallen off
arm of the robot is the result of introducing unsafe coordinates into traffic
Dynamic malware
This type of attack assumes that the robot is running a program written by a system integrator that is believed to be trusted. In reality, any program created by an integrator is considered trusted and is deployed without code security checks.
By compromising an integrator or replacing a program in a vulnerable network storage, you can invisibly inject malicious code into an enterprise network: add a bootloader that downloads the module the attacker needs and runs it as part of a standard production cycle.
Malware downloader written in a programming language for industrial robots
To test this concept, we wrote a dropper in a programming language for industrial robots and made sure that an external program can be used to load the code into the robot controller and execute it. Once controlled, such a program can perform further malicious actions by collecting information about the network infrastructure, stealing files and credentials.
Unusual RCE vulnerability
One of our findings was a completely respectable program that launches functions for execution, the names of which are received over the network. To execute them, it uses dynamic code loading, but it is not interested in what exactly it launches: the program does not provide for checking the integrity of the loaded libraries.
Vulnerable logic of a "respectable" application
A code fragment that implements vulnerable logic.
Although the program itself does not contain malicious functions, an attacker can use it to issue commands to the robot at the right time, affecting the physical world.
Crown of Creation - Malicious Worm
To demonstrate the seriousness of the detected problems, we have developed a program with the function of self-propagation and automatic updating, dynamic loading of code from the control server and the ability to remotely control it. The scan program can also perform network scanning, transfer arbitrary files to the command and control server, maintain a list of infected devices and act as a bot.
The logic of the PoC program that simulates the work of a real malware
Formation of a list of found files and sending it to the control server
Source of problems
After analyzing eight popular industrial automation programming languages developed in the past decades, we came to the conclusion that the main reason for the identified and potential vulnerabilities is that these languages contain low-level means of accessing system resources. Although these tools are not dangerous in themselves, attackers can use them for other than their intended purpose, critically affecting the safety of the robot, its operator and connected systems. For example, they can be used to move the manipulator up, lift the workpiece, lower the manipulator down and release the workpiece.
This rich set of sophisticated functions gives process engineers the freedom to develop applications in which they can retrieve data from the network, read and write files. However, since platforms do not provide secure access to these advanced features, attackers can use them to write malicious modules.
Another problem with obsolete languages for industrial automation (Industrial Robots Programming Language, IRPL), inherited along with the equipment, is that they do not have tools for checking code for unsafe patterns, similar to tools for C, C ++, C #, Java. PHP and Python.
Each OEM creates its own languages and environment in which the target programs will run. Some of them are based on real-time operating systems (RTOS), but overall there is no standardization. The semantics of each IRPL is also unique and can differ significantly from the semantics of general-purpose programming languages. Some capabilities, such as for manipulating strings or cryptographic operations, are either absent in the IRPL or not as advanced as in traditional languages.
The main sources of vulnerabilities in programs written in IRPL are three main functions:
- working with files and directories,
- dynamically loading modules and calling functions by name,
- network functions - receiving and transmitting data to external systems.
Dangerous functions available in IRPL
How to protect yourself
As with any software application that deals with untrusted data, industrial automation systems must be designed, implemented, configured, and deployed with appropriate security mechanisms.
Consolidated recommendations for ensuring the safety of programs for industrial automation
Therefore, when writing such programs, you must be guided by the following principles:
- Think of industrial robots as computers, and applications for them as extremely critical code;
- authenticate all communications;
- implement access control policies;
- implement input validation wherever applicable;
- ensure continuous sanitization of the output;
- When handling errors, do not expose unnecessary technical details;
- create the correct configurations and deployment procedures;
- Implement change management processes for industrial automation code.
Old or smart?
While traditional software developers have struggled with the consequences of unsafe programming for decades and developed various techniques to ensure victory, the world of industrial automation was unprepared to detect and prevent exploitation of vulnerabilities.
Given the pace of IT / OT convergence, it is imperative to introduce secure code development methods into the industrial automation industry. Otherwise, the next few years could bring us many reports of incidents in the industry, and the consequences of these incidents will manifest themselves not only in cyberspace, but also in the physical world.