Author: Tian Di He Xing Industrial Cybersecurity Research Institute
However, if we look at the tasks that advanced attackers can accomplish from a different perspective, while considering the system as a whole, this system is not just composed of things in the factory workshop. For example, what would happen if an attacker could blend in with legitimate network traffic or normal host activity? What would such an attacker do to maintain persistence? Are there unique attack opportunities that may be overlooked, perhaps outside the network scope?
The following figure illustrates the many dependencies in the software and data ecosystem surrounding smart manufacturing systems. During the development phase, there are software plug-ins and digital twin models provided by vendors, or software plug-ins and digital twins developed on engineering workstations (which can also be optionally uploaded to online directories, typically provided by software extensions). This workstation is also used to create custom automation logic (for machines such as robots) or firmware for custom IIoT devices. All of these, along with other components such as human-machine interfaces, manufacturing execution systems, and programmable logic controllers, enable the automation logic to work. High-level business decisions are translated into data written in ERP systems (or other databases), which in turn define operations scheduled by MES, and then define automation routines executed by PLCs.Here, the indirect impact of the software supply chain on the final automation operations can be seen.
The following figure visualizes the attack opportunities within data and software dependencies. Attacks involving compromise through malicious industrial plugins and attacks involving the “Trojanization” of custom IIoT devices abuse software components, which are now possible and have already been used in the wild due to the complex supply chain that contains numerous vulnerabilities. Attacks involving vulnerable mobile human-machine interfaces demonstrate how information leaked from mobile HMIs can be exploited to access the machines controlled by those HMIs. Attacks on MES data management show how any manipulation of data at the ERP system or database level can later impact automation.Attacks on vulnerable or malicious automation logic in complex manufacturing machines are inherently more complex as they exploit vulnerabilities within the automation logic.
Experts indicate that isolating smart manufacturing systems in dedicated, isolated networks is a common practice. These systems are viewed as black boxes, and in a sense, it is believed that no one can compromise them. On the other hand, connectivity is increasing, and vendors are pushing for wireless networks to be established at the factory level, directly connecting assets like industrial robots to wireless networks.
Attackers may have various motivations to cause failures, damage products, or alter workflows to manufacture defective products: attackers may be hired by competitors, may have financial motives (for example, attackers may demand payment in exchange for not disclosing confidential information they have stolen), or may simply want to affect the overall reputation of the factory. Attackers may also be interested in automation logic, which is often well-protected intellectual property.
In recent years, researchers have discovered numerous supply chain attacks targeting software development tools or libraries (especially open-source code repositories) that may target the software itself or certain third-party extensions of that software.Interestingly, it has been reported that 42% of attacks in the manufacturing sector are not directly targeting facilities but rather certain systems within the supply chain.
The following figure highlights the security-sensitive areas of smart manufacturing systems, focusing on the physical network perimeter. The factory layer network is separated from other networks (such as the internet, corporate networks) by firewalls, and red indicators represent endpoints that can serve as attack entry points.
2.1Engineering Workstations
Engineering workstations are systems shared with domain users that are always connected to the production layer. They are used to develop and deploy program logic or connect to field devices (such as programmable logic controllers, HMIs) for maintenance, diagnostics, or reprogramming. Sometimes, they are simply used to deploy programs developed elsewhere, potentially by system integrators working off-site.
Any workstation used for engineering purposes has a trust relationship with the rest of the system. Sometimes this relationship is known and is part of the security plan. Other times, considering the indirect or implicit trust relationships between the party developing the automation logic and the smart manufacturing system that ultimately deploys that logic makes it harder to see. This does not necessarily mean that developers are malicious: their computers may simply have been compromised, or even a library they use may have been compromised at the source code level. A good example is the xcodeghost malware, which was used in one of the earliest supply chain attack instances: one of the techniques of this malware was to modify the Xcode compiler, allowing the compiled iOS applications to become infected.
2.2Custom IIoT Device Development Environments
Custom IIoT devices programmed by system integrators or internal staff, such as embedded systems, Arduino-like devices, Raspberry Pi, or other single-board computers, are becoming increasingly popular due to their greater automation flexibility compared to traditional automation hardware (such as programmable logic controllers).
There are numerous trust relationships between multiple software libraries in this ecosystem and the smart manufacturing system where the final deployed software resides. Developers are likely to need to use third-party libraries, libraries based on third-party libraries, or third-party libraries based on another party’s libraries. This software dependency chain is very complex.Developers cannot easily verify the end-to-end integrity and authenticity of libraries, which may lead to the inclusion of Trojan components.
2.3Manufacturing Execution System Databases
MES databases are typically shared with the upper layers of the automation pyramid. Their function is to contain work orders and work templates, which are clearly sensitive data. When work templates are created on the MES, new records are saved in the database.Similarly, when work orders are initiated, the status of production operations is also updated in the database.
At a conceptual level, the MES trusts the data coming from the database. This means that, without authentication and integrity of the data stored in the database, an attacker on the network or database could forge or alter records, leading to changes in production. Changes could occur at the product feature level and could be seamless.
Diving deeper into the specific aspects of smart manufacturing technology, the components that provide attack opportunities include:industrial plugins, custom IIoT devices, human-machine interfaces, manual coding stations, and complex programmable manufacturing machines.
3.1Industrial Plugins
As the pace of innovation accelerates, the delivery mechanisms for industrial software are also evolving. Specifically, some solutions have been inspired by the app store model. For example, ABB has an app store where anyone can register (registration is automatic and only requires email verification) and upload plugins for ABB’s RobotStudio, which engineers use to write automation logic for ABB industrial robots. There are about 1000 plugins in the store, some of which have been downloaded thousands of times.These numbers must first be considered in light of the fact that industrial robotics is currently a niche field, and developers tend to “keep everything in-house.” This is expected to change, and app stores like ABB’s are the first signs of this directional shift.
Solutions for smart factories are similar to ABB’s app store. However, it is not specifically for robotics but for general industrial applications. Individuals cannot upload applications; only registered enterprises can.Applications are purchased through business-to-business (B2B) channels and provided through business-to-consumer (B2C) channels.
OrangeApps, developed by Kuka, although not directly developed or managed by Kuka. Unlike ABB’s app store, OrangeApps does not accept user-submitted content and is a closed ecosystem. Interestingly, it provides applications for both desktop software and industrial robot controllers. Therefore, applications obtained from OrangeApps include code that runs directly on industrial robot controllers. However, network transmission uses pure HTTP, which allows for the possibility of man-in-the-middle (MitM) attacks.
Siwiat’s solution has a slightly different model: vendors provide hardware (IIoT devices) that can be extended by downloading applications from the app store. This software delivery model is very similar to the mobile device ecosystem, where users simply purchase a piece of hardware and extend its functionality by downloading (trusted) applications delivered from the store. In fact, anything from the app store is considered trusted.
3.2Custom IIoT Devices
Widely and highly dispersed “industrial-grade” embedded devices (often Arduino-compatible) are used for rapid prototyping and production purposes. Examples include Arduino Industrial 101, Industrial Shields devices, Industrino, Iono Arduino, and Siemens Simatic IoT2000. These IIoT devices offer end-users comprehensive software customization capabilities. However, the increasing demand for customization and flexibility expands the attack surface in industrial factories like smart manufacturing systems.
Most industry experts confirm that they have used some custom devices to run custom firmware in actual production. Even in industrial 4.0 laboratory environments, there is a (separate) network of Raspberry Pi nodes that monitor the physical conditions of the factory using sensors (such as temperature, pressure, light, noise).
“Extra” devices connected to the ground network are becoming increasingly common, which in itself poses a risk. In fact, there have been cases where such devices were used to breach critical facilities. In 2018, a hacker targeted an unauthorized Raspberry Pi device to access the NASA Jet Propulsion Laboratory (JPL) network. Moreover, the miniaturization of electronic components and the accessibility of manufacturing laboratories have made it possible to create hardware implants as small as the metal part of a USB key.
Custom IIoT devices can run complex firmware and often include several external libraries with further dependencies. The management of the software supply chain for custom IIoT devices is more complex compared to vendor-provided hardware and software solutions. The primary risk is that, apart from the official libraries provided by Arduino, there are no integrity mechanisms to ensure that the libraries used by these devices are authentic and unaltered. In fact, attackers have realized that if they can find a “source” by compromising popular libraries or by “typing” their code into the final product (rather than the original product), they can simultaneously compromise a large number of computers.
3.3Human-Machine Interfaces
Research findings targeting human-machine interfaces (HMIs) indicate that HMIs often run outdated, vulnerable software. HMI technologies and custom deployments create opportunities for attack types, rather than traditional HMI-side software vulnerabilities.
Web-based and cloud-based solutions, as well as application or plugin-based systems, have led to traditional HMIs becoming more interconnected. HMIs have also evolved from a static definition of “interaction” to a more flexible concept, providing means for end-users to design or customize interfaces and quickly upload and integrate into existing systems.These features make human-machine interface components complex, leading to a larger attack surface.
For example, even in test setups in research laboratories, HMIs are mixed and use embedded web browsers, allowing factory operators to customize UIs (e.g., by providing custom HTML or JavaScript resources) without the intervention of system integrators. Experts designing manufacturing plants for large clients confirm that this is often requested by clients. Attackers can manipulate a simple webpage, delivering not only vulnerabilities but also employing UI tricks to deceive operators and influence their decisions (e.g., simulating errors or emergencies). Users may trust HMI screens and take action based on their inputs, especially when the authenticity of the embedded web pages cannot be ensured.
Due to their flexibility and ease of use, mobile devices like tablets and smartphones make good human-machine interfaces. Although HMIs are a relatively niche market, over 170 HMI applications have been found on the Google Play Store, with more than 40 applications installed over 1000 times, and in some cases even exceeding 100,000 times. Researchers not only expect that the demand for these solutions is continuously growing, but also that mobile HMIs have usability and security advantages over classic HMIs.In addition to users being accustomed to using mobile devices, they are also more flexible and easier to manage than industrial computers running HMI software. Because applications running on modern mobile operating systems are sandboxed, they are easier to keep updated and inherently more secure, which is a significant feature lacking in touch-based industrial computers running outdated versions of Microsoft Windows.
However, due to their flexibility and the fact that hardware is generic computing devices, mobile HMIs are susceptible to other categories of attacks. At the physical network layer, mobile HMIs connect via wireless protocols (Wi-Fi or Bluetooth), making it easier for attackers to access them compared to wired connections. The primary risk is that the design of mobile HMIs assumes, like traditional HMIs, that they are located within closed wired networks. For example, in Comau’s PickApp (a human-machine interface for interacting with industrial robots), the network protocol used does not enforce any integrity or confidentiality of the data and does not authenticate endpoints or perform any authentication, meaning that as long as the data complies with its application protocol, it will trust any data.
Like other applications, mobile HMI applications may inadvertently carry sensitive information (such as credentials and private keys). The key point here is that this information will be exposed since the preferred delivery mechanism is through app stores.
3.4Manual Coding Stations
In smart manufacturing systems, MES plays a crucial role as the gateway between high-level manufacturing scheduling (such as ERP) and the actual production of goods in the manufacturing workshop. The MES market is “closed” and oriented towards specialized solutions. For example, researchers could only find two open-source solutions, with no more commercial and enterprise products, the most popular of which include GE’s Predix manufacturing execution system, Honeywell’s Connected Plant, Rockwell Automation’s FactoryTalk Production Center MES, SAP MES, and Wonderware MES.
Enterprise-level MES is very expensive and difficult to access. From a security research perspective, this is clearly a problem, as it is crucial to access real, mature systems for security testing. Apart from cloud-based solutions and some transient instances of Wonderware that we found through remote desktop protocols (possibly honeypots or staging systems), it is unlikely to find internet-facing MES.
From a security perspective, it is reasonable to assume that attackers are already within the network. Regarding lateral movement, this does not mean assuming that attackers can access the MES (otherwise, it would be too late). For example, researchers believe that attackers can only access the MES database without accessing the entire MES endpoint.
3.5Complex Programmable Manufacturing Machines
Complex programmable machines (such as industrial robots) execute their manufacturing tasks based on task programs, which are essentially scripts executed on the machine (e.g., “move right,” “open claw,” “move down,” “pick up item”). Each machine vendor has its own domain-specific language for writing task programs, such as ABB’s Rapid, Comau’s PDL2, Fanuc’s Karel, Kawasaki’s AS, Kuka’s Robot Language (KRL), Mitsubishi’s Melfa Basic, Yaskawa’s Inform. These industrial robot programming languages (IRPLs) are proprietary, and each language has a unique set of features.
IRPLs are very powerful as they allow programmers to write automation programs and can also read and write data to the network or files, access process memory, execute code dynamically downloaded from the network, and so on. One of the main use cases for this powerful capability is the need to integrate with middleware software, which allows robots to communicate with vendor-neutral solutions (such as the Robot Operating System Industrial, ROS Industrial), which is the most popular solution and many top industry brands are part of the ROS Industrial consortium.
If misused and without proper security awareness, these powerful capabilities can be very dangerous. First, if used without input validation (which is the most common case we found), these features can introduce vulnerabilities. Second, due to the lack of permission separation during execution, a program that performs simple machine movements may be indistinguishable from a program that reads from the network, writes to a file, or executes that file (i.e., similar to dropper behavior) or scans the network to impact the manufacturing machine’s movements and other characteristics that affect the physical environment.
Attack vectors can be malicious task programs that conventional security scanning programs cannot detect (similar to how PowerShell or JavaScript malware variants are often undetectable), or Trojan task programs with dropper functionality that download malicious payloads and execute them under unexpected circumstances.
4.1Exploitation of Vulnerabilities
Smart factory systems consist of countless devices and apparatus connected to a single network. Any vulnerability present in any of these devices could expose the system to any form of attack. In fact, the Stuxnet worm is an example that exploited certain 0-day vulnerabilities for propagation. Stuxnet garnered attention because it targeted critical infrastructure.Successful attack activities using vulnerabilities highlight the importance of good security practices, such as regularly patching vulnerabilities.
4.2Malware Installation
Past attacks have shown that malware deployment is the most commonly used method by threat actors. Malware installed on industrial networks can jeopardize industrial control systems (ICS), such as BlackEnergy and Killdisk. The Trojan Triton is noteworthy because it was specifically designed to manipulate industrial safety systems and shut down operations at an industrial plant. Recently, it was discovered that threat actors used cryptocurrency mining malware to attack a water supply facility in Europe.
Threat actors use different types of malware to conduct attacks, such as rootkits, ransomware, and Trojans. They also consider how to effectively deploy malware, which means a method that can cause maximum damage or penetrate the target’s defense system without being detected. They can utilize techniques such as social engineering, spear phishing, and watering hole attacks.This is why manufacturers should not only raise cybersecurity awareness for smart factory operators but for all employees as well.
4.3DoS and DDoS
DoS is a type of network attack aimed at disabling or shutting down networks, devices, or resources.DDoS is a distributed DoS that uses a large number of compromised devices (bots) to attack the target system’s connections or processors. For example, the IoT botnet Mirai shut down several well-known websites and online services. Although its impact on the industrial sector is not well known, it still demonstrates the potential effectiveness and consequences of DDoS attacks. With the release of its source code and the emergence of DDoS-as-a-service providers, it is not hard to believe that DDoS attacks targeting smart factories and other IIoT infrastructures will increase in the future. Similarly, compromised ICSs may ultimately be used by botnets to attack other organizations.
4.4Man-in-the-Middle Attacks
Man-in-the-middle (MitM) attacks involve threat actors entering the communication channels being used by the company. Smart manufacturing systems require multiple communication channels to facilitate their processes, such as communication between control systems and devices. In addition to forwarding information to malicious third parties, this attack may allow attackers to input their own code or data. For example, insecure communication protocols may allow attackers to modify firmware upgrades during transmission. Man-in-the-middle attacks emphasize that ensuring the security of communication channels is essential for the overall security of the system, in addition to device and network security.
4.5Reconnaissance and Information Theft
Attackers can also take a more subtle approach by stealing information or monitoring exposed systems during their activities. For example, exposed HMIs may expose customer databases, and attackers may steal personally identifiable information (PII). This threat and its chain effect may impact exposed integrated circuits in critical sectors and other industries. By gaining unauthorized access to the network, threat actors can also steal information about device behavior that is usually necessary for the automated functions collected by their sensors. Such attacks on the network highlight the importance of APT intrusion detection and prevention systems.
4.6Device Attacks
The number of connected devices inside and outside the factory floor does not diminish the importance of each device to the overall security. Attackers can use a single compromised device to spread malware or access the entire industrial network. If attackers gain physical access, they can even tamper with actual devices. They may cause the tampered devices to send erroneous information to other parts of the network or simply fail and impact other parts of the production line.
References:
1. TrendMicro, Attacks on Smart Manufacturing Systems, A Forward-looking Security Analysis
2. https://iiot-world.com/cybersecurity/security-threats-and-risks-in-smart-factories/
