Team82’s OPC UA Deep Dive Series was always meant to be a compilation of our research into this most important of operational technology protocols. OPC UA standardizes data and communication between dozens of proprietary industrial control systems and devices that otherwise could not share information. Modern automation runs on OPC UA.
Therefore, it made sense to deeply examine the security of the protocol, starting with its origins and ultimately arriving at its security features and attack surface. The installments of this comprehensive guide that we’ve published since last April dissects these concepts and also includes practical and theoretical attacks against OPC UA, tools you can use to test the security of your implementations, and a community of vendors and practitioners who have collaborated with us to improve the safety and reliability of products built on top of the protocol.
In this final entry of the series, we will 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.
First, some outcomes:
Pwn2Own ICS: We participated and demonstrated our OPC UA exploits at three Pwn2Own competitions: Pwn2Own ICS 2020, 2022, 2023
CVEs: We found and reported on ~50 OPC-UA vulnerabilities/CVE across ~15 protocol stacks, which affect hundreds of OPC UA products.
Exploit Techniques: We developed ~12 unique exploit techniques that are universal and affected multiple vendors and pushed to change the specs.
Open-Source Tools: We have released open-source tools: our OPC UA network fuzzer and the OPC UA exploit framework.
OPC UA Specifications: We helped to improve the specifications and pushed the vendors toward better and more secure products.
OPC UA Slack: We’ve collaborated with major OPC-UA vendors and created a safe place, via a dedicated Slack workspace) to discuss security issues, architecture, and possible improvements for OPC-UA protocol stack implementations.
Public Talks: We’ve presented this research at major security conferences including DEFCON and Black Hat
Now, a do’s and don’ts checklist of best practices you can use to assess the safety of your deployments.
Regularly updating software is crucial for maintaining security because updates often include patches for known vulnerabilities. Software updates should not only cover the OPC UA server but also any underlying operating systems, libraries, and dependencies. Implementing a robust update process ensures that security patches are applied promptly to mitigate potential threats.
Enabling auditing allows for the tracking and monitoring of access and activities on the OPC UA server. Auditing helps in identifying security incidents, detecting anomalies, and providing accountability for actions performed within the system. By enabling auditing, organizations can enhance security posture and comply with regulatory requirements related to data protection and access control.
Role-based access control (RBAC) is essential for managing and controlling user access to OPC UA resources based on their roles and permissions.
Organizations should define roles and associated permissions tailored to their specific security requirements and operational needs.
RBAC helps in enforcing the principle of least privilege, ensuring that users only have access to the resources necessary for their tasks, thereby reducing the risk of unauthorized access and potential misuse of privileges.
Exposing OPC UA servers directly to the internet increases the risk of unauthorized access and potential cyberattacks. It's recommended to deploy OPC UA servers within a secure network environment, preferably behind firewalls and other network security measures.
If remote access is required, consider using secure VPNs or implementing other secure access methods rather than exposing the servers directly to the internet.
Allowing anonymous authentication poses significant security risks because it allows anyone to access the OPC UA server without providing credentials. Enforcing authentication ensures that only authorized users or devices can access the server, thereby preventing unauthorized access and potential data breaches.
Sharing or using common credentials across multiple users or systems increases the risk of credential theft and unauthorized access. Each user should have unique credentials, such as usernames and passwords, to access the OPC UA server. Implementing strong password policies and multi-factor authentication can further enhance security by adding layers of verification.
OPC UA supports different security modes, including None, Sign, SignAndEncrypt.
Choosing None or an invalid security mode leaves communication unprotected, making it vulnerable to eavesdropping, tampering, and other security threats. It's essential to select an appropriate security mode based on the security requirements of the system and the sensitivity of the data being transmitted.
OPC UA defines various security policies, such as Basic256, Basic256Sha256, etc., which specify encryption and signature algorithms. Selecting the None security policy means no encryption or signature is applied to the communication, leaving it vulnerable to attacks.
Organizations should choose security policies that provide adequate protection based on their security requirements and compliance standards.
Using self-signed certificates for authentication and encryption. Doing so may introduce security risks, because they are not issued by a trusted Certificate Authority (CA). Self-signed certificates can be susceptible to spoofing attacks and may not provide the same level of trust and validation as certificates issued by trusted CAs. Whenever possible, organizations should run their own CAs because they need to control their trusted network of applications. OPCA UA certificates are generally not designed to be verified primarily by a global CA, for example.
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