Background
During the two years since the outbreak of the COVID-19 pandemic, intermittent labor shortages caused by the crisis have led to an unprecedented downturn in the automobile industry, due to its reliance on physical presence in factories for production. However, as early as 2016, Renault, the third largest automotive manufacturer in Europe, began experimenting with digital transformation in its factory in Valladolid, Spain. In 2017, they partnered with Google Cloud to introduce the OPC-UA standard on a large scale as the communication standard for their automobile manufacturing at Renault factories worldwide [1]. By 2021, Renault had installed more than 3,300 production line equipment supporting the OPC-UA protocol across 38 production lines in 16 countries. The uninterrupted flow of white papers released over the next five consecutive years also serves as evidence of their successful transformation, providing a suitable case study for other automakers to follow [2].
This shift towards digital transformation cases is seen as the next milestone in operational technology development for automotive manufacturers that lack a unified production control standard. In a 2018 article titled “A unified network for automotive production,” Swiss robotics manufacturer ABB Group highly praised the conversion to using OPC-UA as a unified production communication standard [3]. Compared to other communication protocols, OPC-UA offers numerous advantages, including cross-language compatibility, easy deployment, and the ability to communicate across multiple system platforms through network connections. Additionally, as a Microsoft-led unified standard, it effectively addresses the instability in production line communication caused by the chaotic development of proprietary specifications, specifications that would often vary wildly from one manufacturer to the next.
The Panacea for Factory Digital Transformation
Before the introduction of OPC (OLE for Process Control) communication specification, communication between HMI and PLC in factory buildings was disorganized due to the use of diverse communication protocols. For instance, communication between various factories, individual communication protocols developed by manufacturers, and the need to manage and update these numerous unique drivers each pose practical difficulties. This made it challenging for factory information personnel to manage and maintain the system, and any updates could result in plant shutdowns.
In order to provide a unified communication standard for the broad OT/ICS (Operational Technology/Industrial Control Systems) landscape, Microsoft introduced the first-generation OLE for Process Control (OPC) communication standard: OPC-DA (Data Access), also known as OPC Classic. Its purpose was to provide a fixed API interface for data exchange, enabling various HMI/PLC devices to exchange data and control equipment. This allowed maintenance personnel to finally break free from chaotic and difficult-to-manage connection and communication methods. At the same time, with a unified connection method in place, managers and operators could more easily identify abnormal connections or malicious intruders lurking in the system.
Before the introduction of OPC, the equipment HMI, PLC, and maintenance software in the factory were all individually connected for data exchange and control (as shown on the left side of Figure 1). However, after the implementation of the OPC-DA standard (right side of Figure 1), all HMI and PLC devices are centrally managed within the OPC server. The factory maintenance software or network administrator can then easily connect to the server to access data or control equipment from these devices. All connections within this system utilize Microsoft’s DCOM protocol for communication between various Windows devices. Due to the design of this protocol, the OPC-DA standard can only be deployed and used on devices within a Windows system environment, a fact that has often been criticized.
Figure 1. OPC-DA architecture [4]
OPC-UA with a Flexible, Cross-platform, Secure design
After the initial OPC-DA standard was introduced in the 1990s and received widespread acclaim, the increased adoption of Linux servers and growing concerns about information security prompted Microsoft to launch the next-generation OPC standard in 2008, 18 years later: OPC-UA (Unified Architecture). This new standard claimed to offer excellent cross-platform compatibility and security, quickly becoming the new solution for industrial digital transformation. At the same time, the definition of OPC evolved from the Windows platform-limited OLE for Process Control to Open Platform Communications.
Figure 2. Differences Between OPC-UA and OPC-DA Architectures [4]
With this new generation of the OPC-UA standard, the primary OLE/DCOM connection mode in the original architecture was replaced with the more universally friendly HTTP connection mode, addressing the issue of the previous generation being limited to the Windows platform [5]. This eliminated the Windows-specific attack strategy of lateral movement through DCOM, which was frequently exploited by hackers in traditional environments, completely eradicating it in products deploying the next-generation OPC-UA.
Trust List Mechanism
In order to completely eliminate malicious attackers infiltrating factories from the outside in the new generation OPC-UA, a strict trust list design is required in the OPC-UA standard. Both the server and the client about to connect have their respective trust lists, each containing the X509 format certificates of their own trusted devices.
At the moment of connection, the server verifies whether the certificate held by the connecting client is on its trusted device list; conversely, the client also checks whether the certificate held by the server it is about to connect to is on its own trust list. This ensures that both parties in the communication are connecting to servers/clients that are considered safe and secure by the network administrator.
Figure 3. OPC-UA Trust List Mechanism
OPC-UA Communication Architecture
However, how can we ensure that attackers lurking in factories cannot implement traditional IT network attacks (such as man-in-the-middle, ARP spoofing, or traffic eavesdropping) when the industrial control communication standard, which claims to be secure, uses an HTTP(s) server internally? We can get a glimpse of the details from the paper [6], as OPC-UA has its own comprehensive security authentication process.
When any client attempts to connect to a server, it first sends a hello (HEL) message, and the server responds with an acknowledge (ACK) message indicating the server’s current state of operation. The client then sends a GetEndPoints request to the server to learn how many HMI/PLC devices the current OPC-UA server has. Each device has its preferred security mode, encryption algorithm selection (Security Policy), and account and password information for connections (User Identify Token).
Figure 4. Introduction to OPC UA Security [7]
Once the client has selected which device to connect to through the server, it sends an OpenSecureChannel request to the server to establish a secure channel to the specified device (Figure 5). The server then creates a new session, recording the client’s information such as the connected device, encryption mode, and account and password information.
Figure 5. OPC-UA Message Exchange Process [6]
Next, the client can send requests to the newly established Session using the specified encryption connection mode. This request’s Session serves as the channel for communicating with the designated device, sending data read and write requests, or controlling the device. This is done with the help of the server, ensuring secure access to the HMI/PLC device.
Once the client has completed all tasks, it can call CloseSession and CloseSecureChannel to notify the server to revoke the session and the secure channel. This helps the server clean up any records caused by the client’s connection, ensuring that the server can maintain long-term efficient and clean operations. For a complete understanding of all the processes mentioned above, refer to the diagram in paper [6].
The State of OPC-UA Vulnerabilities: A New Focus for Attackers
You might be wondering, is there no flaw in the widely used OPC-UA in today’s industrial manufacturing? Perhaps hackers are further ahead in this race than we imagine. Due to the importance of OPC-UA as a unified communication standard for a diverse range of industrial control devices, last year’s top global vulnerability competition, Pwn2Own 2022, included the highly utilized Prosys OPC UA SDK for Java [8] as one of the vulnerability bounty items. A cybersecurity company research team won a high score of CVSS 7.5 for a severe OPC-UA vulnerability that allowed hackers to easily paralyze an entire factory’s operation from outside. But did ethical hacker researchers only begin focusing on this standard’s issues in 2022? Not necessarily. A report from Mandiant last year [9] reveals that a nation-state hacker group, INCONTROLLER, targeted PLC equipment vendors in an attack and paralysis operation as early as the end of March 2022. The toolkit used by the hackers in this operation was found to have a high overlap with those used in the 2015 and 2016 Stuxnet attacks in Ukraine. In these operations, OPC-UA’s practical vulnerabilities and design issues were powerful weapons for attackers that allowed them to conduct reconnaissance, leak information, and even paralyze factories from the outside.
As OPC-UA vulnerability research has become a new focus of attack in both the community and the wild, after introducing the modern industrial control communication standard OPC-UA in this article, we will discuss the attack strategies against OPC-UA that have been discovered by researchers and exploited in the wild in the following series of articles. These include deserialization issues, practical trust list design vulnerabilities, and the resulting strategies that allow attackers to remain lurking in factories for an extended period of time.
References
[1] OPC Connect, “Digital Transformation at Groupe Renault”, OPC Connect, March 2022, Accessed Feb 7 2023
[2] OPC Foundation, “OPC UA Users and Experts – Conveying Knowledge and Experience”, OPC Foundation, March 2021, Accessed Feb 7 2023
[3] Stefan Hensel, “A unified network for automotive production”, B&R, Sep 2018, Accessed Feb 7 2023
[4] OMRON, “White Paper Series What is OPC UA”, OMRON, Accessed Feb 7, 2023
[5] Mario Hildebrandt, Kevin Lamshöft, Jana Dittmann, Tom Neubert, Claus Vielhauer, “Information Hiding in Industrial Control Systems: An OPC UA based Supply Chain Attack and its Detection”, IH&MMSec, June 2020, Accessed Feb 7 2023
[6] Sten Gruner, Julius Pfrommer, Florian Palm, “RESTful Industrial Communication with OPC UA”, IEEE Transactions on Industrial Informatics, Oct 2016, Accessed Feb 7 2023
[7] Erba, Alessandro and Müller, Anne and Tippenhauer, Nils Ole, “Resting on Feet of Clay: Securely Bootstrapping OPC UA Deployments”, CISPA Helmholtz Center for Information Security, Nov 08 2021, Accessed Feb 7 2023
[8] PROSYS OPC, “OPC UA Pwn2Own Resource Exhaustion Exploit”, PROSYS OPC, May 11 2022, Accessed Feb 7 2023
[9] Nathan Brubaker, Keith Lunden, Ken Proska, Muhammad Umair, Daniel Kapellmann Zafra, Corey Hildebrandt, Rob Caldwell, “INCONTROLLER: New State-Sponsored Cyber Attack Tools Target Multiple Industrial Control Systems”, MANDIANT, Dec 02 2022, Accessed Feb 7 2023
[10] Eran Jacob, “A Broken Chain: Discovering OPC-UA Attack Surface and Exploiting the Supply-chain”, OTORIO, Aug 5 2022, Accessed Feb 7 2023
[11] RFID & Wireless IoT, “OPC UA – Bridging the Gap from the Sensor to the Cloud and Back”, RFID & Wireless IoT, Accessed Feb 7 2023
