Practical Pitfalls for Security in OPC UA

Alessandro Erba∗†, Anne Muller¨ ∗†, Nils Ole Tippenhauer∗ ∗CISPA Helmholtz Center for Information Security, †Saarbrucken¨ Graduate School of Computer Science, Saarland University [alessandro.erba, anne.mueller, tippenhauer]@cispa.de

Abstract—In 2006, the OPC Foundation released the first (i.e. client impersonation), and iii) Middleperson attacks. For specification for OPC Unified Architecture protocol, one of example, an attacker can feed wrong information to clients the industrial protocols that promises security features such (Rogue Server attack), eavesdrop, and change values which as authentication, authorization, integrity, and confidentiality. Challenges in the practical adoption of those security features can directly alter the physical process (Rogue Client attack), by product vendors, libraries implementing the standard, and or both (Middleperson attack). In 2017, the German Federal end-users were not investigated so far. Office for Information Security (BSI) released the ‘OPC UA In this work, we systematically investigate practical challenges Security Analysis’ [2], reporting that ‘No systematic errors to configure OPC UA securely. In particular, we review 48 could be detected’ in the OPC UA standard. In addition, the artifacts consisting of products and libraries for OPC UA and show that 38 out of the 48 artifacts have one (or more) security BSI recommended using only ‘Sign’ or ‘SignAndEncrypt’ as issue. In particular, we show that 7 OPC UA artifacts do security mode, with ‘Basic256Sha256’ as security policy, and not support the security features of the protocol at all. In configure a user authentication mechanism. addition, 31 artifacts that partially feature OPC UA security rely Nevertheless, there seem to be significant challenges to set on incomplete libraries and come with misleading instructions. up secure OPC UA deployments in practice. In [3], Dahlmanns Consequently, relying on those products and libraries will result in vulnerable implementations of OPC UA security features. We et al. perform a scan for OPC UA servers reachable over design, implement and demonstrate attacks in which the attacker the Internet and find that 92% of the reachable deployments can steal credentials exchanged between victims, eavesdrop on show issues with security configuration. Among those, 44% process information, manipulate the physical process through of the servers are accessible without any authentication re- sensor values and actuator commands, and prevent the detection quirements. To mitigate that issue, the authors suggest (similar of anomalies in the physical process. to [2]) to disable insecure security modes and policies and enforce user authentication. Their findings demonstrate that I.INTRODUCTION such suggestions are still not applied in a significant number Interconnection of industrial components carries security of deployments. The authors believe that this is due to the concerns that need to be addressed at different levels to configuration complexity of the OPC UA security features. allow secure industrial plants. One among the others is the In this work, we systematically investigate practical chal- security of the communication protocol adopted for Machine lenges to configure OPC UA in a secure way and prevent to Machine (M2M) communication. In 2006, the OPC Foun- the three attacks outlined above. In particular, we show that dation released the first specification for the OPC Unified many OPC UA products have missing support for security Architecture (OPC UA) protocol [1], an industrial protocol that features of the protocol. In addition, products that claim to promises security features such as authentication, authoriza- feature OPC UA security rely on libraries that are incomplete, tion, integrity, and confidentiality. OPC UA is a client/server difficult to use and provide instructions that lead to insecure architecture, e.g., in an ICS the OPC UA server is running on settings. Lastly, we also show that several popular OPC a Programmable Logic Controller (PLC) to publish industrial UA libraries provide vulnerable implementations of OPC UA arXiv:2104.06051v1 [cs.CR] 13 Apr 2021 process sensor readings and control its state. Those values can security features. be read and modified by an OPC UA client running on other To assess the vulnerability of available libraries, we cre- industrial devices or end-user systems. ate a framework that implements the three proposed attacks Although OPC UA provides features to ensure security (i.e. Rogue Server, Rogue Client, Middleperson). For each and confidentiality properties, they do not work out of the library, we set up a client and/or server application using box. OPC UA requires a correct configuration to guaran- protocol options that can be expected to provide a secured tee secure communication. For example, OPC UA specifies OPC UA instance, and then attack that system. For cases where a number of alternative securityModes (i.e., configurations the attacks succeed, we further investigate the cause for the for application authentication and encryption ranging from vulnerability. In particular, we show that Middleperson attacks ‘None’ to ‘SignAndEncrypt’), securityPolicies (i.e., algorithms are possible if vulnerable servers and clients are present in used for asymmetric encryption ranging from ‘None’ to the same network, and such attacks allow to manipulate the ‘Basic256Sha256’) and UserIdentityToken (i.e., configurations process and prevent reliable control of the system. Surpris- for user authentication). The main attacks to mitigate are i) ingly, we find that even recovery of plaintext credentials from Rogue Server (i.e. server impersonation), ii) Rogue Client intercepted encrypted communications is easily possible with our Rogue Server and Middleperson attacks. This finding is in contrast to prior work [4], where the authors perform a Middleperson attack on OPC UA applications and conclude that it is impossible to recover user passwords in OPC UA systems (even with security mode ‘None’). Contributions. We summarize our contributions as follows • We systematically analyze proprietary products and iden- tify reoccurring issues with the availability, and setup instructions for OPC UA security features • We systematically analyze available libraries and identify reoccurring issues with the implementation of security features • We demonstrate the feasibility of the identified attacks by implementing all three attacks with a proof-of-concept application (we plan to release a proof of concept of our framework as open-source) The remainder of this work is organized as follows. In II we (a) (b) present the details of the OPC UA protocol. In III we present Fig. 1. Figure (a) gives an overview over the connection establishment the system and attacker model, as well as the approach we use procedure between client and server. The server provides a list of endpoints, to conduct our research. In IV we explain how we build the where each endpoint consist of a Security Mode, a Security Policy and a User Identity Token. The client selects which endpoint it wants to connect to. If framework that we use to analyze the available libraries. In the mode Sign or SignAndEncrypt is chosen the server and client each have V we report the results of our research. A discussion of our to send their public certificate along with the endpoint to establish the secure findings is presented in VI, followed by conclusions in VIII. channel. Figure (b) shows the options available for the endpoint configuration. The Security Mode, Security Policy and User Identity Token can be chosen independently from each other. II.BACKGROUND In this section, we present the background related to the OPC UA protocol and its security features. OPC UA features None, Basic128Rsa15 (Deprecated), Basic256 (Deprecated), several options to change the level of security achieved for a Aes128-Sha256-RsaOaep, Basic256Sha256, Aes256-Sha256- connection. RsaPss. Finally, the UserIdentityToken defines the supported user authentication methods for an endpoint: Anonymous (no A. OPC Unified Architecture user authentication), Username&Password, Certificate [5]. OPC UA [1] is an industrial communication protocol devel- When initiating a connection, the client can choose the end- oped by the OPC foundation. The protocol allows platform- point to connect to (from an unauthenticated list of endpoints independent and secure communication by design. The first provided by the server). version of OPC UA Unified Architecture was released in 2006, followed by four other releases up to the current specification B. Certificate Management in OPC UA 1.04 released in 2018. Eighteen parts constitute the protocol In order to establish a secure connection (Security Mode specification, each describing a feature of the protocol. Part 2 different from ‘None’), OPC UA applications (Clients and describes the security model of OPC UA, and Part 4 describes Servers) need to perform application authentication by ex- the services that implement security primitives. changing their Application Instance Certificates. Upon re- The standard details two communication strategies: a client- ceiving a certificate, an application needs to decide whether server model and a publisher-subscriber model. Both models the received application certificate is trustworthy and the allow messages to be signed to ensure authenticity or signed connection can be established or not. To this end, each OPC and encrypted to add confidentiality. OPC UA does not enforce UA application has a list of certificates that are trusted (Cer- the use of security features, a mode with no security is also tificate Trustlist). This list can contain self-signed certificates possible. or certificates from Certificate Authorities (CA). In the first Figure 1 reports an example of a secure connection es- case, the certificates are often exchanged manually between tablishment in client-server communication. A server can applications, but the use of a Certificate Manager with a Global offer several endpoints, each defined by a Security Mode, a Discovery Server (GDS) is also possible. Security Policy, and the supported User Identity Token(s). The A GDS can provide two main functionalities. As the name Security Mode defines how messages are exchanged between ’Global Discovery’ suggests: OPC UA instances can query parties to achieve authentication, confidentiality, and integrity the GDS to find available applications that have previously guarantees. Available Security Modes are None, Sign, Sig- registered with the GDS. Additionally, a GDS can offer nAndEncrypt (Security Mode Sign and SignAndEncrypt en- the CertificateManager and allow applications to push their force application authentication). Security Policies define the certificate to the GDS or pull certificates from the GDS to cryptographic primitives used for the specific security mode: update the Trustlist. Sensor 42.42

