OPC UA is the standard unified communication protocol in industrial environments
Proprietary field devices and ICS/SCADA systems that previously could not exchange data on the OT network now do so over OPC UA, which is now supported by dozens of vendors across industries
Team82 has compiled a comprehensive guide to OPC UA, examining its history, security features, and attack surface
Part 1, OPC UA Uncovered: History of the OPC UA Protocol is available today
In the coming weeks, we will publish additional installations of this guide, including disclosures of new vulnerabilities, details on some of the tools we use—including an OPC UA network fuzzer, and an exploitation framework
OPC UA (Open Protocol Communication Unified Architecture) is today the standard protocol for unified communications in industrial environments. As more vendors build new products that implement OPC UA—or retrofit older devices to support the protocol—it becomes one of the few mutually understood and adopted technologies in OT.
OPC UA solved critical interoperability issues between field devices and ICS/SCADA systems that previously could not exchange data. Developed by the OPC Foundation, OPC UA is the standard protocol over which engineers and operators can, from a single server, communicate with and manage physical processes on the OT network. The fact that OPC UA is platform independent allows devices from different vendors to seamlessly communicate.
To achieve this goal, a few components were introduced: the OPC server, OPC client, and the OPC gateway. The OPC server contains many protocol converters that are capable of communicating with devices, such as PLCs, using their proprietary protocols, including Modbus, EtherNet/IP, S7, and more. The OPC server will constantly query devices for specific predefined memory values that are known as tags or points, and store them in a special database. Later, an OPC client, such as an HMI, can communicate with the server using the generic OPC protocol to get the values of these tags/points.
Team82 has invested considerable time and resources to research the security of the OPC UA protocol. Since 2020, we’ve disclosed more than two dozen vulnerabilities in OPC UA products, or in the protocol stack itself. We’ve researched clients, servers, and other software that supports OPC UA, and our work has helped improve the security of the overall network protocol stack. In addition, we also made freely available a network fuzzer used to find a number of zero-day vulnerabilities in OPC UA products in preparation for the Pwn2Own Miami competition in 2022 and 2023.
Today, we’re publishing the first in a multipart series of blogs that we hope will be the ultimate resource for OT engineers, asset operators, and asset owners intimately involved in OT network security, and specifically, OPC UA.
Throughout the series we plan to share our research into the OPC UA attack surface, and provide extensive background on the following:
The inner workings of the protocol
Recap OPC UA history
Explain OPC UA’s security features
Cover the OPC-UA attack surface
Disclose some information about new vulnerabilities
Describe new attack techniques targeting OPC UA
Introduce a new OPC UA exploit framework and fuzzers.
Our goal is to publish and maintain a useful OPC UA security guide, one that can be referenced often in order to minimize the risk to OT networks, and reduce the potential for damaging remote code execution or denial-of-service attacks.
In part one of Team82’s series examining the OPC protocol, we look at its history and the different flavors of OPC that have been developed throughout the past two decades. This blog sets the table for the remainder of this series, which will examine the OPC attack surface, security features in the protocol, and attack vectors.
Part 1: History of the OPC UA protocol
Part two begins our exploration of the OPC UA protocol, how it's used, its data model, and encoding. This is an extensive technical dive under the hood of the protocol, which is the standardized, secure, and reliable communication channel for exchanging data between devices, machines, and control systems, irrespective of the manufacturer or platform.
Part 2: What is OPC UA?
In part three, we cover not only OPC UA's structure, but four messaging types: HEL, OPN, MSG, and CLO, and demonstrated how they come into play while communicating over OPC UA and creating new sessions. Finally, OPC UA’s security features are dissected. Its features enable users to be fully authenticated, authorized, and sign and/or encrypt traffic if they so choose.
Part 3: Exploring the OPC UA Protocol
In this part, we describe the risk of changing values via OPC UA and the threat associated with exploiting OPC-UA components like servers or gateways. We 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.
Part 4: Targeting Core OPC UA Components
In part five, we explain our research methodology, how we set up our research environment, utilized fuzzers, and dove into the specification to find bugs and vulnerabilities in common protocol implementations. We will also discuss our results including the vulnerabilities we found, and the open-source tools we developed to uncover those issues.
Part 5: Inside Team82's Research Methodology
The centerpiece tool of our research is an advanced OPC UA Exploit Framework we built and used to execute many unique attacks against OPC UA implementations. It’s been immensely useful in finding close to 50 vulnerabilities in products using the protocol from OPC-UA client to servers to protocol gateways. In part six, we make it publicly available on our GitHub repository, and invite fellow researchers and vendors to use this framework to test their code bases and the security of your respective products.
Part 6: A One-of-a-Kind OPC UA Exploit Framework
Denial of service (DoS) attacks on industrial networks utilizing OPC UA are particularly perilous due to their potential to disrupt critical operations. OPC UA-based systems play a vital role in industrial automation, and a DoS attack can overload network resources or flood communication channels, rendering the system unavailable. In part seven, we explore three attack concepts that could disrupt automation services over OPC UA.
Part 7: Practical Denial-of-Service Attacks
We showcase our approach to researching and exploiting OPC UA client applications, where we combined classic OPC UA and OT knowledge with run-of-the-mill web vulnerabilities to uncover zero days in both clients. During our Pwn2Own research journey, we managed to find similar vulnerable code patterns in both applications, exploiting the OPC UA client’s trust in the data it receives from the OPC UA server.
Part 8: Gaining Client-Side Remote Code Execution
We uncovered four new vulnerabilities during our research of the Softing Secure Integration Server, which we were able to chain along with a fifth vulnerability found by the Zero Day Initiative in order to achieve full remote code execution on the server. The vulnerabilities range from bypasses of security features and programming limitations meant to restrict access to the server, to others that allowed us to read and write arbitrary files on the server.
Part 9: Chaining Vulnerabilities to Exploit Softing OPC UA Integration Servers
In this final entry of the series, we briefly recap the results of our research and also share helpful tips for asset owners. We are confident that OPC UA implementations are much more secure and robust. Most of our research was focused on helping OPC UA developers and vendors improve their protocol stack implementations, but we would like to share some tips for asset owners as well.
CWE-1390 WEAK AUTHENTICATION:
The web server for ONS-S8 - Spectra Aggregation Switch includes an incomplete authentication process, which can lead to an attacker authenticating without a password.
Optigo Networks recommends users always use a unique management VLAN for the port on the ONS-S8 that is used to connect to OneView.
Optigo Networks also recommends users implement at least one of the following additional mitigations:
Use a dedicated NIC on the BMS computer and exclusively this computer for connecting to OneView to manage your OT network configuration.
Set up a router firewall with a white list for the devices permitted to access OneView.
Connect to OneView via secure VPN.
CVSS v3: 9.1
CWE-98: IMPROPER CONTROL OF FILENAME FOR INCLUDE/REQUIRE STATEMENT IN PHP PROGRAM ('PHP REMOTE FILE INCLUSION')
The web service for ONS-S8 - Spectra Aggregation Switch includes functions which do not properly validate user input, allowing an attacker to traverse directories, bypass authentication, and execute remote code. ONS-S8 - Spectra Aggregation Switch: 1.3.7 and prior are affected.
Optigo Networks recommends users always use a unique management VLAN for the port on the ONS-S8 that is used to connect to OneView.
Optigo Networks also recommends users implement at least one of the following additional mitigations:
Use a dedicated NIC on the BMS computer and exclusively this computer for connecting to OneView to manage your OT network configuration.
Set up a router firewall with a white list for the devices permitted to access OneView.
Connect to OneView via secure VPN.
CVSS v3: 9.8
CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition:
This vulnerability occurs when an attacker exploits a race condition between the time a file is checked and the time it is used (TOCTOU). By exploiting this race condition, an attacker can write arbitrary files to the system. This could allow the attacker to execute malicious code and potentially cause file losses.
CVSS v3: 5.3
CWE-24: Path Traversal:
The vulnerability allows an attacker to craft MQTT messages that include relative path traversal sequences, enabling them to read arbitrary files on the system. This could lead to the disclosure of sensitive information, such as configuration files and JWT signing secrets.
CVSS v3: 6.5
CWE-313: CLEARTEXT STORAGE IN A FILE OR ON DISK
The configuration file stores credentials in cleartext. An attacker with local access rights can read or modify the configuration file, potentially resulting in the service being abused because of sensitive information exposure.
Moxa recommends the following to address the vulnerabilities:
CVSS v3: 5.5