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 protocol 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.
OPC-UA Protocol: 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 protocols, 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 protocol, 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.
OPC-UA Protocol: 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 Protocol Trust List Mechanism
OPC-UA Protocol: 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 Protocol 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, we will discuss the attack strategies against OPC-UA that have been discovered by researchers and exploited in the wild. 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.
OPC-UA Design Practice from an Attacker’s Perspective
Earlier, we discussed how the flexibility of OPC-UA has made it a popular choice for many industrial control system vendors, while simultaneously attracting attention from potential attackers as a vast blue ocean full of untapped resources. But how can we study this with a practical lens? Let’s delve into the research entitled “A Broken Chain: Discovering OPC-UA Attack Surface and Exploiting the Supply-Chain” presented at Black Hat USA, where researcher Eran Jacob gave us a look at vulnerability mining in products using the OPC-UA protocol from an attacker’s perspective.
Eran Jacob, adopting the perspective of an attacker, initially investigated the various versions of OPC-UA function libraries utilized in market products. The original suites of implementation were open-sourced, maintained, and championed by the OPC Foundation, made available as ANSI C, .NET, and JAVA versions. In response to market demand, three commercial OPC-UA suites were developed. This research reveals that these three suites, produced by Softing, the OPC Foundation, and Unified Automation, collectively hold 80% of the market share. Intrigued, Eran Jacob concentrated his research on finding common vulnerabilities among these three suites.
The dominant use of these three implementations in market products can be divided into two types: C/C++ and .NET. This research reveals that both the commercial C++ and .NET function libraries from Softing or Unified Automation have a high degree of similarity with the versions open-sourced by the OPC Foundation. This discovery was confirmed with reverse engineering. Therefore, Jacob attempted to dig into the common architectural issues in the original OPC Foundation suites, hoping to simultaneously impact Softing, Unified Automation, or even more third-party commercial OPC-UA protocol suites.
Penetrating the Core Security Defenses of OPC-UA Protocol
Earlier, we mentioned that current attack research primarily focuses on vulnerabilities like stack overflows, with attackers poised to threaten the operations of industrial control systems. In contrast to this well-known vulnerability, we will now turn our attentions to the security design that is ostensibly invulnerable—the trust list mechanism. However, is the core security design of OPC-UA protocol, which it boasts of, truly invulnerable? In a study titled “Resting on Feet of Clay: Securely Bootstrapping OPC UA Deployments“, researcher Alessandro Erba from the CISPA institute suggests otherwise. We must consider that the trust list, in practical application, might be more fragile than we initially thought.
The Overly Strict Trust List Mechanism: A Potential Hurdle in Practice
In his paper “Security Analysis of Vendor Implementations of the OPC UA Protocol for Industrial Control Systems” , Alessandro Erba points out that as early as 2017, the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) conducted a comprehensive review of the OPC-UA protocol specifications and technical details. They praised the protocol, stating that “no systemic errors were found in OPC-UA”. However, BSI’s review also raised a concern: “Practical deployment of OPC-UA presents significant challenges”. A study that conducted a large-scale scan of OPC-UA Servers on the global internet found that a staggering 92% of OPC-UA implementations in the industry were set up in an insecure manner. Even more concerning, 44% of these servers could be accessed by hackers without any authentication requirements.
Such significant risks in practical deployment piqued Alessandro Erba’s interest. He wondered: Why is the securely designed OPC-UA insecure when deployed in practice? Is it due to overly complex setup requirements? Or is it because the majority of products on the market have been implemented incorrectly, leading to such a high prevalence of insecure OPC-UA protocol installations worldwide? These questions formed the basis of his research, which was later presented at Black Hat Europe.
OPC-UA Secure Connection Handshake Process
Before discussing the issues with the current practical deployment of OPC Servers on the internet, we first need to understand the standard handshake authentication process used for establishing a secure connection between an OPC client and an OPC server. Past research has pointed out that the entire OPC specification is designed with two distinct communication strategies: (a.) Client-to-Server and (b.) Publisher-to-Subscriber, based on the MQTT concept. Both strategies allow for encrypted communication and authentication. However, the OPC-UA specification doesn’t strictly mandate encryption. Currently, the industry predominantly uses the former architecture (a.), as illustrated in Figure 4, above.
When an OPC Client connects to an OPC Server, the client uses the GetEndpoints request to the server. In response, the server provides information about all its managed endpoints. Each endpoint has three essential parameters for establishing a secure communication with the server:
- Security Mode – This defines the preferred level of protection for communication with the endpoint. Options include no encryption, signature only, or both signature and encryption.
- Security Policy – If the endpoint prefers encryption, it specifies which encryption algorithm to use, such as RSA, AES128, or combinations like signing with SHA256.
- User Identity Token – This is the desired authentication mode when establishing a connection with the endpoint. It can be anonymous, allowing anyone to authenticate, require username and password login, or send a certificate for endpoint verification.
Once the OPC Client receives a list of endpoints from the server, it can choose any endpoint to establish a connection. The client can use OpenSecureChannel to request an endpoint from the server and communicate securely with the chosen endpoint through the server. At this point, the server verifies if the certificate sent by the client to the endpoint is trustworthy.
If the server finds the certificate in its trust list whitelist, it means the certificate is trusted, indicating that the client can also be trusted. The server then establishes a secure channel, allowing the client to receive messages from or send messages to this new channel, establishing communications with the endpoint.
New UPC-UA Protocol Challenges in Trust Certificate Management and Industrial Control Transformation for Operations
In practice, both OPC Clients and Servers maintain a certificate trust list, which includes self-signed certificates and trusted certificates issued by third-party Certificate Authorities (CAs). Typically, self-signed certificates are signatures created and used internally by industrial control vendors. They aren’t trusted by external third-party CAs, so they’re manually embedded during deployment by engineers or operators.
Figure 7: New OPC Client’s Access Verification for Plant Equipment via OPC Server as per Official OPC Standards
However, this manual approach becomes cumbersome for operators managing hundreds or thousands of devices. To simplify this, OPC-UA protocol supports the Global Discovery Server (GDS) design. Engineers only need to ensure that their OPC Servers within the plant trust a single GDS located on the external network. Subsequently, when there’s a need to add any new self-signed certificates to be trusted across numerous devices, manual intervention isn’t required. The new signature just needs to be added to the GDS, which then updates the certificate trust list on every OPC Server.
Yet, as we know, protecting equipment with network segmentation in industrial settings has always been a core security strategy and value. This makes the trend of using OPC-UA for industrial control transformation a significant challenge. As a result, researchers became deeply interested in the question of “how operators manage a vast number of OPC servers in a plant without internet connectivity” and conducted an in-depth investigation.
Balancing Easy Deployment with Practical Certificate Verification: Several Leading Brands Rank High in Risk
Researchers analyzed 48 leading industrial control products that claim to support the OPC-UA standard. They individually deployed and examined these brands to understand how their official guidelines instruct customers (i.e., the operators of industrial plants deploying the products) on how to manage trust certificate issues. Their findings, summarized by a table in their paper, highlight the precarious state of OPC-UA’s practical use in industrial settings.
Figure 8: Practical Security Implementation, Concerns, and Vulnerability Ratios of Devices in the Market Claiming OPC Support
Referencing Figure 8, the study found that only 20.8% of global industrial control products genuinely adhere to the OPC-UA standard with rigorous security designs. The remaining nearly 80% are highly vulnerable, susceptible to attackers who can easily hijack OPC Servers and launch attacks that could paralyze entire plant operations. Of them all, 14.6% of the products claim to support secure designs but, in reality, have a high-risk design that doesn’t properly verify certificate trust lists. Of these, 64.6% have implemented certificate verification but fall short of security standards, leaving them exposed to hackers. These vulnerabilities can be categorized into three situations: Missing Trust List Support, Trust List Disabled by Default, and Insecure Trust List Configuration.
Missing Trust List Support
Referencing this paper, it is noted that as many as 11 products are in the ‘Missing Trust List Support’ state. This accounts for 22.9% of products supporting OPC that lack client trust verification. Additionally, their official websites lack guidance on how to deploy the trust list. While these 11 products still support the security features claimed by OPC-UA, their OPC Servers allow attackers using OPC Clients to create secure channels with endpoints that support signatures or encryption. They don’t verify if the attacking OPC Client initiating the request to the OPC Server is on a trusted list. This oversight leaves the door wide open for remote attacks by potential adversaries on the network.
Figure 9: The “Trust List Disabled by Default” Dilemma
Trust List Disabled by Default
The second situation is characterized by products having their “Trust List Disabled by Default”. For these products, the pivotal certificate verification feature of OPC-UA, a cornerstone of its security, is turned off right off the bat. Alarmingly, based on the official documentation of these products, certificate verification appears more as an optional feature rather than an integral part of their security design.
This paper cites practical examples, with Siemens’ official documentation notably suggesting that enabling the trust certificate feature would “blindly trust all certificates sent by OPC Clients”. This approach essentially makes a mockery of OPC-UA protocol’s touted security design. In real-world attack scenarios, an attacker can simply provide any certificate, even one they’ve self-signed, and their connection requests to an OPC Server within a plant would be granted. This vulnerability stems from the product’s OPC Server not verifying, but instead blindly trusting the certificates sent by attackers. Both Siemens and Bachmann products exhibit this vulnerability.
Insecure Trust List Configuration
Some OPC products enable ‘Auto-Trust’ for newly presented certificates from unknown OPC Clients during the openSecureChannel() phase to expedite certificate exchange. In the study conducted by Alessandro Erba, corresponding to the third situation mentioned in the Security Analysis of Vendor Implementation of the OPC UA Protocol for Industrial Control Systems paper, there’s a condition termed as “Insecure Trust List Configuration” or “Certificate exchange through Secure Channel primitives”. The crux of this issue lies in products that, for the sake of operational convenience in deploying self-signed certificates, allow the exchange of trust certificates during the OPC Client/Server communication phase. This means that if an attacker, posing as an OPC Client, initiates a connection to a plant’s OPC Server and attaches a self-signed certificate they control while invoking the OpenSecureChannel request, the OPC Server might mistakenly interpret this as a legitimate certificate exchange. Consequently, the malicious certificate sent by the attacker gets installed into the server’s trust list, effectively allowing the attacker to flagrantly bypass the security measures.
Table 1: Comprehensive Chart from the original study, Evaluating Real-World Security Implementation in Various OPC Products
The conclusion of the security analysis research paper provides an overview of the current state of certificate verification and security implementations by leading global brands. This serves as a valuable security benchmark for selecting OPC-UA products. Additionally, there’s a comprehensive chart for engineers and researchers highlighting which programming languages’ OPC-UA libraries fall short of the security standards.
Table 2: Original Study’s Analysis of Security Implementation Across Open-Source and Commercial OPC Kits in Various Languages
Figure 10: History and Source of the Current Mainstream OPC-UA Commercial Suites in the Market
OPC-UA Protocol’s Flexible Features: An Asset or a Potential Breach Point?
Before diving into architectural issues, the researcher attempted to understand the touted flexible features of OPC-UA and whether its potential could present exploitable opportunities. Figure 11 indicates that OPC-UA’s reputed flexibility and adaptability in practice are comprised of three aspects: Complex Datatypes, Flexible Encoding, and Pre-security Messages.
Figure 11: Top 3 Frequently Discussed Major Design Features of OPC
Earlier, we mentioned a Trust List mechanism, which guarantees that both the Client and Server involved in setting up a connection are on the trust list. This mechanism provides diverse, user-friendly data structures and enables data to be encapsulated and transmitted in a variety of encodings. Additionally, to improve ‘efficiency’, the OPC Server eliminates the need for expensive whitelist verification processes when dealing with certain API requests that it frequently receives from the Client.
In OPC-UA protocol, in addition to the most basic variable types (such as arrays, strings, text, etc.), there are four additional unique data structures that can be used, namely Variant, Extension Objects Used as Containers, Diagnostic Info, and Data Value. The most intriguing feature is that any variable in OPC-UA can contain any OPC-UA structure, XML, or even binary code. There can even be problematic situations where, within the structure of Extension Objects there are variables that also contain Extension Objects; this creates an issue of self-referential complex variables in the data structure, caught in a recursive loop that can affect the normal operations of the system. This piqued the researcher’s attention: could an OPC Server, which is supposed to operate efficiently, function well if this issue of Unlimited Nesting (self-referencing complex variables) arises?
Recursive Structure Causing Stack Overflow in .NET Runtime Parsing
Figure 12: Following CVE-2018-12086, OPC Foundation Added ‘Recursive Parsing Depth’
Validation in the Source Code
Under the promotion of the OPC Foundation, their official .NET Standard open-source implementation (and other commercial variations) has become the preferred suite for the production stage in the industry. Upon studying the public source code of .NET Standard, researchers discovered that the official version had made some patch measures as early as 2018 to defend against Nesting Issue type of attack tactics. The patch method is such that each time an OPC server parses a complex variable, if it needs to recursively unfold a variable and its sub-variables, it will then record and confirm that the current recursion depth does not exceed a certain threshold. Should the recursion depth exceed that threshold, the server will abandon parsing the current connection so as to prevent a server crash.
However, why does the official version claim to modify numerous parts of the code to guard against this type of issue? This sparked the researcher’s intense interest and was mentioned in the lecture, “The Current Mainstream OPC-UA Suites are all Based on .NET Runtime (.NET Framework / .NET Core)”. Running on .NET can be considered a natural defense against traditional hacker RCE attacks and Memory Corruption tactics. However, .NET language isn’t particularly suited for handling recursive function behavior. This is because the default stack memory size of .NET Runtime is limited, and exceeding a certain recursion depth can easily trigger Stack Overflow in the underlying .NET Runtime, leading to a crash. This is a problem not initially considered in the OPC-UA protocol concept. For example, the famous CVE-2018-12086 caused the OPC Server to crash just by transmitting a 64KB Extension Object structure.
Figure 13: OPC’s Data Variable Design- An Exploitable Complex Data Structure Matrix
Naturally, one might presume that after the fallout of CVE-2018-12086, the subsequent official patch should have rendered this category of attack strategies ineffective. This, however, may not be entirely accurate. There may be persisting issues related to other OPC-UA language features, which could be exploited to uncover more vulnerabilities for the same type of attacks.
The research team provided a specific instance from OPC-UA where they utilized a feature to unearth a fresh OPC vulnerability in 2021: They declared an OPC Variant variable and incorporated a Variant array within its structure. Each Variant in this array accommodates another array, and this continues in a chain.
If the data is nested deep enough, and is transmuted into an XML encoding package supported by OPC, which is then dispatched to the server for interpretation, it’s worth observing whether this practical illustration could inflict any substantial impact on the server’s performance, or perhaps even provoke a disastrous system crash due to vulnerability exploitation.
Learning from History: A Real Vulnerability That Devastates All OPC Servers
Figure 14: OPC-UA Protocol Allows Un-Secure Clients to Send Requests Containing OPC Variables
At this point, one can’t help but wonder: even if there are such maliciously tailored OPC packets that attackers want to send, shouldn’t the highly secure OPC be able to protect the trustworthiness of both ends of the connection through the Client/Server mechanism with a Trust List whitelist? How could there still be a chance for attack requests to be sent to the server? This goes back to what was previously mentioned: for the sake of efficiency, the server does not actually enforce a whitelist verification on high-frequency operation APIs such as OpenSecureChannel, GetEndpoints, FindServers, etc.
Therefore, in practical instances, an attacker can masquerade as an OPC Client, initiating a FindServersRequest to the server that isn’t restricted by the whitelist, and embed highly nested OPC variables within this request. This would render the server’s whitelist mechanism ineffective, and it would accept the malicious OPC variable from the attacker. During the parsing process, the attacker can recursively call functions an excessive number of times, ultimately leading to a stack overflow, causing the .NET Runtime to proactively shut down the software process of the OPC server.
This is the exploitation process of the infamous CVE-2021-27432. When this vulnerability was reported, not only were all OPC packages from the OPC Foundation affected, but the scope also extended to third-party cooperative OPC packages—including those from Softing and Unified Automation—with over 80% of the market’s products being affected. This also marked the first attempt by a research team to attack and maliciously exploit weaknesses of the abnormal crash type since the OPC Foundation made major security revisions in 2018.
From Service Crash to People: Attackers Target Factory Maintenance Personnel
Figure 15: Software Attacks on OPC Server; Paralysis Leads to Physical Security Concerns in Operational Factories
Contrary to past IT vulnerabilities where attackers often aimed to take control of the machine, the researchers in this study suggest that this type of attack could become a new pattern in OT/ICS, shifting the ultimate goal from machine control to a higher level of human risk. This is due to the unique role of the OPC Server in the industrial control domain: the OPC Server is responsible for receiving information and issuing commands to endpoint devices like PLCs, HMIs, robotic arms, etc., within the factory. This allows engineers at the SCADA workstation to keep real-time tabs on factory operations without physically being in the factory.
Therefore, an abrupt halt in the OPC Server, which serves as the eyes within the factory, would result in engineers and maintenance personnel being unable to immediately grasp the status of the factory, leaving them effectively blind and defenseless. Subsequent physical attacks that the attacker truly wants to launch against the factory would be dangerous and destructive, potentially leading to a repeat of historical tragedies such as the Stuxnet incident.
Digging into the OPC-UA Protocol Specifications for More Exploitation Opportunities – XXE
From the perspective of an attacker, any opportunity to collect more components for weaponization cannot be overlooked. The researchers found that during their code review of the commercial OPC package Unified Automation, a typical XXE vulnerability commonly exploited in traditional web penetration activities had not been properly addressed and protected against.
Figure 16: Risk of XXE Injection Attacks within XML Parser of the Unified Automation Suite
As previously mentioned, regardless of brand, all implementations of OPC-UA must support XML encoding and decoding by design. During their reverse engineering of Unified Automation’s code, the researchers discovered that the package does not disable the built-in XXE (XML External Entity) function of the XML parser during XML string parsing. This means that an attacker could craft an XML document that directs the parser to pull content from a URL or file path and parse it into the XML document.
This attack method is similar to the previously mentioned nested parsing supported by OPC variables, and can thus be maliciously exploited to dramatically increase the memory consumed by the OPC Server during XML parsing, eventually leading to a stack overflow and server crash. This vulnerability was reported and assigned the identifier CVE-2021-27434.
The Issue of Deserialization: Even Commercial OPC-UA Suites Designed in C/C++ Contain Vulnerabilities
Figure 17: Use of Custom C++ Structures for Message Serialization and Deserialization in Softing’s OPC-UA System
In an effort to thoroughly probe all potential vulnerabilities in OPC-UA, the researchers also explored whether there were other potential exploitable tactics in the C/C++ (or ANSI C) implementation of OPC-UA suites, beyond the server stack overflow strategies resulting from nested variable parsing. For this, they selected the commercial OPC-UA suite Softing’s C/C++ package as their target for vulnerability mining.
Figure 18: The Serialization and Deserialization Process of Extension Objects in Softing’s OPC-UA
Figure 19: Parsing Errors and Unusual Crashes in Softing’s OPC Server
The researchers point out that to ensure the effective transmission of diverse OPC data structures, the Softing C/C++ suite first encapsulates each OPC structure carrying data into a specific C++ structure known as OpcUa_ExtensionObject_Body. This is done prior to every transmission for network transmission. When this C++ structure is received at the server, the TB5OT.dll function is invoked to parse and then deserialize it, converting it back into the corresponding data laden OPC structure.
How can the C/C++ structure ‘OpcUa_ExtensionObject_Body’ being transmitted across the network be maliciously manipulated to cause a system crash on the Softing OPC Server? The researchers propose two feasible methods. The first involves transmitting a variable with XML content through the Softing OPC suite, then intercepting the packet with tools like Wireshark, and substituting any data structure for the XML type marker in the structure. This forced conversion of XML content data into an OPC data structure would induce a conversion anomaly, causing the system to crash. The second method is similar to the first, except it transmits an OPC structure through the Softing OPC suite, intercepts the packet, and replaces the structure’s ID with an incorrect structure ID. This, too, would prompt an anomaly in the OPC structure conversion, often leading to a service crash. Both of these attack approaches have been logged under the CVE number CVE-2021-32994.
Beyond Certificate Validation: The Extent of Hacker Exploits and OPC-UA Protocol
We’re going to revisit the work of CISPA researcher Alessandro Erba presented at Black Hat Europe, “Resting on Feet of Clay: Securely Bootstrapping OPC UA Deployments“, and his paper published in the same year, “Security Analysis of Vendor Implementations of the OPC UA Protocol for Industrial Control Systems“. These studies, through practical analysis and reverse engineering, identified a critical issue: in industrial control systems, nearly 80% of leading brands failed to correctly implement the security certificate validation aspect of the OPC-UA standard. This exposed a significant security vulnerability.
However, “identifying that certificates were not properly validated by leading brand manufacturers” is only the tip of the iceberg. Alessandro Erba and his team spent two months transforming this certificate issue into a practical attack model that could be exploited by hackers. Their experiments demonstrated the extent to which hackers could use this particular vulnerability to cause substantial harm to industrial control systems.
The Perfect Attack Model Hypothesis
The aforementioned security analysis mentions that, in the worst-case scenario, if these practical OPC trust lists and certificate validations are not properly implemented, attackers could execute what is known as a PITM (Plant-in-the-Middle) attack aka a MITM (Man-in-the-Middle) attack. This method of exploit inserts a third party in the communication between two legitimate entities, and that third party can intercept and also tamper with the data being communicated with neither party being none the wiser. This attack could blind maintenance personnel to the real situation inside the plant and pose physical security threats to the plant, as shown below.
Figure 20: PITM (Plant-in-the-Middle) Attack Model
OPC-UA serves as a specification for data exchange and communication between an Engineer Workstation and Endpoints. For attackers aiming to target all devices using OPC-UA protocol in a facility, the ideal scenario would be to execute a PITM attack. This enables hackers to monitor all OPC data transmissions within the plant, and also manipulate that transmitted data in a way that convinces the recipient of the attacker’s altered data integrity. This insidious attack method means that it will take longer for the organization to detect that anything is amiss, giving it more time to carry out its destructive objectives.
To achieve this perfect state of attack, the attacker must infiltrate the plant and create an OPC Client to connect to the real OPC Server, thereby collecting real-time information on Endpoints. They then set up their controlled OPC-UA Server on the Engineer Workstation to provide felonious ‘real-time plant information collected’ to the legitimate OPC Client. This strategic setup enables the attacker to manipulate the information sent to the Workstation’s legitimate OPC Client when necessary, causing actual damage to the plant. Consequently, the described perfect MITM attack model actually consists of two-pronged assault, comprised of a Rogue Server attack and a Rogue Client attack.
Rogue Server Workflow
Firstly, let’s discuss the Rogue Server attack strategy: the attacker can set up an OPC Server within the plant network and wait for any legitimate OPC Client within the plant to send requests to the compromised OPC Server. As previously mentioned, when any OPC Client connects to an OPC Server, the first step is to obtain a list of managed Endpoints from the Server using getEndpoints. The attacker’s OPC Server will also attach a self-signed certificate controlled by the attacker when replying to the Endpoint list.
According to the OPC standard, the client should refuse further connection since the attacker’s self-signed certificate is not in the Trust List. However, if the OPC Client uses a product implementation with vulnerabilities, it may mistakenly trust the attacker’s certificate, leading to the conclusion that the server is also trustworthy. The Client then attempts to control the malicious Server’s Endpoints by initiating a request to OpenSecureChannel to the OPC Server controlled by the attacker.
Figure 21: Rogue Server Attack Model
The most severe issue in this process is Credentials leakage: since the OPC Client has trusted the malicious Server, it actively provides user identity tokens and other information during stages like ActivateSession requests to the malicious Server. This allows the attacker to possess the essential Credentials needed to connect to the real industrial OPC Server Endpoints. The Client subsequently also trusts all Endpoint information provided in responses from the malicious Server without question, leaving it completely at the mercy of the attacker.
In Erba’s publication, researchers evaluated this attack model by testing it out on leading brand OPC Clients already in the market. They found that in the default state, all brand OPC Clients used a connection security mode of Security Node None (No Security), and three library designs (ASNeG, Free OpcUa, and opcua ts) didn’t even offer an encryption option.
Furthermore, these brands’ twelve different libraries were also tested for their support of Trust List certificate management. Libraries like LibUA, node-opcua, OpenScada UA, and python-opcua were found to completely lack Trust List functionality. Meanwhile, four other libraries (Opcua Rust, UA.Net, open62541, and opc-ua-client) do support Trust List functionality but are disabled by default, though engineers can manually enable them. But is that safe? Not necessarily, because even when enabled, these four libraries automatically trust any certificate sent by the attacker. Engineers aware of these OPC-UA attack techniques can manually disable this auto-trust setting that allows attacks to occur.
One library with a GUI interface, UAexpert, responds with BadCertificateUntrusted when the client receives a fraudulent self-signed certificate from the attacker, indicating the certificate cannot be trusted. This is good as it verifies the certificate’s validity. However, the story doesn’t end there. The malicious OPC server persists and prompts the client again to trust the compromised certificate and re-establish the connection to the malicious OPC Server, which the client does, ultimately rendering the certificate validation design ineffective.
Rogue Client Workflow
Next, let’s discuss the Rogue Client attack strategy, which, like the aforementioned Rogue Server approach, revolves around the core issue of targets not properly validating certificates. Once the attacker infiltrates the plant network, they can attempt to establish a malicious OPC Client to connect to the legitimate plant OPC Server.
As we know, the first step for a malicious OPC Client is also to request the legitimate OPC Server using getEndpoints to obtain a list of all Endpoints managed by this Server in the real plant. Then, after acquiring the Endpoint list, the malicious OPC Client can select any Endpoint to connect to by using OpenSecureChannel, attaching a malicious self-signed certificate by the attacker, and waiting for the legitimate OPC Server verify its authenticity.
Figure 22: Rogue Client Attack Model
In such attack scenarios, since the malicious self-signed certificate sent by the attacker shouldn’t be listed in the legitimate OPC Server’s Trust List, the OPC Server should, under normal OPC standards, refuse all subsequent connection requests from this malicious OPC Client. However, in practice, well-known brand OPC Servers have been found to allow such malicious OPC Clients to connect and manipulate legitimate Server Endpoints. This implies that their certificate management logic has vulnerabilities that allow attackers to undertake various actions to physically incapacitate the plant, such as maliciously altering threshold values of factory equipment or executing malicious commands, leading to physical damage.
Referencing Dragos’ chief malware analyst Jimmy Wylie at DEFCON 30, he pointed out the dangers of OPC-UA attacks, citing the famous Dead-Heading attack method as an example. This attack took place in 2017 in Queensland, Australia, when attackers took control of an OPC Server and used it to ceaselessly inject mining slurry through pumps into pipelines until it led to the mining slurry pump to explode.
Regarding the Rogue Client attack method, the paper also conducted field investigations to confirm whether major brands are permeable to such attacks. A total of 22 products were analyzed, and the results are listed in the paper. Suppliers Yokogawa, Honeywell, and Beijer completely lack any OPC-UA protocol security features (which also means that they don’t offer secure communication channels to protect Client/Server messages).
Only 7 out of the 19 remaining manufacturers guide users on how to correctly configure Trust Lists for certificate validation, while the other twelve offer unsafe guidelines that leave the user open to attack. For instance, the default OPC Servers of two manufacturers, Siemens and Bachmann, trust all certificates unconditionally, even those strange certificates sent by attackers without any validation.
Some brands even exhibit improper certificate exchange behavior: if a malicious OPC Client is not authenticated by a legitimate OPC Server, then when the malicious OPC Client sends an OpenSecureChannel request to its server, the Client Certificate is automatically copied to the legitimate OPC Server’s trust list. This results in the problem of the malicious OPC Client still being automatically trusted. Paper [2] points out this glaring error in certificate management design, which is described as a common behavior in the official manuals of 10 different suppliers (ABB, Beckoff, Bosch Rexroth, Codesys, Eaton, General Electric, Hitachi, Lenze, Panasonic, & Wago); moreover, four Codesys products with OPC Servers have the same issue in their official documentation, potentially threatening over 400 global brands reliant on Codesys-manufactured products.
Middleperson Attack (PITM aka MITM)
If industrial control system manufacturers opt for products whose OPC-UA is in a high-risk state allowing attackers to simultaneously act as both Rogue Server and Rogue Client, then they become vulnerable to the most perfect form of attack on OPC-UA: the middleperson attack.
In a complete middleperson attack scenario, the attacker first creates a malicious OPC Server within the plant network to phish and wait for any unsuspecting legitimate OPC Client to connect. Then, any request and Credentials the Client sends to the malicious Server are forwarded in an unaltered state to the legitimate OPC Server in the industrial control domain. The malicious OPC Server merely acts as an intermediary, relaying messages and eavesdropping on Credentials, waiting for the right moment to launch an attack on the plant.
The research notes that in the final survey of many leading brand products, if their products are simultaneously under the threat of both Rogue Client and Rogue Server attacks, it could potentially allow any attacker to conduct a plant-wide middleperson attack on factories using these products.
They discovered that out of 44 brands surveyed, 19 products (43%) claiming to support security features were actually vulnerable to Rogue Client attacks (four completely lacked Trust List support, while the remaining fifteen had insecure Trust List designs by default). Similarly, 12 products (27%) claiming to support security features were actually under the threat of Rogue Server attacks (seven lacking Trust List design and five with insecure default Trust List designs). Therefore, as we can see, using insecure OPC-UA products is a significant cybersecurity threat that cannot be ignored.
Figure 23: Launching a Middleperson Attack using Rogue Client and Rogue Server Techniques
Conclusion
Recent research into the cybersecurity of OPC UA in industrial control systems has revealed shocking vulnerabilities, highlighting an urgent need to strengthen security measures. Many systems utilizing OPC UA are vulnerable, primarily due to flawed implementations of security features such as certificate validation and inadequate Trust List management, issues that persist even among products from leading brands. Numerous products lack essential security features, such as Trust Lists, or have unsafe default configurations. This indicates a significant underestimation of network security threats in industrial control systems, especially those associated with OPC UA.
The results of this research serve as a clear reminder of the critical need for constant vigilance, enhanced security measures, and regular system audits. These risks extend beyond data breaches, posing severe physical threats to industrial facilities and their workforce. Addressing these vulnerabilities is not just about safeguarding data but is crucial for protecting the physical integrity and operational continuity of industrial plants.
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
Alessandro Erba, Anne Müller, Nils Ole Tippenhauer, “Resting on Feet of Clay: Securely Bootstrapping OPC UA Deployments”, CISPA, Nov 10 2021, Accessed Feb 10 2023
Alessandro Erba, Anne Müller, Nils Ole Tippenhauer, “Security Analysis of Vendor Implementations of the OPC UA Protocol for Industrial Control Systems”, CISPA, Apr 2021, Accessed Feb 10 2023
Dragos, “Analyzing PIPEDREAM: Results from Runtime Testing”, Dragos, Oct 27 2022, Accessed Feb 10 2023