Fig. 3. The figure shows a network consisting of an OPC UA server and two clients. An attacker that wants to establish themselves as a PitM has to (1) pose as an OPC UA client towards the legitimate OPC UA server and (2) as an OPC UA server towards a legitimate client.

NodeManagement, View, Query, Attribute, Method, Moni- toredItem, and Subscription. Each service set specifies a different functionality as defined in Part 4 of the OPC UA protocol [7]. For example, a client can read and write values related to the processes on OPC UA Nodes in the server through the Attribute service set. It is also possible to provide the functionality for the clients to add nodes. Moreover, clients can call methods (through the Method service set) defined for Object Nodes. Through these functionalities, a client can directly influence the plant operation. The OPC UA server can authorize clients to use its func- tionalities through user authentication. Session service set provides the user authentication functionalities (e.g., login with username and password). Authentication occurs during session activation, after the initial authentication via certificates.

III.OPCUASECURITY ASSESSMENT METHODOLOGY In this section, we present our approach for the security Fig. 2. Connection establishment between client and server using Security Mode SignAndEncrypt. assessment of OPC UA artifacts. OPC UA features a number of cryptographic options to establish secure channels (see Section II). Like in any system, authentication of parties to The server sends its certificate as part of the each other (application authentication in OPC UA) requires GetEndpoints() response. If the client selects an either pre-shared secrets or certificates with public keys. In endpoint with Security Mode Sign or SignAndEncyrpt, the this work, we argue that in the ICS setting (in which OPC UA following OpenSecureChannel message is encrypted with is adopted), no public PKI (e.g., with root CAs) is available, the server public key and signed with the client’s private so a core issue is how to establish the initial trust between key. This message also contains the client certificate. If the the communicating parties. There are two options in OPC server decides to trust the client’s certificate, the response is UA to tackle the certificate management and distribution: i) encrypted with the client’s public key and signed with the Self-signed certificates that need to be distributed manually server’s private key. The OpenSecureChannel Request, among parties that are willing to communicate in the OPC and Response messages contain a nonce from client and UA network, to build the so-called Trustlist. ii) Through server in the respective message. Client and server compute CertificateManager functionality as described in part 12 of the symmetric signing and encryption keys used in the session the OPC UA standard. The focus of our security assessment starting from the nonces [6]. Figure 2 shows the complete is the application authentication functionality required for the secure connection establishment procedure. security in OPC UA. We start presenting our system and attacker model, and C. Service Sets research challenges. Then we introduce our framework for OPC UA offers its functionalities through 10 service sets. OPC UA security assessment. Each service consists of a Service request and Service re- sponse, identifiable via RequestHeader and ResponseHeader. A. System and Attacker Model The ten service sets (and therefore the functionalities) We assume a local ICS network with OPC UA server as offered by the protocol are Discovery, SecureChannel, Session, depicted in Figure 3. The system operator guarantees security in the OPC UA system by allowing the server to offer only To address R2, we propose a framework to verify the secure endpoints (i.e., Sign or SignAndEncrypt, see Section II) correctness of implementations of OPC UA security features as suggested by the BSI [2]. We note that Intrusion Detection in hardware and software products. For proprietary products: Systems are out of scope in our model as we aim to look at we consult user manuals to verify the correctness of security security guarantees from the OPC UA artifacts. We assume features. For available libraries, we practically tested the secu- the network operator follows the user manual shipped with rity features by deploying OPC UA clients and server locally. the deployed ICS hardware/software to configure the OPC In general, we investigate correct key management in OPC UA UA server and client security. In this work, we consider three enabled products. In particular, with our framework, we tested attackers with different goals1. specific attacks against OPC UA client and server implemen- Rogue Server. A new device is introduced and now needs to tations, which are feasible due to erroneous or incomplete key establish secure OPC UA communications with other devices. management in OPC UA enabled products. For each library, An attacker is present in the network and aims to manipu- we create the OPC UA server and clients following the library late OPC UA clients by providing malicious information or instructions (first the default configuration, second the optional stealing of OPC UA user credentials. The attacker creates features) and test their vulnerability to the different attacks a server that offers secure endpoints to establish a secure presented in the Attacker Model (Section III-A). We plan to connection with new clients and make them believe that they release a proof of concept of our framework as open-source. are communicating with the actual OPC UA server in the To address R3, we show that breaking the application network. authentication of any OPC UA security configuration will have severe consequences on OPC UA security. An attacker Rogue Client. An attacker aims to connect to the OPC will be able to obtain plain-text passwords when legitimate UA server to eavesdrop or manipulate the information shared clients connect to Rogue Server or the Middleperson system between the server to its clients. The attacker creates a client and perform user authentication, to modify the data seen by that attempts to connect to the server although not authorized OPC UA clients and servers, and to execute function calls on by the network operator. an OPC UA server that can interfere with the physical process Middleperson attack (PitM). An attacker aims to establish (e.g. send commands to actuators). We will discuss this further themselves as Middleperson in the connection between the in the next Section. client and server, intercepting and manipulating all communi- cations between both. In general, this requires achieving Rogue IV. FRAMEWORKAND IMPLEMENTATION Client and Server objectives. In this section, we present our framework for the security assessment of OPC UA artifacts. First, we will describe our B. Research Questions and Challenges framework from a high-level perspective; then, we provide the With our research, we aim to address the following research details about the framework implementation used to test the questions. R1. What are practical challenges for the correct OPC UA artifacts. The results of our security assessment are use of OPC UA security features? R2. Are OPC UA security presented in Section V. features correctly implemented by the vendors and products? A. Framework R3. What are the consequences of breaking OPC UA security features? Our framework tests OPC UA clients and OPC UA servers While addressing those research questions, we tackle the against Rogue Server, Rogue Client, and Middleperson at- following research challenges: i) Partially proprietary products tacks. For OPC UA servers, the framework identifies vulnera- without source code. ii) available OPC UA libraries partially bilities to Rogue Client Attacks, while for OPC UA clients the documented, iii) unavailability of products (or real deploy- framework identifies vulnerabilities to Rogue Server Attacks. ments) for testing. The framework test for vulnerabilities generated by incorrect (or incomplete) Trustlist management (that deviates from the C. Proposed Approach prescriptions of the OPC UA protocol). When both Rogue Client and Rogue Server vulnerabilities are present in the OPC The focus of our approach is the analysis of the secu- UA network, Middleperson attacks can be exploited. rity features implemented by OPC UA software available. In particular, we focus on key management functionalities Rogue Server. In Figure 4 we report the steps followed by implemented in OPC UA artifacts i.e. i) Proprietary hardware our framework to verify the vulnerability to the Rogue Server. and software that implements OPC UA stack, ii) available The test employs an OPC UA Rogue Server to test OPC UA libraries that implement the OPC UA stack. clients. The Rogue Server waits for a getEndpoints() To address R1, we survey proprietary and available OPC request from a victim client and replies offering secure end- UA enabled products. We investigate practical challenges for points and its self-signed certificate that is not present in the correctly configuring secure OPC UA setups in the analyzed client’s Trustlist. The victim client receives the endpoints and products checking availability of features. the certificate (server Application Instance Certificate). The Trustlist of the OPC UA victim client does not contain the 1We use the gender-neutral ‘they’ as pronoun in this work Rogue Server’s public key (Application Instance Certificate). Fig. 4. Rogue Server workflow. The server waits for a new incoming connec- tion. When the Server receives a getEndpoints() request it provides a certificate that was not trusted on the client side upon connection (highlighted in red). If the client trusts the server certificate and performs an OpenSecureChannel() request to the server, the Rogue Server allows the connection (highlighted in green) and the attacker can perpetrate his attacks e.g. steal credentials and send manipulated data. The client is misconfigured and vulnerable to Rogue Server attack. Fig. 5. Rogue Client workflow. The dashed boxes contain the flowchart rep- resenting the application server/client logic. Diamonds represent a decisions by the client/server according to the data flow and management. The client lists all the secure endpoints on the server and for each one it tries to connect Hence, the victim client should not establish a secure con- providing an arbitrary self signed certificate (highlighted in red) that was not nection with the untrusted Rogue Server as the root of trust shared with the server in advance. If the client successfully connects, the server is not correctly managing certificates. between client and Rogue Server was not established upon connection. If the victim client is correctly configured, it will not continue the interaction with the Rogue Server. Otherwise, of them, one by one. The Trustlist of the OPC UA server the victim client trusts the Rogue Server and instantiates does not contain the Rogue Client’s certificate. Hence, the an OpenSecureChannel() request that the Rogue Server Rogue Client should not be entitled to establish a secure accepts. connection with the server because the root of trust between As a consequence of a Rogue Server attack, an at- client and server was not acknowledged upon connection. If tacker can send fake data to the victim client and steal the client succeeds in connecting, the server implementation is user credentials. User credentials stealing occurs when the managing erroneously the certificates, and it is deviating from ActivateSession() request is instantiated by the Client. the expected behavior prescribed by OPC UA protocol. The If the Rogue Server endpoints are configured with ‘UserI- server is then considered vulnerable to Rogue Client attacks. dentityToken’ user and password, the attacked client will As a consequence of a Rogue Client attack, an attacker can be required to authenticate (activate a session) to estab- perform different actions on the server according to the server lish a connection with the Server. OPC UA session activa- configuration. The attacker possibilities range from reading tion request (that contains user and password) is encrypted values published by the attacked OPC UA server to writing with the keys derived from the Nonces exchanged in the values and executing commands on the server that influence OpenSecureChannel() with the Rogue Server. Moreover, the physical process. the password is encoded in UTF-8 and encrypted with the Middleperson. Figure 6 reports the steps followed by our server public key (i.e., the key received from the untrusted framework to verify the vulnerability to the Middleperson Rogue Server). Despite the different encryption techniques attack. The test leverages the concepts of Rogue Client and applied to encrypt the password before transmission, the Rouge Server used at the same time to achieve the Mid- Rogue Server will decrypt them because the client allows the dleperson attack. The attacker instantiates a Rogue Server in connection with untrusted parties. the network. The client requests a secure connection with the Rogue Client. In Figure 5 we report the steps followed Rogue Server (as described in the previous paragraphs). If by our framework to verify the vulnerability to the Rogue the attacked server requires user authentication with username Client in OPC UA servers. The test employs an OPC UA and password, the Rogue Server can use the same user identity Rogue Client to the test OPC UA server implementations. token to the victim’s client and steal the credentials. At this The Rogue Client scans all the endpoints offered by an OPC point, the Rogue Client instantiates a connection with the UA server and tries to establish a secure connection to all victim’s server by providing the stolen credentials and takes the attack to perform (i.e., Rogue Server, Rogue Client, or Middleperson). Rogue Server attack. When Rogue Server attack is selected, the rogueserver module performs the following to mount and start the attack. First, the program executes port scanning in the network to identify available OPC UA servers on port 4840. The attacker selects a benign server that they want to clone with the Rogue Server attack. At this point, the sequence of unencrypted and unauthenticated primitives FindServers() and GetEndpoints() requests are sent to the benign server to retrieve endpoints information, server information, and the server certificate. A Rogue Server is created with this information. The Rogue Server has the same name, offers the same endpoints (same security mode, security policy), the same user identity token, and provides a self-signed certificate filled with the same information as the benign server. When Rogue Server is configured, port forwarding is enabled in the network to route requests intended to the victim’s server to the Rogue Server. Finally, the server is started and waits for a victim client to connect to it without performing certificate validation. If the connection succeeds, Fig. 6. Example of Middleperson attack with stealing of session credentials the Rogue Server starts publishing fake data, and if the victim’s (User Identity Token: User, Password). The attacker acts both as Rogue Client client provides user credentials, the Rogue Client decrypts and Rougue Server. The Target Client connects to the Middleperson Server, that provides to the client a self signed certificate. The client is vulnerable them. to Rogue Client attacks and trusts the server cert without verification and instantiates a OpenSecureChannel() request. The Rogue Server allows the Rogue Client attack. When Rogue Client attack is selected, connection. When the client instantiates a session the server accepts it and the rogueclient module performs the following actions decrypts the provided credentials. At this point the Middleperson connects to to mount and start the attack. First, the attack performs port the Target Server (that is vulnerable to Rogue Client Attacks) and creates a session providing the credentials stolen from the Target Client. scanning in the network to identify available OPC UA servers on port 4840. The attacker chooses the victim server that they want to connect through the Rogue Client attack. At control of the industrial process (as described in the Rogue this point, the client attempts the OpenSecureChannel() Client paragraph). The attacker forwards stealthily (from the request to the victim server endpoints (one by one), providing process operators) the information received from the victim a self-signed certificate that was not inserted in the victim client to the victim server and vice versa. server Trustlist upon connection. If the cert is trusted, the Consequences of the Middleperson attack comprise the attack is successful. Furthermore, if the victim server requires union of the outcomes identified for Rogue Client and Rogue the user identity token ’None’: the Rogue Client instantiates Server. a ActivateSession() request and can start reading (or writing) values at server nodes. If a user identity token with username and password is required, the attacker can input them B. Implementation (e.g., they retrieved them with a Rogue Server attack). Finally, We implemented our framework (i.e., Rogue Server, Rogue the ActivateSession() request is sent to the server. Client, and Middleperson) using the python opc-ua [8] open Middleperson attack. When the Middleperson attack is source library. The implementation serves as a Proof of selected, our POC realizes the attack depicted in Figure 6. concept (POC) of our attacks. We have implemented the POC The rogueserver and rogueclient modules are used using the python opc-ua since the library offers support to in parallel (i.e., in threads). First, the Rogue Server is created all the functions required to implement our proposed attacks. to capture victim client requests in the network and acquire Moreover, the functionalities are easy to prototype and deploy. user credentials. Once the credentials are retrieved, the Rogue Our framework consists four python modules, framework, Client is instantiated and connects to the victim’s server rogueserver, rogueclient, and utils for a total of providing the stolen credentials. The attack is successful if 571 lines of code. For each of the attacks that we implemented both the victim’s client and server do not populate the Trustlist (Rogue Server, Rogue Client, and Middleperson), we report upon connection. a description of how we realized functionalities through the python modules. V. ASSESSMENT RESULTS Framework module. framework module interacts with In this section, we present the results of our security assess- the attacker. It offers a command-line interface to select ment of 22 OPC UA products by different vendors (i.e., mostly OPC UA servers for PLCs), and 26 systems we build using 16 three attacks considered in our manuscript. We will detail the available libraries. We start by investigating the availability of configuration issues in the following subsections. features of the OPC UA stack implemented in the considered Available OPC UA libraries. In Table II we report the results artifacts. Then we perform a security assessment for OPC UA of our research about the adoption of OPC UA features that products with our framework and look for vulnerabilities to we conducted over 16 available libraries to deploy OPC UA in Rogue Client, Rogue Server, Middleperson attacks. industrial plants. The table is divided into four parts: support of A. Adoption of OPC UA features publish-subscribe, compatibility with Global Discovery Server, In this section, we investigate which features of OPC UA server security features, client security features. stack are implemented by OPC UA enabled artifacts. We Out of 16 libraries: 11 libraries implement server features, consider proprietary products, and available software. and 15 libraries implement client features. Specifically, 10 libraries offer server and client features, 5 offer solely client Proprietary OPC UA products. In Table I we report the features, and 1 offers solely server features. Publish-Subscribe results of our research about the adoption of OPC UA features is implemented by 2 libraries (open62541, S2OPC), also in that we conducted over 22 proprietary OPC UA products that this case, this feature is not widely adopted. At the mo- are offered by vendors to configure their industrial devices. ment of writing, the OPC Foundation official implementation The table is organized into three parts, i) support of publish- (UA .NET) does not support this connection mode. GDS subscribe, ii) compatibility with Global Discovery Server, is implemented by 1 library (UA .NET). With respect to iii) security features. Out of 22 software packages that were security features implemented in servers, 10 out of 11 offer analyzed, four vendors rely on Codesys automation software security features. Regarding the security features implemented to implement OPC UA features. in clients, 12 out of 15 implement security features. More- None of the considered products support the publish- over, we have investigated the correctness of security features subscribe model. This feature, announced in the first semester implementation. Specifically, we looked at the availability of of 2018, is not yet supported by products. In October 2020, the Trustlist for certificate verification as described in the Codesys software released the CODESYS OPC UA PubSub OPC UA standard. Among server implementations, 6 (Eclipse SL [31] extension that supports Publish-Subscribe, but at the Milo, node-opcua, Rust opcua, open62451, S2OPC, and UA moment of writing, vendors do not integrate it yet. .NET) offer this feature, while the other 5 (ASNeG, LibUA, Four vendors mention compatibility with GDS servers, but OpenScada UA, Python-opcua) do not allow the server to it is not clear if these vendors also offer their implementation verify to which clients they are communicating with. Among of a GDS server or provide functionality for their products to the client implementations, 6 (Eclipse Milo, Rust opcua, connect to third party software. open62541, UA .NET, opc-ua-client, and UAExpert) offer Concerning the security features, out of 22 OPC UA servers, Trustlist functionality, while 4 libraries (LibUA, node-opcua, three vendors (Beijer, Honeywell, and Yokogawa) do not OpenScadaUA, Python-opcua) do not provide the feature to support security features. It means that deploying an OPC UA verify the party that they are communicating with. Regarding network with industrial devices from those brands will always the remaining 2 implementations (Golang opcua, and S2OPC), result in an insecure deployment since the only supported we run into issues while verifying their secure connection security policy is None. A total of 3 vendors (Bachmann, functionalities that prevented us from testing the availability Beckoff, and Lenze) support security with deprecated crypto- of Trustlist features. Finally, we check the security features graphic primitives, making their applications de facto insecure. and verify their correct configuration in the demo applications For the remaining 16 products that support security features, provided in their repository. The following subsections will we have looked at how the user manual guides the customers detail the pitfalls and problems that we found in the security through the server configuration. Specifically, we observed that of available implementations, making them vulnerable to the two vendors (Mitsubishi and National Instruments) instruct considered attacks. their users to configure security None. Then, three vendors (B&R, Omron, and Panasonic) discourage the use of None, B. Vulnerability to Rogue Server and six vendors (Codesys, Hitachi, Rockwell, Siemens, Wago, Eaton) do not give recommendations on the preferred policy. We tested the vulnerability of 15 Client implementations Furthermore, four vendors (ABB, General Electric, Schneider, from available libraries, as vendors do not offer OPC UA Wiedmuller)¨ recommend a specific Security Policy (Schnei- client functionalities (apart from Bachmann). We found that all der and Weidmuller¨ use security mode SignAndEncrypt as available Client demo applications are configured to connect default). Finally, one vendor (Bosch Rexroth) does not support to a security point with mode None, i.e., no security. For 3 security mode None, thereby enforcing authenticated connec- libraries (ASNeG, Free OpcUa, opcua ts) no other mode is tions. We report in the table if the certificate Trustlist is possible. The ASNeG library will support security features supported as required by the OPC UA specification. As we starting from the next release. The 12 remaining libraries can see from the table, most vendors support it but, there support secure connections. are several problems in the configuration procedure detailed For those 12 libraries, we verified their support to Trustlist in user manuals that make deployments vulnerable to the for certificate management and tested it with our framework TABLE I ADOPTION OF FEATURES OPCUA IN PROPRIETARY PRODUCTS. DENOTES THAT THE FEATURE IS SUPPORTED BY THE PRODUCT. DENOTES THAT THE FEATURE IS NOT SUPPORTED BY THE PRODUCT. DENOTES THAT THE FEATURE IS SUPPORTED BUT THERE ARE PROBLEMS# WITH ITS CONFIGURATION THATG# MAKE INDUSTRIAL DEPLOYMENTS INSECURE.

