Cyber Threats
Experimental analysis of smart factories Part 2
Part two takes a closer look at the vulnerabilities and security risks involved in industrial application stores, which are a weak spot of engineering workstations.
Save to Folio
Previous posts
On May 11, 2020, Trend Micro released a paper showing the results of proof-of-concept research on new security risks associated with smart factories. In this series of 5 columns, based on the results of this research, we will look at the security risks to be aware of when promoting smart factories by examining overlooked attack vectors, feasible attack scenarios, and recommended defense strategies. This column is must-read content for architects, engineers, and developers who are involved in smart factory technology. Let's take a closer look at the vulnerabilities and security risks involved in industrial application stores, which are a weak spot of engineering workstations.
The EWS, a mission-critical machine
An EWS (Engineering Workstation) is a computer used for development, configuration, maintenance, and diagnosis of systems and devices in a smart manufacturing plant. Automation programs, which are indispensable for making factories smart, are developed and/or tested on an EWS and then distributed to robots and other equipment. Thus, the EWS often has the following characteristics.
- The EWS is shared by multiple personnel roles.
- The EWS is almost always connected to the factory floor network.
In addition, developers who directly or indirectly use the EWS are not limited to internal employees. Although operations vary from company to company, EWS may be used by external partners (such as system integrators and consultants), or they may be used to distribute programs developed by external partners. In other words, the EWS may be an endpoint device that executes various programs created by various people, and it also has network access to the factory equipment (Fig. 1).
<Fig. 1> The EWS is connected to factory networks and has multiple users.
Industrial application stores
As factories become smarter, their IT systems (including the EWS) are being connected to a new type of service: industrial application stores. An industrial application store is an online service that is officially provided by industrial equipment manufacturers. To make an analogy, it is an "industrial" version of the familiar app stores for mobile devices. With this service, developers can use add-ins downloaded from the industrial application store on the EWS, which offers the advantage of enabling faster, more flexible development.
Let's look at an example. The left screenshot in Photo 1 shows the home page of ABB's industrial application store. In this application store, you can upload and download the add-in of "RobotStudio," which is ABB's OLP*1 tool. Anyone can register an account with this application store and use the add-ins in the store to enhance their development workflow while writing automation logic for ABB industrial robots. The store has about 1,000 add-ins, some of which have been downloaded thousands of times. Orange Apps also provides industrial applications (right screenshot in Photo 1), although they do not have a full "app store"-like delivery model: the maintainers upload the apps rather than having the developers do it directly. Some application stores offer apps for both desktop software and industrial robot controllers. This means that an app retrieved from such a store will contain code that runs directly on the industrial robot controller.
<Photo 1> ABB's application store (left) and Orange Apps (right)
As mentioned above, the software development and delivery process is also changing as factories get smarter, and these application stores, despite being in a very experimental phase, are a concrete step forward. In the future, OT developers will more frequently leverage external cloud services and include third-party components such as apps, libraries, and add-ins. Thus, the security of these cloud services is a prerequisite for such development methods to spread. However, in this study, Trend Micro identified and reported a number of vulnerabilities in the industrial cloud services provided by these manufacturers. Here, we share our findings regarding the ABB cloud service as an example, but the purpose of this research is not to point out the vulnerabilities of a specific manufacturer; rather, it is to clarify the security risks that get overlooked with respect to industrial cloud services as well as to contribute to improving the security of the entire ecosystem.
Attack scenario: Compromising the EWS through vulnerable industrial application stores
We will now take a closer look at the security issues with the ABB application store that we identified in this research. Trend Micro notified ABB via ZDI, which promptly fixed their backend. Since the vulnerabilities were on a cloud service offered by ABB - and not contained within their software products - there was no public CVE; instead, they fixed the problem right away, and all customers immediately benefitted from the fix.
1. Anyone can upload files to the application store
ABB's application store did not have a thorough inspection process for uploaded apps. Anyone could upload their own add-ins to the service. We discovered a test app that was downloaded 18 times in 10 days from July 31st to August 9th, 2019. This means that an attacker could easily upload malicious programs to the cloud service, which users could unknowingly expose themselves to by downloading it.
2. Unapproved files can be downloaded
Even if an uploaded application had a status of "waiting for approval," it could be downloaded immediately from within RobotStudio's built-in desktop application store interface (Photo 2). This "one click" installation process increases the risk that users will come into contact with malicious files.
<Photo 2> An app that is "waiting for approval" (left) can be downloaded via the desktop built-in interface.
3. Software design issue
If the OLP software has no sandboxing features or restrictions (such as RobotStudio), once add-ins are downloaded, they can do anything to the user's system. This is a software design issue, not an implementation vulnerability, but it poses a security risk - one that is potentially broader because it is hard to fix in the short term without a complete software redesign. The test add-in created during this research recursively traversed the directory tree at "C:\Users" and collected the complete file path from it. Also, we were able to make web requests, which is essential functionality for developing information-stealing malware.
In addition to the above, vulnerabilities such as the absence of data integrity checking and a network encryption function were also identified in KUKA's digital twin simulation tool (for which ICS-CERT released an alert), but I will omit the details here due to space limitations. For more information, refer to page 52 of the research paper.
Both vulnerabilities facilitate the delivery of malicious payloads disguised as add-ins, namely the alteration of digital twins. Once again, the take-away is that the EWS can connect to both cloud services (e.g., application stores) and factory floor networks, which makes it possible to inadvertently bring in malware from the cloud.
Countermeasure: Protecting the EWS and security policy setting
Vulnerability management for application stores is a security issue that providers must implement responsibly. In this case, both ABB and KUKA responded to our reports. However, since design-level weaknesses remain, users who use application stores or similar services must also take security measures. It is essential to apply endpoint protection to the EWS, where files are executed. In addition, based on the concept of zero-trust security, it is important to minimize access from the EWS. For example, it is effective to adopt the principle of restricting communication from the EWS to specific cloud services, and to limit the facilities on the factory floor network that the EWS can access (for example, only the PLC that performs rewriting). It is also effective to set a policy such as one that only permits digitally signed applications to be used, that ensures development code is backed up on a regular basis, and that stipulates operations for achieving speedy recovery if an emergency occurs.
Malicious industrial add-ins are basically DLL files, so it is difficult to determine whether or not they are malicious programs based on the file format. On the other hand, it is very easy for today's endpoint protection software to detect malicious DLLs. Let's apply endpoint measures to the EWS and enable a function that detects whether an executed file behaves suspiciously. In addition, let's set a security policy that enables multiple users to use the EWS under a common set of rules.
In the next post, we will examine the second attack scenario, "Trojanized libraries for Industrial IoT devices."