Team82 Logo Claroty
Return to Blog

OPC UA Deep Dive Series (Part 8): Gaining Client-Side Remote Code Execution

/

This is part 8 of Team82’s OPC UA Deep Dive series. In this part, we showcase vulnerabilities we uncovered in preparation for Pwn2Own Miami 2023 in two popular OPC UA clients: Inductive Automation Ignition and Softing edgeAggregator. We were able to chain different vulnerabilities in order to remotely execute code on the OPC UA clients, giving us full control over the system. 

Executive Summary

  • Team82’s OPC UA Deep Dive series continues with an explanation of separate attacks targeting popular OPC UA clients: Inductive Automation Ignition and Softing edgeAggregator

  • We were able to chain different vulnerabilities in order to successfully exploit each client and gain full control over them. These vulnerabilities received the following identifiers: CVE-2023-27335, CVE-2023-38126 and CVE-2023-38125. In addition CVE-2023-38121 and CVE-2023-38124 which were co-disclosed by the researcher, 20urdjk.

  • These OPC UA clients are critical to industrial automation processes across many industries; engineers use them to build and deploy automation systems, collect and visualize data, and each client supports numerous OT protocols

  • Softing and Inductive Automation issued patches fixing these vulnerabilities, and users are advised to update their installation.

Hacking OPC UA Clients at Pwn2Own Miami 2023

In 2023 we participated in, and won, the ICS-themed Pwn2Own hacking competition in Miami, where we, alongside dozens of researchers, searched for vulnerabilities in a wide range of ICS- and SCADA-related software. In this competition, for the first time, a new type of target was introduced: OPC UA clients. This new target category intrigued us because it exposed a new set of attack vectors we could exploit.

Throughout our Pwn2Own ICS 2023 research, we found dozens of different bugs and vulnerabilities in nine applications that were part of the competition, two of which were OPC UA clients where we managed to achieve remote code execution. We won the overall competition, gaining the title of Master Of Pwn, with 98.5 PWN points and $98,500 USD in prize money.

The final standings for Pwn2Own Miami 2023.

In this blog, we’ll showcase our approach to researching and exploiting OPC UA client applications, where we combined classic OPC UA and OT knowledge with run-of-the-mill web vulnerabilities—combining “old” and “new” attack vectors—to uncover zero days in both clients. During our Pwn2Own research journey, we managed to find similar vulnerable code patterns in both applications, exploiting the OPC UA client’s trust in the data it receives from the OPC UA server.

In the end, we exploited Inductive Automation Ignition and Softing edgeAggregator in a similar manner: exploit in both a cross-site scripting (XSS) vulnerability stemming from improper sanitization of data coming from the OPC UA protocol. Then, we abused the XSS vulnerability to perform actions on behalf of the user, leveraging this primitive into code execution. Let’s take a look at these vulnerabilities, and how we chose to exploit them.

Exploiting Inductive Automation Ignition to Gain RCE

Inductive Automation’s Ignition is a software platform for industrial automation and control. It is designed to be used in a variety of industrial environments, including manufacturing, oil and gas, and water. It features a comprehensive set of tools for building and deploying industrial automation systems, including a visual programming interface, real-time data collection and visualization, and support for a wide range of industrial protocols. Ignition is also designed to be highly scalable, with support for large numbers of devices and tags, and can be used to control and monitor a wide range of industrial equipment, including PLCs, HMIs, and IoT devices.

Inductive Automation’s Ignition dashboard.

From XSS to RCE

When exploring the attack surface of the Ignition OPC UA client, we noticed that it had three main capabilities when interacting with OPC UA tags: read, write and subscribe.

The UI for the OPC UA Client in Ignition, allowing the users to read (r), write (w) or subscribe (s) to tags.

When choosing read, the Ignition Gateway queries the OPC UA Server about the value of the chosen tag, and presents it to the user in the web UI.

The UI for read OPC UA tags