Vendor Platform Pub-Sub GDS Security Trustlist Recommended Policy

B&R ADI OPC UA [9] Not specified Bachmann OPC UA Client and Server [10] # # Deprecated protocols Beckoff TC3 OPC UA [11] # # G# G# Deprecated protocols Beijer iX Developer [12] # # G# G# None Bosch Rexroth ctrlX CORE [13] # # ## None not supported General Electric iFIX [14] # compatible# G# Basic256Sha256 Honeywell ControlEdge Builder [15] # G# None Lenze Easy Starter [16] # # ## Deprecated protocols Mitsubishi MX Configurator-R [17] # # G# G# None National Instruments InsightCM [18] # # None Omron SYSMAC-SE2 [19] # # Not specified Panasonic HMWIN Studio [20] # compatible# Not specified Rockwell Factory talk linx [21] # G# Not specified Schneider Control Expert [22] # # Basic256Sha256 Siemens STEP 7 [23] # compatible# Not specified Weidmuller¨ u-create studio [24] # G# Basic256Sha256 Yokogawa SMARTDAC+ [25] # # None Codesys based# platforms# ## Codesys Codesys V3.5 [26] Not specified ABB Automation Builder [27] # G# Basic256Sha256 Eaton XSOFT-CODESYS [28] # # G# Not specified Hitachi HX Codesys [29] # # G# Not specified Wago e!cockpit [30] # compatible# G# Not specified # G# implementation. In 4 libraries (LibUA, node-opcua, Open- ii) Use of unencrypted primitives to perform certificate Scada UA, and python-opcua), the Trustlist is not supported. exchange In one implementation (UAexpert with GUI inter- In 3 libraries, we had issues configuring and running the face) the instructions guide the user to perform a ‘GetEnd- client application in a secure configuration. In Eclipse Milo, points’ request to retrieve the Server certificate. The server the demo client does not perform certificate validation and replies to the client sending his certificate to the client. The the documentation does not provide details about how to Client prompts the error ‘BadCertificateUntrusted’ since the enable the Trustlist on although the feature is present in the server certificate fails the security check. At this point, the source code. In S2OPC the source code features the Trustlist client is asked to trust the certificate and re-instantiate a secure management, but we were not able to test it due to errors and connection. This behavior is susceptible to Rogue Server missing details for the configuration. Finally, in Golang opcua attacks since the certificates are exchanged through an insecure we were not able to find information related to the Trustlist channel. UAexpert offers the option to trust certificates before neither in the documentation, issues in the repository, or the establishing a connection to servers, but this is not the default code, hence we assume that this feature is not supported. workflow proposed in the instructions. In 5 clients, the Trustlist is supported, but we found two Overall all 12 clients that support security features exhibit types of insecure behavior that make these clients vulnerable vulnerabilities that can be exploited in a Rogue Server attack. to Rogue Server attacks: Even libraries that have handled security correctly on the i) Trustlist disabled by default In 4 libraries (Opcua server-side are lacking security features on the client-side, Rust, UA.Net, and open62541, opc-ua-client) the demo client forcing users to lower the security properties of their OPC accepts all server certificates by default. The user can disable UA deployments. this option, then the mentioned libraries behave correctly w.r.t. the certificate validation procedure. While this setting C. Vulnerability to Rogue Client is only meant to be used during development and testing, it In this section, we report the results of our security assess- is an additional hurdle that can lead to a seemingly secure ment w.r.t. the vulnerabilities to the Rogue Client for the OPC application that is vulnerable to a Rogue Server attack. UA artifacts. TABLE II LIBRARIESWITH OPCUA IMPLEMENTATION. DENOTES THAT THE FEATURE IS SUPPORTED BY THE PRODUCT. DENOTES THAT THE FEATURE IS NOT SUPPORTED BY THE PRODUCT. DENOTES THAT THE FEATURE IS SUPPORTED BUT THERE ARE PROBLEMS WITH ITS# CONFIGURATION.* DENOTES THAT THEFEATUREISGOINGTOBEINTRODUCEDINNEXTRELEASEG# .THECOLUMN SECURITYREPORTSWHETHERTHELIBRARYIMPLEMENTSSIGNINGAND ENCRYPTION.THECOLUMN TRUSTLIST REPORTS WHETHER THE LIBRARY IMPLEMENTS APPLICATION AUTHENTICATION.THECOLUMN DEMO BEHAVIOURREPORTSWHETHERASECURECONNECTIONTOTHEDEMOAPPLICATIONISPOSSIBLE.

