How We Hacked a Smart Factory

Object of study

The complexity of intelligent manufacturing systems is so great that it is difficult to give them an exact formal definition. Today, the concept of a reference production infrastructure does not exist even as a concept. However, with increasing complexity, the number of threats also increases, and the perimeter expands, which can be affected by cybercriminals who pursue various goals.
Without trying to grasp the immensity, we decided to focus on one instance of the intellectual production system, which includes both hardware and software components in the form of control software, development and monitoring tools.

Industry 4.0 Lab is the subject of our study. Source (hereinafter, unless otherwise indicated): Trend Micro

The object of our study was the Industry 4.0 Lab, created by Fiesto on the basis of the Technical University of Milan (Politecnico di Milano). It includes seven stations, programmable logic devices and human-machine interfaces of Siemens, as well as physical drives (drills, presses), temperature and pressure sensors, conveyor belts and the industrial robot Mitsubishi Melfa.

Block diagram Industry 4.0 Lab

Research Areas

In a smart manufacturing system, we distinguish the following safety-sensitive areas:

– Industrial software that comes in the form of add-ons, extensions or stand-alone applications

We made sure that this software can become a powerful vector of attacks, which until now has not been seriously considered. If the software delivery platforms – application stores, extension directories, etc. – are not properly protected, they turn into a hotbed of malware through which critical endpoints will be infected, for example, engineering workstations from which attacks can spread to production workshops and gain a foothold on the equipment, having introduced itself in the form of machine code through a vulnerability in the firmware of an industrial robot.

– Custom IIoT devices

This trend is becoming more and more popular in leading enterprises, as it allows engineers to run fully customizable automation logic at the production site. This distinguishes these devices from more traditional PLCs. However, this flexibility has another side, which requires changes in the security management model: instead of trusting one software developer, for devices you have to manage a rather complicated and confusing chain of trust, which includes developers of third-party libraries that were used by enterprise engineers, and also all libraries on which these components depend.
Considering that recently compromise of software libraries and developer accounts in software repositories is used quite often by cybercriminals, we consider it necessary to single out this risk as a vector that will have an increasing impact on the threat landscape.

– Human Machine Interfaces (HMI)

This is a central component of the ecosystem of intellectual production. HMIs provide cybercriminals with a wide attack surface, since in most cases they are ordinary computers with a significant number of interfaces, and their OS and software are rarely updated. This means that they remain software vulnerabilities that can be compared with the wide open doors for cybercriminals.

– Production management systems

This is the most sensitive endpoint for a smart enterprise because it acts as an intermediary between the production hall and the rest of the corporate network, for example, the ERP system. Production management systems contain complex automation logic and interact with one or more databases. Introducing incorrect changes to these databases can cause the release of marriage or even damage to the executive mechanisms, if the boundaries of safe modes are not specified in the system.

Data and Software Relationships in the Context of a Smart Manufacturing System

– Programmable production machines

Industrial robots often have processing power that is redundant for simple physical movements representing their basic functionality. The ability to perform general-purpose computing tasks with their help can be used by attackers to hide malicious logic from modern solutions for protecting endpoints, since they are not intended to verify the firmware code of industrial systems.

About the human factor

We deliberately excluded from the consideration the influence of people on safety, since social engineering is beyond the scope of this study. At the same time, we examined how technology can be abused in order to influence operator decisions using various tricks of the user interface, but we did not analyze how effective the impact of such methods would be.

One of the most underestimated in terms of danger vectors of attacks on industrial systems is the impact through malicious software and add-ons. Consider these attacks in more detail.

Software vectors and targets of attacks on industrial systems

Attack through malicious industrial software add-ons

Using tool software and development environments specific to industrial automation, an attacker can gain access to targeted jobs for engineers, steal their secrets and inject Trojan code into each program they develop. The result is software for machines and robots, “charged” with the necessary attacking functionality.
Not only Google, Apple and Microsoft have their own application registry. Industrial software developers also use their own application registries, from which engineers can download add-ons that extend the functionality of their development environments. Unfortunately, some of the popular industrial software directories contain vulnerabilities that allow you to load unverified extensions into it.

