The Open Platform Communications Unified Architecture (OPC UA) protocol is a prime candidate for secure future industrial communication. While the protocol’s security features are widely attested, it requires extensive configuration to achieve the promised security level.
Official security guidelines exist to guide operators through this configuration process. However, in a recent study, my colleagues and I from the Chair of Communication and Distributed Systems, RWTH Aachen University and the Department for Cyber Analysis & Defense, Fraunhofer FKIE, discovered that 92% of all OPC UA deployments reachable from the Internet neglect OPC UA’s security benefits, for example, by disabling access control or communication security.
OPC UA deployments in the wild
We monitored the complete IPv4 address space weekly over seven months using ZMap and our OPC UA extended version of ZGrab2, retrieving the security configuration of found OPC UA hosts and payload data whenever publicly available. Figure 1 shows the number of publicly reachable OPC UA hosts over time.
We found between 1,761 and 2,069 hosts, whereby ~42% are Discovery Servers used to announce OPC UA instances on other IP/port combinations only. For our analysis, we focused on the 1,114 non-Discovery Servers of the latest measurement (2020-08-30), as Discovery Servers do not directly make data available and the security configuration is only relevant for payload transmission.
Communication security: disabled, deprecated, or implemented incorrectly
To set up OPC UA deployments securely, operators must first configure servers offering a ‘Security Mode’ enabling confidential and/or authentic communication. However, one out of three available modes disables communication security. Nearly one in four (24%) of all deployments offer only this Security Mode prohibiting clients from connecting securely and opening the door for attackers to intercept or modify communicated data.
Secondly, operators have to select ‘Security Policies’ defining security primitives to implement the desired security features. One out of six policies completely disables communication security, and the other two policies have been deprecated since 2017 due to security primitives that lost their promises, that is, the usage of SHA-1.
While the Security Policy disabling communication security exclusively is used with the Security Mode disabling communication security, 25% of the found servers only announce deprecated policies. Beyond these, 70% of the servers enabling communication security do not implement announced security policies correctly and realize a weaker security level than specified, for example, by using certificates for authentication that do not meet the announced policy’s minimum requirements.
Regarding the used server certificates, among others, we detected one certificate deployed on more than 380 hosts. While common practice in the web, where the same certificate is placed on several web servers, for example, in a Content Delivery Network, such a practice is more than questionable on industrial deployments, which are typically not installed securely in a data centre but on the field.
From the discussion with the manufacturer of the affected devices, who claimed that distributors and/or operators do not read the product manual, which indeed states the danger in certificate reuse, we derived that different operators deployed these hosts. Other entities in possession of the certificate’s private key material narrow the security, clearing the way for impersonation attacks.
After our discussion, the manufacturer sent security notices to its customers, pointing out this risk again, but during subsequent measurements we still detected a rising number of hosts using the said certificate.
Open door for everybody
A third perspective of the OPC UA security concept intends servers to force clients to authenticate, that is, to restrict access to available data and functions. Here, we found that 44% of the Internet-facing OPC UA deployments do not restrict access to otherwise internal information and enable everybody on the Internet to connect, read and write data, as well as execute system functions.
Without altering the state of these systems, we requested the publicly available data and classified many of these systems as actual production systems. These production systems encompass, on one hand, systems leaking privacy-sensitive information (like parking lot systems storing license plate data and video surveillance data), and on the other hand, systems which are part of critical infrastructure (like water sewage systems).
Information campaign: limited response
As ethical considerations for Internet measurements require, we wanted to inform the responsible operators of these systems and set out to identify them by manually inspecting the available data. This identification was possible for 50 systems where we reached out to the operators via email. However, we got very little response, receiving only two replies; one promising to forward our information to the responsible IT department, and one asking for security advice.
Four months after our initial contact attempts, both systems and all but three of the other systems were still online — only the device of which the operator asked for security advice now implements access control.
Constant revision of security configuration and secure-by-default protocols required
Our results underline that secure-by-design protocols are no guarantee for secure deployments. Operators still have to configure their deployments correctly and constantly need to revisit the security configuration according to regularly updated security recommendations.
With OPC UA as a key example, our analysis shows that providing such security recommendations does not automatically lead to secure deployments. Thus, we think that a shift from secure-by-design to secure-by-default protocols, where implementations hinder operators from using insecure configurations, would be a good starting point for more secure deployments. The corresponding protocol specifications could incentivize these secure-by-default implementations.
Learn more about our study in our Internet Measurement Conference 2020 paper.
Markus Dahlmanns is a PhD student at the Chair for Communication and Distributed Systems at RWTH Aachen University in Germany.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.