Beyond Certificate Validation: The Extent of Hacker Exploits
In our previous article, we introduced 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 in Figure 1.
Figure 1: PITM (Plant-in-the-Middle) Attack Model
Continuing from our previous discussion, 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 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 2: 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 3: 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 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 4: 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
- 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