Vulnerability in the ABB extension catalog led to the fact that extensions for RobotStudio became available in the development environment immediately after loading, before the verification and approval stage

Examining the application directories, we found the following serious problems that could potentially lead to serious consequences:
1) a weak verification process, more similar to its absence;
2) the absence of a “sandbox” for the implementation of add-ons downloaded from the catalog;
3) the availability of add-ons uploaded to the catalog prior to their verification and approval;
4) lack of code integrity verification;
5) the use of unencrypted network connections.

– Weak verification process

The ABB add-ons directory does not have a developer verification process. Anyone can register and download add-ons, and, as we have seen, strict verification of the downloaded files is also not performed. One of our partners downloaded the harmless add-on without any problems, the description of which contained the following text:
prepared and downloaded to make sure that in this application directory there is a manual check procedure, (…) to check if anyone can load software that does not perform any useful actions into this directory.

The add-on was easily approved, and for 10 days 18 users downloaded it for some reason.

After downloading and automatic installation, the RobotStudio add-on can do anything with the workstation

– Lack of sandbox

We wrote and uploaded a harmless add-on to the ABB directory and made sure that it can do anything on the workstation, including bypassing the file system, establishing network connections and making http requests to send data to the management server. Such a wealth of opportunities gives attackers many opportunities, especially considering the following problem.

A freshly loaded extension module is not displayed in the application catalog via a browser, however, it is already available for installation through the built-in RobotStudio interface.
– Availability of add-ons prior to approval

After uploading to the directory, the add-on should theoretically pass a test before being approved and made available for download. However, due to an error, unapproved extensions can be downloaded through RobotStudio’s built-in development environment directory.
We notified ABB of the problem, and the company fixed this vulnerability, however, theoretically, it allowed remote attackers to infect RobotStudio users computers by downloading a malicious setting bypassing the verification process.

– Lack of code signature verification

The ABB application catalog is not the only source of potentially harmful add-ons. We found similar problems in Kuka.Sim, the engineering software for robots and CNC machines.
Kuka.Sim is used to design and test developed programs before installing them directly in a robot or intelligent machine. For this, digital models of various machine tools and robots are used – digital twins. Each such twin consists of a three-dimensional model and source code that determines its physical behavior. By changing the code, you can change the behavior of the model.
It turned out that eCatalog – a repository of digital models of various intelligent industrial installations and robots for Kuka.Sim – does not check the integrity of published files, which are ordinary ZIP archives. Thus, the user has no way to verify the authenticity of the model, but an attacker can easily add malicious functionality to the archive.

Unencrypted network traffic

The interaction between the Kuka.Sim client and the catalog of digital models occurs via http, that is, the traffic is transmitted in the clear, which allows for a “man in the middle” attack, replacing or intercepting model files.
If a programmer creates his program on the basis of a malicious modification of a digital model, it may turn out that it works without problems in a virtual environment, but at the same time the real equipment crashes or leads to the release of the marriage.

Conclusion: countermeasures against future threats

In our study, we consider threats that will become a reality in the near future, since there are all technical prerequisites for this. We believe that they can be prevented by performing the following measures:
– the introduction of secure coding practices in the development of industrial applications, including engineering development environments and extension catalogs – input verification, traffic encryption and authentication should be a mandatory part of any interaction;
– Creation of a complete chain of trust for data and software within the framework of a “smart” production environment: code that implements automation logic, including IoT firmware, should not just be downloaded from the developer’s laptop to an industrial machine – it is necessary to check the digital signature on the program code and all libraries; similar checks are needed in development environments;
– provide mechanisms for detecting vulnerable or malicious logic in complex production complexes in order to prevent attackers from creating a “time bomb”;
– implement a sandbox and a privilege sharing mechanism for engineering software running on industrial machines – mobile applications, for example, must request permissions before accessing storage or network resources, in the same way – as components with zero trust – automation logic and other software components must be implemented .