![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/1569094872898-en-html-1.0.jpg\")
Possible communications offered by OPC UA <\/em>(Source: OPC Foundation website<\/a>)<\/p>\n
Two types of architecture can be set up:<\/p>\n
- \n
- Client-server architecture: this is the most widely used architecture. It is composed of hardware and\/or software elements that contain data, OPC UA servers that provide this data or services, and OPC UA clients that can interact with the servers to use their services or access their data.<\/li>\n
- PubSub architecture: it can be used to exchange a higher data volume. It is composed of Publishers who send messages, and Subscribers who receive these messages through a Message Oriented Middleware (MOM).<\/li>\n<\/ul>\n
\u00a0<\/p>\n
Client-server architecture security<\/h1>\n
As the client-server architecture is by far the most widely used, we will now look in more detail at the security mechanisms offered by the OPC UA standard in this type of architecture.<\/p>\n
First of all, three levels of security are available regarding the encryption of communications between a client and an OPC UA server:<\/p>\n
- \n
- None<\/em>: messages are sent in clear text, without any protection<\/li>\n
- Sign<\/em>: messages are signed. This protects the integrity of the transmitted data, but not their confidentiality<\/li>\n
- SignAndEncrypt<\/em>: messages are signed and encrypted. In this case, the confidentiality of the messages is also protected<\/li>\n<\/ul>\n
To set up an encrypted channel, the client and server each have an X.509 certificate and an associated private key, which they use to exchange a session key in a secure channel. Then, they can use this session key to encrypt the rest of the exchanges, using symmetric encryption algorithms.<\/p>\n
Several levels of security for user authentication are also available. To authenticate, clients send tokens to the servers called UserIdentityTokens<\/em><\/a>, which contain the information necessary for the authentication process. There are several types of UserIdentityToken<\/em>, and the server chooses which types it accepts:<\/p>\n
- \n
- AnonymousIdentityToken<\/em><\/a>: this token does not contain any specific information. If the server accepts it, and authenticates the user as an anonymous user<\/li>\n
- UserNameIdentityToken<\/em><\/a>: this token contains a username and a password. If these are valid, the user is authenticated and then obtains the profile and rights associated with his username<\/li>\n
- X509IdentityToken<\/em><\/a>: this token contains an X.509 certificate. If the server has registered this certificate, the user is authenticated and then obtains a profile and the rights associated with the certificate<\/li>\n
- IssuedIdentityToken<\/em><\/a>: this token encapsulates an access token provided by a third-party access management service, like an OAuth2 server for example<\/li>\n<\/ul>\n
Finally, once authenticated, the user has access to the server’s nodes. Below is an example of nodes that could be encountered on an OPC UA server:<\/p>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image1.png\")
\u00a0 \u00a0 \u00a0 \u00a0 ![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image2.png\")
\u00a0 \u00a0 \u00a0 \u00a0 \u00a0<\/p>\n\u00a0<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
OPC UA nodes<\/em><\/p>\nAccess control can be set up to restrict access to some nodes to high-privileged users (administrators, etc.), or to require that the communication channel be encrypted to access some sensitive nodes. The figure below summarizes how access management to a node works:<\/p>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image3-3.png\")
Role overview extracted from chapter 2 of the OPC UA specifications<\/em><\/p>\n\u00a0<\/p>\n
OPC UA audit tooling<\/h1>\n
Only few public tools are available to audit OPC UA applications. One of the most well-known is the Metasploit module called \u00ab\u00a0msf-opcua\u00a0<\/a>\u00bb.<\/p>\n
This module is composed of three scripts:<\/p>\n
- \n
- opcua_hello<\/em>: sends a “Hello Message” to a list of IP addresses, for a given port, to detect the presence of OPC UA servers among this list<\/li>\n
- opcua_server_config<\/em>: this script requires an authenticated access to an OPC UA server to be used. It allows to retrieve information on the configuration of the server endpoints (encryption, authentication…)<\/li>\n
- opcua_login<\/em>: performs a dictionary attack on a server using username and password authentication<\/li>\n<\/ul>\n
Although it provides some useful functionalities, this tool has some limitations. For example, it is not possible to scan several ports at once with the opcua_hello script. Another example is that the opcua_server_config script requires authentication to retrieve configuration information, which is available without authentication.<\/p>\n
Therefore, Wavestone decided to improve this tool. It was decided to stop using the Metasploit framework, which imposed too many constraints, therefore the tool is now an independent Python script, renamed \u00ab\u00a0opcua_scan\u00a0\u00bb. It is based on the opcua-asyncio<\/a> library, unlike the msf-opcua module which uses the python-opcua<\/a> library declared deprecated by its authors.<\/p>\n
The tool is accessible with this link<\/a>, and provides two commands: “hello” and “server_config”, which reimplement and improve the functionality of the opcua_hello and opcua_server_config scripts of the msf-opcua module. The opcua_login script is not included, as no improvement were performed, and it can be used directly.<\/p>\n
\u00a0<\/p>\n
The hello command<\/h2>\n
This command is used to detect OPC UA applications in a network. It sends “Hello Message” to a list of IP addresses, on a given list of ports, and deduces the presence or absence of OPC UA servers on the targets. Then, the FindServers<\/em><\/a> service, which is supposed to be implemented by any OPC UA server, is used to retrieve the ApplicationDescription<\/em><\/a> of the server (and other OPC UA applications known by the server). This object contains useful information, such as the productUri<\/em>, which gives information about the software or library used to run the detected server, or the discoveryUrls<\/em>, which indicates the URLs to the server’s DiscoveryEndpoints<\/em><\/a>. These endpoints can be used by the server_config command to retrieve more information about the server configuration.<\/p>\n
Several options have been added to the command, such as the configuration of the timeout or the possibility to retrieve the list of detected servers in a JSON output file.<\/p>\n
This is how the hello command could be used in practice:<\/p>\n
$ python opcua_scan.py hello -i <IPs> -p <ports> -o hello_output.json<\/pre>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image4.png\")
Example of results generated by the hello command<\/em><\/p>\nAnd the screenshot below shows an extract of the generated JSON file:<\/p>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image5.png\")
Extract of an output file generated by the hello command<\/em><\/p>\nThe complete documentation of the hello command and all its options is available here<\/a>.<\/p>\n
\u00a0<\/h2>\n
The server_config command<\/h2>\n
Thanks to the DiscoveryEndpoints<\/em><\/a> retrieved with the hello command, we now have access to the entire Discovery Service Set<\/em><\/a> of the server. No authentication or encryption mechanisms are required to use these services. Among these services, the one called GetEndpoints<\/em><\/a> can be used to retrieve the endpoints to connect to the server, as well as information about the configuration of these endpoints. This information is given through EndpointDescriptions<\/em><\/a> objects, which contain, among others:<\/p>\n
- \n
- The security level of the encryption accepted on the endpoint (None<\/em>, Sign<\/em> ou SignAndEncrypt<\/em>)<\/li>\n
- The signature or encryption algorithm used<\/li>\n
- The types of UserIdentityToken<\/em> accepted by the endpoint (AnonymousIdentityToken<\/em>, UserNameIdentityToken<\/em>, X509IdentityToken<\/em> or IssuedIdentityToken<\/em>)<\/li>\n<\/ul>\n
The server_config command allows to retrieve the EndpointDescriptions<\/em> of all the servers detected via the hello command, and to identify among these servers those that accept anonymous authentication or the None<\/em> security level. All this information is accessible for a non-authenticated user.<\/p>\n
In addition, if an authenticated access to a server is possible, the command also allows to browse the nodes of the server and identify the rights that the current user has on these nodes. For example, it is possible to obtain a list of nodes of type Variable<\/em> that can be written to, or a list of methods that can be executed by the user.<\/p>\n
Finally, other useful options have been added to the server_config command:<\/p>\n
- \n
- -o (or –output) allows to set up a JSON output file to store the results of the command and browse them more easily than on a terminal. Additional information is stored there, such as the value of the UserWriteMask<\/em> attribute of the nodes, which indicates which attributes of the nodes can be modified by the user.<\/li>\n
- -r (or –root_node) allows to browse only a subset of the server’s nodes from a starting node specified in the argument. Indeed, browsing all the nodes can be long and this option can be used to target the nodes of interest.<\/li>\n<\/ul>\n
The complete documentation of the server_config command and all its options is available here<\/a>.<\/p>\n
In practice, this is how the server_config command could be used:<\/p>\n
The output file of the hello command is given as an argument (via the -t option) and will be used to retrieve information about the endpoints of the detected servers::<\/p>\n
$ python opcua_scan.py server_config -t hello_output.json<\/pre>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image6.png\")
Example of results generated by the server_config command<\/em><\/p>\nHere, the server allows unencrypted and anonymous connections or authenticated with a username and password. If the server did not allow anonymous connections, the opcua_login script of msf-opcua could be used to try to find valid credentials, but this is not necessary in this example<\/p>\n
It is therefore possible to anonymously access the server, browse its nodes and search for interesting nodes (the beginning of the command result has been deliberately cut off, and the \u00ab\u00a0TemperatureControl\u00a0\u00bb directory has been targeted with the -r option to reduce the number of nodes browsed):<\/p>\n
$ python opcua_scan.py server_config -t hello_output.json -o config_output.json -nw -r \u2018ns=3;s=85\/0:Simulation\u2019<\/pre>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image7.png\")
Example of results obtained during a search for writeable nodes<\/em><\/p>\nWriteable nodes can then be further analysed in the output file that was configured in the previous command:<\/p>\n
![\"\"](\"https:\/\/www.riskinsight-wavestone.com\/wp-content\/uploads\/2023\/09\/Image8.png\")
Extract of an output file generated by the server_config command<\/em><\/p>\nHere, it seems possible for an anonymous user to remotely turn on or off an air conditioners via the detected OPC UA server<\/p>\n
\u00a0<\/p>\n
Conclusion<\/h1>\n
Despite the security mechanisms provided by the OPC UA standard, misconfigurations can easily occur and can impact the availability of industrial assets. The tool developed by Wavestone and presented in this article facilitates the audit of these configurations to better assess the security of Industrial Control Systems.<\/p>\n
Finally, the OPC UA specifications defines more security mechanisms, such as the management of certificates by a Global Discovery Server or the encryption of PubSub messages thanks to the implementation of a Security Key Server. The OPC UA standard could therefore enable further progress in terms of security, but few implementations of these mechanisms exist to this date.<\/p>\n\n\n\n
\n\n\n\nThe tool is available on Wavestone\u2019s Github account: https:\/\/github.com\/wavestone-cdt\/opcua-scan<\/a><\/p>\n\n\n\n
- -r (or –root_node) allows to browse only a subset of the server’s nodes from a starting node specified in the argument. Indeed, browsing all the nodes can be long and this option can be used to target the nodes of interest.<\/li>\n<\/ul>\n
- opcua_server_config<\/em>: this script requires an authenticated access to an OPC UA server to be used. It allows to retrieve information on the configuration of the server endpoints (encryption, authentication…)<\/li>\n
- UserNameIdentityToken<\/em><\/a>: this token contains a username and a password. If these are valid, the user is authenticated and then obtains the profile and rights associated with his username<\/li>\n
- Sign<\/em>: messages are signed. This protects the integrity of the transmitted data, but not their confidentiality<\/li>\n
- None<\/em>: messages are sent in clear text, without any protection<\/li>\n
![\"\"](\"https:\/\/opcconnect.opcfoundation.org\/wp-content\/uploads\/2021\/09\/OPC-UA-for-Field-in-FA-and-PA.jpg\")
\u00a0 \u00a0 \u00a0 \u00a0