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-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.
Update to Access Commander version 3.2.
CVSS v3: 4.7
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, an Insufficient Verification of Data Authenticity vulnerability could allow an attacker to escalate their privileges and gain root access to the system.
Update to Access Commander version 3.2.
CVSS v3: 6.3
CWE-22 IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL'):
In 2N Access Commander versions 3.1.1.2 and prior, a Path Traversal vulnerability could allow an attacker to write files on the filesystem to achieve arbitrary remote code execution.
Update to Access Commander version 3.2.
CVSS v3: 7.2
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1