We discovered the Ignition Gateway does not sanitize the return tag value, nor does it insert it into the HTML document object model (DOM) securely, which opens the path to an XSS attack. This vulnerability is now labeled CVE-2023-38121.

A malicious tag read from an OPC UA Server, resulting in the attacker being able to execute arbitrary javascript code in the target browser.

Since this vulnerability enables attackers to execute arbitrary JavaScript code in the target browser, it enables the attacker to perform any actions they choose, using the target’s cookie and permissions.

When we moved to exploit this vulnerability, we discovered that we were limited in our exploitation options. For example, we could not exfiltrate the admin session directly because Ignition uses the HTTP Only directive, blocking JavaScript code from touching the cookie. Similarly, we could not supply arbitrary characters/sizes in our payload, because we were limited in that regard as well.

The Ignition web server, disallowing Javascript code to interact with the user’s cookie.

In order to bypass said limitations, we chose to perform the entire exploit chain inside the victim’s browser, using their session token. To do so, we chose to load a malicious JavaScript file from our own server using our XSS vulnerability, executing it directly from our server. 

Our malicious OPC UA tag value, with an XSS payload loading an external script from our server.

Luckily for us, even though Inductive Automation applied the HTTP Only header to the cookie, it did not use a strong content-security policy (CSP) policy, meaning we could load an external JavaScript file from unauthorized locations.

In order to block attacks like this, it is important to add a CSP header that protects the website from many XSS attacks, disallowing attackers from loading JavaScripts scripts from unauthorized sources. Using this header, it is possible for developers to allow only execution of JavaScript from the local server or a list of whitelisted servers.

The returned security headers of Ignition Gateway, lacking a CSP header.


After we gained an administrator session, we needed to be able to execute arbitrary code on the Ignition Gateway server. In order to do so, we chose to abuse a functionality of projects: the ability to schedule tasks on some events. 

This functionality allows users to invoke some Jython scripts whenever a certain event occurs, such as a project startup, shutdown, or after a certain time. However, we discovered that this functionality allows for the execution of arbitrary OS commands whenever a project is imported, resulting in us being able to achieve RCE on the Ignition server. This vulnerability received the following label: CVE-2023-38124.

The Gateway Events functionality, allowing users to configure callbacks for certain events.

Our script allowed us to execute arbitrary commands.

Our malicious payload being executed, in this case - MSPaint being executed.

We then chained these vulnerabilities, leveraging our XSS vulnerability into full-fledged remote code execution, below.

Targeting Softing edgeAggregator Client for RCE

Softing edgeAggregator is an industrial data management platform designed to integrate, process, and visualize large amounts of industrial data from various sources. It allows users to centralize, store, and analyze industrial data to gain insights and make informed decisions. EdgeAggregator provides a unified interface for data collection and management, reducing the complexity of integrating and processing data from different sources.

Softing edgeAggregator architecture.

From XSS to RCE, Again..

In Softing edgeAgraggator, before fully configuring an OPC UA Server for the client connection, users are allowed to test the connection to the configured server and view its basic information.

The “Test Connection” screen, allowing users to test a connection to a server before fully configuring it.

As shown in the screenshot above, the Softing edgeAggregator client shows basic information about the OPC UA Server, such as the server’s manufacturer name, product name, etc. These fields come from the OPC UA Server, and are then inserted into the HTML of the edgeAggregator client.

We discovered that by supplying malicious values, an OPC UA server can perform an XSS attack on the client, allowing the attacker to execute arbitrary JavaScript in the context of the user’s permissions. By simply supplying JavaScript code inside a <script> tag, we are able to execute arbitrary Javascript code (CVE-2023-27335).

A malicious manufacturer name value OPC UA Server, resulting in the attacker being able to execute arbitrary javascript code in the target browser.

Since this vulnerability enables attackers to execute arbitrary JavaScript code in the target browser, it enables the attacker to perform any action they choose, using the target’s cookie sessions, and gaining their permissions.

After gaining the ability to perform arbitrary actions on behalf of the administrator, we moved on to leverage this ability into gaining remote code execution. To do so, we took a look at the backup and restore functionality of the platform.

