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-257: Storing Passwords in a Recoverable Format
RND encrypts passwords with a hardcoded weak secret key and returns the passwords in plaintext. If the server were compromised, an attacker could gain all the plaintext passwords and decrypt them.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 5.3
CWE-321: Use of Hard-coded Cryptographic Key
A built-in user called sshuser, with root privileges, exists on the RND platform. Both public and private ssh keys exist in the sshuser home directory. Anyone with the private key can access an RND server as sshuser.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 10.0
CWE-259: Use of Hard-coded Password
RND includes a jailed environment to allow users to configure devices without complete shell access to the underlying operating system. The jailed environment includes a built-in jailbreak for technicians to elevate privileges. The jailbreak requires a weak password that is hardcoded into the environment. Anyone with this password can access an RND server with root permissions.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 8.2
CWE-321: Use of Hard-coded Cryptographic Key
RND uses a secret key on the backend web server to ensure that session JWTs are valid. This secret key is hardcoded into the web server. Anyone with knowledge of the secret key could create a valid JWT, thus bypassing the typical authentication to access the server with administrator privileges.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 9.8
CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
An authenticated vSZ user supplies an IP address as an argument to be run in an OS command, but this IP address is not sanitized. A user could supply other commands instead of an IP address to achieve RCE.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 9.0