Server Client Name Lang. Pub-Sub GDS Security Trustlist Demo Behavior Security Trustlist Demo Behavior

ASNeG [32] C++ * - *-- Eclipse Milo [33] Java # # # # Free OpcUA [34] C++ # # --- G#-- # LibUA [35] C# # # # node-opcua [36] .js #* # # # # # opc-ua-client [37] C# # #- --- G# # # opcua [38] Rust # G# opcua [39] Golang # # --- G# -- G# opcua [40] TypeScript # #------opcua4j [41] Java # -- #--- open62541 [42] C # # # OpenScada UA [43] C++ # G# G# Python-opcua [8] Python # # # # # # S2OPC [44] C # # # # # # UA.NET [45] C# # G# G# UAexpert [46] C++ # --- G# # # G#

Vendors. Since we do not have access to actual devices, move the client certificate from client to server (instead of our analysis relies on the official user manuals shipped with building the Trustlist before any connection in the network products. The results for the 22 analyzed products are reported as required in the OPC UA standard). This behavior is an in Table I. The vendors Yokogawa [25], Honeywell [15] and improper use of the OPC UA standard that can be leveraged Beijer [12] do not support any security features for OPC by an attacker to install its Rogue Client certificate on a UA: this means that they do not offer secure communications target server. On the server-side, the certificate is manually channels to send information to clients and will not be able or automatically trusted. An operator would need to carefully to perform application authentication. check the certificate thumbprint to notice that the installed cer- For the remaining 19 companies, we have investigated if tificate is not authorized. We identified this as a common error they use the Trustlist to enable only certain clients to connect in the instructions from 10 different vendor products (ABB, to the server. All the companies implement the Trustlist for Beckoff, Bosch Rexroth, Codesys, Eaton, General Electric, certificate verification, only 7 out of 19 correctly instruct the Hitachi, Lenze, Panasonic, and Wago). All 4 products analyzed users to configure it. We found that 12 companies report inse- based on Codesys software propagate this error present in cure instructions to perform the certificate exchange necessary the Codesys documentation. This problem may potentially be to build the Trustlist that makes them vulnerable to Rogue threatening more than 400 device manufacturers that rely on Client attack. In particular, we have identified two different this Codesys software. issues with the instructions: As showed in Section IV if the initial certificate exchange i) Trustlist disabled by default The instructions by default is incorrect, the security guarantees of the OPC UA standard guide the user that enables security to configure the server are lost and, the signed/encrypted channels do not guarantee to accept all certificates and optionally the user can configure communication security as the authentication of the commu- the Trustlist. If the server has default settings, an attacker can nicating parties is flawed. connect a client to the server providing an arbitrary certificate Libraries. We tested the vulnerability to Rogue Client attack that is not verified upon trusting it. Siemens and Bachmann’s of the 10 server libraries that offer security features. This products are affected by this issue. evaluation is done with our framework implementation as ii) Improper use of Secure Channel primitives to per- described in section IV. To perform our test, we started from form certificate exchange The issue resides in the procedure demo applications shipped with the libraries and then verified used to exchange certificates. The product affected by this if the library itself has additional capabilities not used in the issue leverages the OpenSecureChannel() request to demo to manage security features. If additional features are available, we add them to the server to test the library. All libraries provide a demo server or a tutorial explaining how to set up a simple OPC UA server. Out of the considered demo applications, 5 demo applications offer secure and insecure endpoints, and 5 offer exclusively security None. For demo applications where only insecure endpoints are supported, any client can connect to the server via the security mode and policy None (i.e., without securely authenticating). Next, we tested the certificate management functionalities offered through Trustlist (mode Sign or SignAndEncrypt). We found that 6 libraries support the Trustlist of certificates, and 4 do not support it. With our framework Rogue Client we tested the 6 demo servers provided by the implementations that support the Trustlist. Our framework tries to establish a connection in mode Sign or SignAndEncrypt where the client provides a self-signed certificate, which was not listed on the server Fig. 7. This chart summarizes the findings of our work. It shows how the before connecting. According to the OPC UA standard, such security properties for the 48 OPC UA enabled artifacts are distributed. For the artifacts that are insecure the chart details the reason of the insecure behavior. connections should be rejected by the server. The majority of the OPC UA artifacts present security issues. In 3 cases the demo server rejects connection from untrusted clients (Eclipse Milo, UA.Net, s2opc). The demo server from Eclipse Milo, available at this address there are 4 libraries where the implementation of the Trustlist ‘opc.tcp://milo.digitalpetri.com:62541/milo’, rejects unknown is missing. In the library LibUA, a function is prepared for the clients, and users are required to upload their client certificates user with a comment to implement certificate authentication. to the server to appear in the server Trustlist and connect. Users of the ASNeG and the Python-opcua library have Similarly, the demo servers provided by the UA.Net library pointed out the missing security features in issues on GitHub. and the s2opc library reject connection attempts of unknown For the ASNeG library, this feature is planned for the next clients. release [47]. Developers of the Python-opcua library in 2017 Moreover, we found that 3 demo servers show the same two acknowledged the issue [48], but it is not available yet. types of insecure behaviors identified in the vendor section. i) Trustlist disabled by default Untrusted connections are D. Vulnerability to Middleperson attack allowed (by default) in 2 libraries (node-opcua, open62541), In Section IV we explained that the Middleperson attack which are not enforcing the use of the Trustlist to start can be performed when there are servers vulnerable to Rogue the server. Again we found a major flaw in the certificate Client attacks and clients vulnerable to Rogue Server present at exchange. the same time in the network. Combinations of aforementioned In node-opcua there is a boolean variable ’automatically- OPC UA servers and clients that are vulnerable respectively to AcceptUnknownCertificate’ that is turned to ’true’ by default Rogue Client and Rogue Server attacks would make a deploy- when creating OPC UA server. This setting is transparent to ment that is vulnerable to Middleperson attacks. In particular, users that are allowed to build a server without setting this we have identified that 19 servers artifacts out of 29 (65%) that variable explicitly. In the open62541 library, the user can start support security features are vulnerable to the Rogue Client the server with or without the Trustlist. The Trustlist can be attack (4 artifacts due to missing Trustlist features and 15 selected as an optional parameter to start the server from the due to insecure instructions Trustlist) and 12 clients out of 12 command-line interface. When the server is started without (100%) that support security, are vulnerable to Rogue Server the Trustlist, any incoming certificate is accepted, the program attack (7 artifacts due to missing Trustlist features and 5 due notifies the user is notified of this behavior. to insecure instructions to configure Trustlist). As we can see ii) Improper use of Secure Channel primitives to per- there is a non-negligible risk to deploy an insecure OPC UA form certificate exchange The Rust opcua library uses the network where an attacker can operate as Middleperson. Trustlist for certificate validation in demo applications, but the suggested procedure on certificate exchange is vulnerable. E. Summary of Findings After a connection attempt, the client certificate is stored in We considered a total of 48 OPC UA enabled artifacts: 22 the ’rejected’ list of certificates from where an operator should products from vendors and 16 available libraries (of which move it to the trusted folder. An attacker can create a certificate 11 provide OPC UA servers, 15 provide OPC UA clients). similar to the real client certificate that is difficult to tell apart. Figure 7 reports a summary of our findings that we detail in Finally, for the remaining 4 demo applications, the missing the following. support to client certificate authentication is caused by missing Seven artifacts do not support security features at all features in the library altogether. In particular, we found that (14.6%). Among the 41 remaining artifacts that support secu- rity features, we found that 31 artifacts (64.6% of the 48 OPC The mentioned countermeasures, although simple, can mit- UA artifacts) show issues or errors in the Trustlist management igate the three common issues that we have encountered in that enable Rogue Client, Rogue Server, and Middleperson our work and avoid vulnerable OPC UA deployments. attacks. The other 10 artifacts (20.8% out 48) correctly im- VII.RELATED WORK plement the Trustlist management and instruct users about its configuration, and thus they are not vulnerable to the Security analysis of open source OPC UA libraries. In [49], Rogue Client, Rogue Server, and Middleperson attacks. The 31 the authors study the security of four popular open-source artifacts that show security issues with the configuration of the libraries (UA .Net Standard, open62541, node-opcua, Python- Trustlist can be classified into the following three categories: opcua) which we also inspect in this paper. The analysis

