This is Part 3 of Team82’s OPC UA Deep Dive series, a comprehensive guide to the security of the OPC UA network protocol for unified OT communication. In previous entries, we covered the history of the protocol, its data model, and an example of a simple automation process. In Part 3, we will focus on how the standard is translated into a protocol.
OPC UA is an asynchronous protocol that is built using several layers of communication and information exchange.
Application Layer: The application layer defines the types of data and services that can be exchanged between OPC UA clients and servers. This layer includes the OPC UA object model, which defines the structure and behavior of the data that can be exchanged.
Session Layer: The session layer manages the communication between OPC UA clients and servers. It handles the establishment, maintenance, and termination of communication sessions.
Transport Layer: The transport layer provides a means for data to be transferred between OPC UA clients and servers. It includes several protocols for data transport, including TCP/IP and HTTPS.
Overall, the OPC UA protocol is designed to be secure, scalable, and platform-independent, making it ideal for industrial automation and control systems. Its flexible architecture allows it to be used in a wide range of applications, from small-scale embedded systems to large-scale enterprise environments.
While the OPC-UA protocol can be used over different transport layers, such as TCP/IP, HTTP, or MQTT, the most common use is over TCP/IP. There is no single predefined port, but instead each application chooses its unique port. For example, these ports are used by different applications: 4840, 4841, 4885 (Triangle Microworks), 49320 (Kepware), 48010 and 48020 (Cpp Stack), 48031 (GE), 4897 (Softing), 53520 and 53530 (Prosys), 62541 (.NET Stack) .
Every OPC UA message starts with a three-byte ASCII code that constructs the message type. The four main message types are:
HEL
: Hello message
OPN
: OpenSecureChannel message
MSG
: A generic message container (secured with the channel’s keys)
CLO
: CloseSecureChannel message
The first message sent is the HEL
message. The HEL
message contains basic parameters to initialize the connection, such as the URL that the client wishes to connect to, and the maximum message size the client expects to receive. The HEL
message is typically followed by the OPN
request.
OPN
opens a secure channel over the connection, and if all goes well, the server responds with a SecureChannelID
. Now the client and server can exchange MSG
type messages over the opened channel. A single client is able to open multiple channels which are identified by their unique SecureChannelID
.
Next, the client and server can communicate over the channels. For example, a common MSG
being used is Browse
, which the client uses in order to retrieve the node tree from the server. Finally, the session ends with the CLO
message which terminates the session.
Here is a typical example of OPC UA packets sequence flow to monitor item values:
Practically, clients will connect to an OPC UA server using an Endpoint URL. An OPC UA Endpoint URL is a formatted text string that consists of four parts:
Scheme: Must be opc.tcp or opc.https
Server Address
Port
Discovery endpoint
For example:
opc.tcp://SERVER_IP:62541/UA/Server
Let’s take a look at a single MSG
message type. It is constructed of a basic header and body.
The MSG
header contains basic information about the message, such as its type (MSG
), its length and information about its SecureChannel
. Other important information passed inside the MSG
header is the IsFinal
flag, which indicates whether the message is complete (F-Final
) or just a single chunk (C-Chunk
) that is part of a series of other chunks being sent forming the whole message. This helps the parties to reassemble big OPC UA messages.
OPC UA defines a list of services (like Browse, ReadRequest, WriteRequest
etc.), each with its unique structure. This defines the request structure, specifying how a request to this service should be built, using OPC’s built-in types. The MSG
body is constructed from a request, specifying which service the client wishes to access (for example, ReadRequest
is ns=0, i=631). Following that is the rest of the structure that is defined for the specific service.
The OPC UA transport layer is responsible for the physical transmission of data between OPC UA clients and servers over different communication protocols. The transport layer operates on top of the network layer and is responsible for establishing, maintaining, and terminating connections between the clients and servers.
The OPC UA specification defines several transport protocols that can be used to transmit data between clients and servers. These protocols include TCP, HTTPS, and others.
OPC servers can expose multiple endpoints with different transport layers. For example, a server can have both TCP and HTTPS endpoints for the same server.
It is worth noting that the transport protocol does not directly affect the structure of the underlying OPC data that is sent. An OPC UA server that exposes an HTTPS endpoint can choose to send regular OPC UA binary, XML, or JSON formatted messages over the secured connection.
Exposed endpoints are identified by the URI scheme. TCP endpoint starts with opc.tcp://<hostname>:<port>
while HTTPS endpoints start with opc.https://<hostname>:<port>
or http://<hostname>:<port>
During session initialization, a SecureChannel is created on top of the opened connection using the OpenSecureChannel requests. During this request, the client and server agree on a shared SecurityMode, which will indicate what security mechanisms will be used in this channel. The SecurityMode can be either None, Sign or SignAndEncrypt.
Depending on the selected SecurityMode, both the server and client will present their own certificates, and after both parties accept each other’s certificates and identities, the channel will be opened. For each OPC-UA server, a list of trusted certificates exists, dictating which client it trusts and which connection it accepts. In the past, vulnerabilities were discovered that enabled rouge clients to bypass this certificate trust check, which could allow unauthorized clients to access servers they are not authorized to access.
During the SecureChannel
initialization, if encryption is enabled in the chosen SecurityMode
, the client and server will exchange symmetric keys that will be used in the encryption process for subsequent messages. In order to distribute the symmetric keys securely, an asymmetric key exchange will be performed, using the server and client’s certificates and public keys.
SecureChannel supports different encryption algorithms for the key exchange and symmetric encryption, key length and even different hashing algorithms for the signing of messages.
After deciding on a shared SecurityPolicy
and depending on the server settings, the server may demand that the client will authenticate using a username-password pair or certificate. If anonymous login is enabled in the server’s configuration, the server will not authenticate the user. This is particularly not recommended and generally should be avoided.
The application layer defines the types of data and services that can be exchanged between OPC UA clients and servers. This layer includes the OPC UA object model, which defines the structure and behavior of the data that can be exchanged.
On top of the open channels, clients and servers can exchange service requests and responses. For example, a client can issue a Read service request to read one or more attributes of one or more Nodes from the server. There are many services available and they are listed in the specification Part 4.
For example, here is a screenshot from Wireshark showing OPC UA ReadRequest. We can see that the client requested to read 20 nodes from the server. The response will be similar with an array of 20 items each containing the content of the respected node.
OPC UA’s acceptance as the standard OT communication protocol comes from the fact it is structured and well defined, making implementation straightforward. The standard defines a three-layer architecture: application, session, and transport, each responsible for various aspects of the protocol from security to business logic.
We covered not only its 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.
In future installments of this series, we will cover OPC UA’s key components including core libraries, protocols stacks, SDKs, and products that are built on top of it. We will also share some new vulnerabilities discovered in the protocol, and make available an exploit framework used in our research.
A Complete Guide to the OPC UA Attack Surface
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