Penetrating the Core Security Defenses of OPC-UA
In our previous article, 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, 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 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 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.), which this article will focus on, as illustrated in Figure 1.
Figure 1: Communication Process Between OPC-UA Client and Server
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 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 2: 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 supports a design called the Global Discovery Server (GDS). 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 3: Practical Security Implementation, Concerns, and Vulnerability Ratios of Devices in the Market Claiming OPC Support
Referencing Figure 3, 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 4: OPC-UA Trust List Mechanism
Figure 5: 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’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