• Missing Support for Trustlist. 11 artifacts do not im- focuses on five aspects: dependencies, timeouts, supported plement Trustlist (or do not provide instructions about Security Policies, message processing, and randomness. The its configuration) management although they implement authors identify two vulnerabilities in the implementations: OPC UA security features, that is they offer functionality missing upper time limits in Python-opcua leaving the library for signing and encryption but not for the validation vulnerable to DoS attacks and missing packet type checks in of certificates. This makes their deployments always node-opcua. The problems that we discovered with our work, vulnerable to Rogue Client, Rogue Server, Middleperson regarding the Trustlist configuration of the libraries, were not attacks. identified. • Trustlist disabled by default. in 8 artifacts the Trustlist Neu et al. [50] and Polge et al. [4] have shown the is enabled optionally. feasibility of a DoS attack by a Rogue Client. They suggest • Insecure Trustlist configuration. in 12 artifacts the detecting anomalies in the network traffic as a countermeasure. instructions guide the users to improper use of Secure Polge et al. [4] additionally implement a Middleperson attack Channel primitives to perform certificate exchange. using Eclipse Milo. The attacked OPC UA applications are using Security Policy None or Aes128-Sha256-RsaOaep. They Adoption of features. in our analysis of OPC UA features, report that if username and password are sent as part of the Ac- we found that while the client-server model is available in tivateSessionRequest message the password is encrypted even all tested products while the publisher-subscriber model is in Security Mode None and can therefore not be recovered (in supported by 3 artifacts. Moreover, the features offered by contrast to the findings presented in this work). The encryption the GDS to manage certificates are supported by 5 artifacts. of the password in Mode None is not required according to the Security features are widely adopted, but they require the Specification [7]. The developers of the library have made the correct distribution of certificates in order to deploy a secure decision to encrypt the password by default even if Security network. As we found, this is not always the case in OPC UA Mode None is used [51]. Based on vulnerabilities we found, products as many of them do not implement the Trustlist for a Middleperson attack that recovers plain-text credentials is certificates or do have issues in the configuration procedure. possible. More specifically, the client examples provided by the Milo library are vulnerable to the attack since arbitrary VI.COUNTERMEASURES certificates are accepted. Therefore, a Middleperson attacker can provide their own certificate, and the user credentials are Our work showed general missing support and incomplete- encrypted using the public key associated with the attacker’s ness of OPC UA security features. This might be due to a certificate. general unawareness about the root importance of the Trustlist Secure exchange of certificates. The security of the OPC in the secure channel establishment for OPC UA (or not UA protocol relies on certificates that authenticate each ap- among motivating drivers during the development [48]). In plication. Prior publications proposed techniques to establish our manuscript we have identified three common issues in the the initial root of trust in OPC UA. Meier et al. [52] propose analyzed artifacts. In this section, we propose some counter- to connect a new OPC UA application to a physical device measures to prevent vulnerabilities in OPC UA deployments. with certificate manager functionality to install a certificate and Missing support to Trustlist. This problem can be solved the Trustlist before connecting the application to the network. by implementing the Trustlist management as described in the In [53], a PKI is implemented. The PKI offers functionality OPC UA standard. to sign certificates or verify the trustworthiness of certificates Trustlist disabled by default. This problem can be solved by using the Online Certificate Status Protocol. enabling the Trustlist by default, and by making it mandatory VIII.CONCLUSIONS to populate the Trustlist upon the creation of secure channels. In this work, we have systematically investigated practical Certificate exchange through Secure Channel primitives. challenges faced to use OPC UA securely. To this end, This problem can be solved with a twofold solution i) remove we have introduced a security assessment methodology— the instructions that lead to this insecure behavior from user our assessment considers three attacks that can target OPC manuals, ii) make it mandatory to populate the Trustlist upon UA deployments, Rogue Server, Rogue Client, Middleperson the creation of secure channels. attacks. Our research poses three research questions and three challenges. With our approach we systematically address the [3] M. Dahlmanns, J. Lohmoller,¨ I. B. Fink, J. Pennekamp, K. Wehrle, research questions R1, R2, R3. To recall, the questions were and M. Henze, “Easing the conscience with opc ua: An internet-wide study on insecure deployments,” in Proceedings of the ACM Internet R1. What are practical challenges for the correct use of OPC Measurement Conference, 2020, pp. 101–110. UA security features? R2. Are OPC UA security features [4] J. Polge, J. Robert, and Y. Le Traon, “Assessing the impact of attacks on correctly implemented by the vendors and products? R3. What opc-ua applications in the industry 4.0 era,” in 2019 16th IEEE Annual Consumer Communications & Networking Conference (CCNC). IEEE, are the consequences of breaking OPC UA security features? 2019, pp. 1–6. To address R1, we conducted the first systematical survey of [5] O. Foundation, “Opc unified architecture specification part 2: Security 48 OPC UA artifacts provided by vendors or available online. model v1.04,” 2018. [6] ——, “Opc unified architecture specification part 6: Mappings v1.04,” Our survey investigates the availability of OPC UA security, 2017. publish-subscribe, and Global Discovery Server functionali- [7] ——, “Opc unified architecture specification part 4: Services v1.04,” ties. We showed that publish-subscribe and Global Discovery 2017. Server are not widely adopted. Furthermore, we showed that 7 [8] F. O. ua, “Opc ua implementation,” https://github.com/FreeOpcUa/ python-opcua, accessed December 10, 2020. OPC UA do not support for security features of the protocol at [9] B. I. A. GmbH, “Adi opc ua server user’s manual all. In addition, we found that 31 artifacts that partially feature v1.27,” https://www.br-automation.com/es-mx/descargar/ OPC UA security rely on incomplete libraries and come with industrial-pcs-and-panels/automation-pc-3100/kabylake-system-unit/ windows-10-iot-enterprise-2016-ltsb/adi-opc-ua-server-users-manual/, misleading instructions. accessed November 3, 2020. To address R2, We proposed a framework to investigate the [10] Bachmann, “OPC UA client and server,” http://bachmann.bbdevserver. identified security issues. With our framework, we show that de/fileadmin/media/Produkte/Vernetzung/Produktblaetter/Software OPC-UA-server en.pdf, accessed 14 January, 2021. the identified issues make OPC UA artifacts are vulnerable [11] Beckhoff, “Tc3 opc ua,” https://download.beckhoff.com/download/ to Middleperson, Rogue Client, and Rogue Server attacks. document/automation/twincat3/TF6100 TC3 OPC-UA EN.pdf, Specifically, We have analyzed 48 OPC UA artifacts, 41 of accessed 14 January, 2021. [12] B. E. A. AB, “Opc ua server - ix developer 2.4 ki00312a,” https://www. those artifacts support security features. We found that 31 beijerelectronics.tw/en/Support/file-archive-tree-page?docId=58657, ac- out 41 artifacts present pitfalls in the Trustlist management cessed November 3, 2020. required to establish the initial root of trust. We have identified [13] B. R. AG, “Opc ua server application manual,” https: //www.boschrexroth.com/various/utilities/mediadirectory/download/ three recurring pitfalls in the Trustlist management that enable index.jsp?object nr=R911403778, accessed November 3, 2020. vulnerabilities in OPC UA deployments. Those recurring pit- [14] G. E. Company, “Certificate management and the opc ua server,” falls are the missing support to Trustlist, Trustlist disabled https://www.ge.com/digital/documentation/ifix/version61/Subsystems/ OPCUASVR/content/opcua about the trust list.htm, accessed by default, and certificate exchange through secure channel November 3, 2020. primitives. For each of the identified recurring pitfalls, we [15] H. I. Sarl,` “Control edge builder protocol configuration reference guide,” provide possible mitigation. https://www.honeywellprocess.com/library/support/Public/Documents/ ControlEdge-Builder-Protocol-Configuration-Reference-Guide-RTDOC-X288-en-161A. To address R3, we designed, implemented, and demon- pdf, accessed November 3, 2020. strated three types of attacks (Middleperson, Rogue Client, [16] Lenze, “Lenze opc ua communicationv1.1,” https://download.lenze.com/ and Rogue Server). The attacks allow the attacker to steal user AKB/English/201400321/Commissioning Lenze OPC UA V1 1.pdf, accessed November 3, 2020. credentials exchanged between victims, eavesdrop on process [17] M. Electric, “Melsec iq-r opc ua server moduleuser’s man- information, manipulate the physical process through sensor ual (startup),” https://dl.mitsubishielectric.com/dl/fa/document/manual/ values and actuator commands, and prevent the detection of plc/sh081693eng/sh081693engf.pdf, accessed November 3, 2020. anomalies in the physical process. [18] N. I. CORP., “Insightcm 3.7 manual,” https://www.ni.com/ documentation/en/insightcm/latest/serverconf/secure-opc-server/, Our findings demonstrate a major flaw on OPC UA artifacts accessed November 3, 2020. that threaten the OPC UA security guarantees. We believe [19] Omron, “Nj-series cpu unit opc ua user’s manual (w588),” that our proposed systematic approach is useful to increase https://assets.omron.eu/downloads/manual/en/v2/w588 nj-series cpu unit opc ua users manual en.pdf, accessed November 3, 2020. the awareness of the risks produced by the three common [20] P. E. W. E. AG, “Hmwin user manual,” https://mediap.industry. pitfalls for the key establishment that we have identified and panasonic.eu/assets/download-files/import/mn hmwin user peweu en. help users, developers and companies to understand the threats pdf, accessed November 3, 2020. [21] R. Automation, “Factorytalk linx gateway getting results guide,” that can be induced by those erroneous configurations of the https://literature.rockwellautomation.com/idc/groups/literature/ Trustlist. Finally, our POC implementation can be used as a documents/gr/ftlg-gr001 -en-e.pdf, accessed November 3, 2020. tool to test for erroneous configurations and improve security [22] S. Electric, “M580bmenua0100 opc ua embedded moduleinstallation and configuration guide,” https://download.schneider-electric.com/files? in OPC UA deployments. p enDocType=User+guide&p File Name=PHA83350.00.pdf&p Doc Ref=PHA83350, accessed November 3, 2020. [23] S. AG, “Opc ua .net client for the simatic s7-1500 opc ua server,” REFERENCES https://cache.industry.siemens.com/dl/files/901/109737901/att 955026/ v3/109737901 OPC UA Client S7-1500 DOKU V13 en.pdf, [1] O. Foundation, “Opc unified architecture specification v1.04,” https: accessed December 10, 2020. //opcfoundation.org/developer-tools/specifications-unified-architecture, [24] W. I. G. . C. KG, “u-create studio system manual,” https://mdcop. 2018. weidmueller.com/mediadelivery/asset/900 91150, accessed November [2] BSI, “Open platform communications unified architecture secu- 3, 2020. rity analysis,” https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/ [25] Yokogawa, “Opc-ua server (/e3)user’s manual,” http://web-material3. Publications/Studies/OPCUA/OPCUA.html, Bundesamt fur¨ Sicherheit in yokogawa.com/IM04L51B01-20EN 010.pdf, accessed November 3, der Informationstechnik, Tech. Rep., 2017. 2020. [26] Codesys, “Opc ua server,” https://help.codesys.com/api-content/2/ codesys/3.5.14.0/en/ cds runtime opc ua server/, accessed December 10, 2020. [27] ABB, “Ac500 user management with v3configuration and handling,” https://library.e.abb.com/public/2745203d43f64bf2af9add792d5b4e46/ AC500%20-%20Application%20Note%203ADR010315.pdf, accessed November 3, 2020. [28] Eaton, “Xc300 modular control,” https://es-assets.eaton.com/ DOCUMENTATION/AWB MANUALS/MN050005 EN.pdf, accessed December 10, 2020. [29] Hitachi, “Hx series application manual (software),” https: //www.hitachi-da.com/files/pdfs/produkte/SPS/HX/HX-CPU Software(Tentative).pdf, accessed November 3, 2020. [30] W. K. G. . C. KG, “Wago-i/o-system 750, 750-8xxx opc ua server,” https://www.wago.com/global/d/3597419, accessed November 3, 2020. [31] CODESYS, “Codesys opc ua pubsub sl,” https://store.codesys.com/ op-ua-pubsub-sl.html? store=en& from store=default, accessed January 14, 2021. [32] ASNeG, “Opc ua implementation,” https://github.com/ASNeG/ OpcUaStack, accessed December 10, 2020. [33] E. Milo, “Opc ua implementation,” https://github.com/eclipse/milo, ac- cessed December 10, 2020. [34] FreeOpcUa, “Opc ua implementation,” http://freeopcua.github.io/, ac- cessed December 10, 2020. [35] LibUA, “Opc ua implmentation,” https://github.com/nauful/LibUA, ac- cessed December 10, 2020. [36] Node-opcua, “Opc ua implementation,” http://node-opcua.github.io/, ac- cessed December 10, 2020. [37] C. S. LLC, “Opc ua implementaion,” https://github.com/ convertersystems/opc-ua-client, accessed December 10, 2020. [38] R. opc UA, “Opc ua implementation,” https://github.com/locka99/opcua, accessed December 10, 2020. [39] G. opcua, “Opc ua implementation,” https://github.com/gopcua/opcua, accessed December 10, 2020. [40] H. B. M. GmbH, “Opc ua implementation,” https://github.com/HBM/ opcua, accessed December 10, 2020. [41] opcua4j, “Opc ua implementation,” https://code.google.com/p/opcua4j/, accessed December 10, 2020. [42] Open62541, “Opc ua implementation,” http://open62541.org/, accessed December 10, 2020. [43] O. U. Interface, “Opc ua implementation,” http://oscada.org/main/ documentation/, accessed December 10, 2020. [44] S2OPC, “Opc ua implementation,” https://gitlab.com/systerel/S2OPC, accessed December 10, 2020. [45] OPCfoundation, “Opc ua implemntation,” https://github.com/ OPCFoundation/UA-.NETStandard, accessed December 10, 2020. [46] U. Automation, “Step-by-step connect example,” http://documentation. unified-automation.com/uaexpert/1.4.2/html/first steps.html#connect step-by-step, accessed January 14, 2021. [47] ASNeG, “Client certificates are not validated #44,” https://github.com/ ASNeG/OpcUaStack/issues/44, accessed January 14, 2021. [48] P. O. UA, “Client certificates are not validated #392,” https://github.com/ FreeOpcUa/python-opcua/issues/392, accessed January 14, 2021. [49]N.M uhlbauer,¨ E. Kirdan, M.-O. Pahl, and G. Carle, “Open-source opc ua security and scalability,” in 2020 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), vol. 1. IEEE, 2020, pp. 262–269. [50] C. V. Neu, I. Schiering, and A. Zorzo, “Simulating and detecting attacks of untrusted clients in opc ua networks,” in Proceedings of the Third Central European Cybersecurity Conference, 2019, pp. 1–6. [51] E. Milo, “Regression with username/password authentication #244,” https://github.com/eclipse/milo/issues/244, accessed January 23, 2021. [52] D. Meier, F. Patzer, M. Drexler, and J. Beyerer, “Portable trust anchor for opc ua using auto-configuration,” in 2020 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), vol. 1. IEEE, 2020, pp. 270–277. [53] G. Karthikeyan and S. Heiss, “Pki and user access rights management for opc ua based applications,” in 2018 IEEE 23rd International Conference on Emerging Technologies and Factory Automation (ETFA), vol. 1. IEEE, 2018, pp. 251–257.