In Part 3 of the OPC UA Deep Dive series, we described the inner workings of the OPC-UA protocol, we discussed its structure and various security aspects. Today, we will discuss the risk of changing values via OPC UA and the threat associated with exploiting OPC-UA components like servers or gateways. We will also delve into the supply chain of OPC-UA components including core libraries, protocols stacks, SDKs and products that are built on top of it.
OPC-UA is one of the most dominant protocols in any ICS/SCADA network environment, as we mentioned multiple times throughout the OPC UA Deep Dive series. This makes it a potential target for attackers lurking on ICS networks wanting to cause physical damage or disruption. For example, the Industroyer malware—also known as CrashOverride—is believed to have been used in attacks against the Ukrainian power grid. Industroyer can interact with a number of industrial control systems found in power grids, including payloads targeting OPC DA devices. I won’t be too long before we will see cyber attacks against OPC UA servers.
Successful exploits against OPC is the ability to modify process values to manipulate a physical operation. For example, changing an OPC item from “true” to “false” could result in shutting down an entire plant! As with Industroyer targeting ABB’s MicroSCADA with OPC DA item manipulation, any attack against an OPC server could lead to injury or loss of life from the manipulation of a physical process potentially causing physical damage be it to an electrical grid or nuclear plant.
Furthermore, not only is unauthorized access risky, but actual exploit chains are dangerous too and could result in denial-of-service attacks, authentication bypasses, information leaks, and even remote code execution. Therefore, the OPC-UA protocol, clients, servers, tunnellers, and gateways must be protected with the highest level of security.
The severity of risks, and potential negative outcomes vary for each outcome of an attack against OPC UA:
OPC UA servers and clients can be vulnerable to DoS attacks, where attackers exploit a specific bug in the protocol stack, or flood the system with a large number of requests, causing it to crash or become unavailable. We demonstrated multiple DoS exploits at Pwn2Own 2022 and 2023, for example in Prosys Java OPC-UA protocol stack.
One of the biggest security risks in OPC UA is unauthorized access. If an attacker gains unauthorized access to the OPC UA server or client, they could potentially steal or manipulate sensitive data, or even disrupt an entire system. At Pwn2Own 2022, Computest demonstrated how it exploited a bug in the OPC-UA .NET protocol stack and bypassed authentication to access and modify process values regulating boiler temperature.
An information leak vulnerability can allow attackers to access sensitive information such as device configurations, user credentials, and production data, which can be used for malicious purposes. In 2020, we demonstrated such attacks against Honeywell Matrikon OPC UA Tunneller with out of bound (OOB) memory read CVE-2020-27299.
Finally, the biggest threat of all is a pre-authenticated remote code execution on both a OPC-UA server and client. By achieving RCE, an attacker could compromise the system and control the environment, including changing process values and performing lateral movement. At Pwn2Own 2022 and 2023 we’ve demonstrated multiple RCEs against many vendors, including an exploit of PTC Kepware KEPServerEx OPC-UA Server.
Once we understand the risk, let’s discuss what uses OPC UA and what types of implementations exist. The products we interact with most are OPC UA servers and clients, and also tunnelers that convert packets between different OPC protocols.
From a high-level perspective these products contain a dedicated OPC UA protocol stack that was developed by the vendor based on OPC UA specifications. However, the reality is a bit more complex. At the bottom of the product tech stack pyramid we have the base code or core library, that in most cases was developed by OPC Foundation.
In the beginning, OPC Foundation released some basic core libraries such as the OPC UA Ansi C library so other vendors could easily integrate it in their products and add support for OPC UA. But with time, vendors privately extended the core library with their functionality and features. Then, some even exposed some functionality with an API and made a SDK for easy and correct programming.
Finally, on top of the protocol stack and SDK, the actual products were developed and some are even being used as OEM by other vendors. For example, PTC Kepware KEPServerEX is used by Rockwell Automation’s KEPServer Enterprise, GE Digital Industrial Gateway Server, Software Toolbox Top Server, and more. We know this because when we reported vulnerabilities in KepwareEX all of these products were affected too, as were listed in a CISA advisory.
The OPC Foundation lists on its website all products that use OPC UA; currently there are 529 different products that use or support OPC UA.
The lower the level of the pyramid where a vulnerability is found, the more likely it will affect many different products that rely on the same code base. That’s why in our research we focused on the protocol stacks and core libraries themselves instead of high-level products.
In their paper, "Practical Pitfalls for Security in OPC UA," Alessandro Erba, Anne Muller and Nils Ole Tippenhauer listed many ICS platforms that have OPC UA functionality, mostly as a OPC UA server. The products are in most cases engineering workstations (EWS) or PLCs. For example, their list included the following EWS:
VENDOR | PLATFORM | |
B&R | ||
Bachmann | ||
Beckoff | ||
Beijer | ||
Bosch Rexroth | ||
General Electric | ||
Honeywell | ||
Lenze | ||
Mitsubishi | ||
National Instruments | ||
Omron | ||
Panasonic | ||
Rockwell Automation | ||
Schneider Electric | ||
Siemens | ||
Weidmuller | ||
Yokogawa | ||
Codesys | ||
ABB | ||
Eaton | ||
Hitachi | ||
Wago |
Another interesting aspect are the dedicated OPC UA servers and gateways. For example:
VENDOR | PRODUCT | |
Softing | ||
Kepware | ||
Triangle Microworks | ||
Honeywell | ||
Inductive Automation |
The fact that almost all ICS vendors incorporated OPC UA technology into their engineering working stations or PLC firmware tells us a lot about the popularity and usage of this protocol. But what are the OPC UA protocol stacks that are used? And which are the most used ones?
Based on multiple sources, we gathered the following list of OPC UA protocol stacks:
OPC UA PROTOCOL STACK | PROGRAMMING LANGUAGE | OPEN SOURCE? |
NodeJS | Yes | |
C | Yes | |
C++ | Yes | |
Python | Yes | |
Python | Yes | |
Java | Yes | |
C++ | Yes | |
Rust | Yes | |
C++ | No | |
C# | Yes | |
C++ | No | |
Java | No | |
Java | Yes | |
C | Yes | |
C# | Yes |
After extensive research, and based on research of all of the above products (EWS, PLCs, servers, gateways), we decided to mainly focus on these OPC UA protocol stack and/or SDKs (and yes, we got a “bit” of incentive from ZDI Pwn2Own):
Finding a vulnerability in one of these SDKs could immediately affect hundreds of products and millions of devices and instances. In future installments of the OPC UA Deep Dive series, we will provide some details about vulnerabilities we have uncovered, their impact, how we found them, and more.
In this blog we discussed the hidden risks of OPC UA and examined the different components of OPC UA-based products. We learned that OPC UA protocol stacks are the weakest link in the global supply chain because they are used by many products with little to no modification.
In the next part, we will discuss our research methodology and the result of our research. After that, we will start sharing our lessons learned from exploiting various OPC UA stack protocols and products including demonstrating the pitfalls, vulnerabilities, and exploits.
A Complete Guide to the OPC UA Attack Surface