Softing allows users to upload a backup file to restore a server’s configuration. Behind the scenes, the backup file is actually a .zip file containing the old configuration. As part of the backup procedure, the Softing edgeAggregator server tries to unzip the backup in order to process it. However, we discovered that Softing unzips the backup file in an insecure manner, which could result in a path-traversal attack (a zip slip vulnerability).

Zip files contain multiple files, each with a unique name that tells the unzipping process how it should name the extracted file, and where it should extract it to. This enables users to zip entire directories, and keep the directory structure during the extraction process. This is done by each entry inside the zip file having a name and path.

A listing of files inside a zip file, showcasing how each file has a name containing the path of the file.

However, it is possible for users to supply path-traversal characters (../) as part of a file’s path, which could result in the file being written outside the intended directory. If the extraction process simply takes a file’s name and path, and does not sanitize it to remove path traversal characters, it could result in the file being written in arbitrary locations (CVE-2023-38126).

We discovered that in the backup routine of the Softing server, the server does not sanitize path-traversal characters, which results in attackers being able to write arbitrary files in arbitrary locations. We were able to leverage this primitive in order to write a malicious Shared Object (SO) file into the Linux library path. 

After going over all of the shared objects loaded by the server during runtime, we discovered that when a user restores a configuration, libacl.so.1 is loaded. The path that libacl is loaded from  is /lib/x86_64-linux-gnu. Using the directory traversal vulnerability we are able to overwrite that file. In our weaponized configuration, we added a custom built libacl.so.1 that will perform everything that the original library does but will instead execute our code when it is loaded.

Our malicious SO file, allowing us to execute arbitrary code when the SO file is loaded.

Then by performing a configuration restore, we are able to both write our weaponized SO and load it, resulting in arbitrary remote code execution.

In order to demonstrate how the vulnerabilities we showcased above could be chained together in order to achieve unauthenticated remote code execution, we created a PoC exploiting them.

Our exploit chain is as follows:

  1. A user clicks on a test connection button and triggers our XSS exploit

  2. We load a malicious Javascript file from our server that will perform a backup restore 

  3. During the backup restore, we exploit the zip slip vulnerability, allowing us to write a load a malicious SO file 

  4. We achieve arbitrary remote code execution on the Softing EdgeAggregator server. In order to demonstrate it, we write a HTML file under the web root directory (/<webroot>/ClarotyPOC.html), showing the output of multiple OS commands we execute.

Key Takeaways

The introduction of OPC UA clients as a new category for this year’s Pwn2Own ICS hacking competition in Miami prompted us to research these critical industrial automation platforms. We used a combination of our extensive OT experience and a handful of commodity web vulnerabilities to successfully exploit popular clients, Inductive Automation Ignition and Softing edgeAggregator.

Our exploit chains garnered us full control over each client, including dangerous remote code execution capabilities. 

In each case, we were able to exploit cross-site scripting vulnerabilities and use malicious JavaScript code to successfully access each client in the context of the user. From there, we uncovered other vulnerabilities that enabled us to remote execute code. 

Both vendors addressed the vulnerabilities disclosed by Team82 and you can find patching and mitigation information here for Inductive Automation and Softing

More from the OPC UA Deep Dive Series

OPC UA Deep Dive (Part 1): History of the OPC UA Protocol
OPC UA Deep Dive (Part 2): What is OPC UA?
OPC UA Deep Dive (Part 3): Exploring the OPC UA Protocol
OPC UA Deep Dive Series (Part 4): Targeting Core OPC UA Components
OPC UA Deep Dive Series (Part 5): Inside Team82’s Research Methodology

OPC UA Deep Dive Series (Part 6): A One-of-a-Kind Exploit Framework
OPC UA Deep Dive Series (Part 7): Practical Denial of Service Attacks

Stay in the know Get the Team82 Newsletter
Related Vulnerability Disclosures
Claroty
LinkedIn Twitter YouTube Facebook