FROM PROJECT FILE TO CODE EXECUTION: EXPLOITING VULNERABILITIES IN XINJE PLC PROGRAM TOOL

Executive Summary

• Team82 has uncovered two vulnerabilities in XINJE’s PLC Program Tool, an engineering workstation.
• Version 3.5.1 is affected, and likely other versions.
• Team82 began disclosure efforts in August 2020. More than a year later, XINJE acknowledged our disclosure in September 2021.
• XINJE at that time refused to cooperate with Team82 and asked us to stop communication with them.
• We extended the terms of our coordinated disclosure policy beyond 90 days to nine months before disclosing limited details today to help asset owners prioritize any mitigations.
• An attacker may use a crafted project file to trigger these vulnerabilities.
• Arbitrary project files may be written to a project file to gain code execution.

Engineering workstations are among the most critical operational technology (OT) assets. Engineers use these platforms to configure and maintain control system applications and devices at lower levels of the Purdue Model for industrial control systems. A threat actor who can access and use an engineering workstation as an attack vector is in position to disrupt industrial processes and cause damage that could put public safety at risk or interrupt the delivery of critical services.

Team82’s latest research is an examination of engineering workstation applications sold by XINJE, a Chinese automation company. We uncovered two vulnerabilities in the XINJE PLC Program Tool (CVE-2021-34605 and CVE-2021-34606) in v3.5.1. Team82 tested only v3.5., we believe other versions may be vulnerable too.

These flaws can be triggered by a crafted project file. An attacker can use these vulnerabilities to write arbitrary project files to a PLC and gain code execution.

Team82 is disclosing limited information today about these vulnerabilities, details of which were privately disclosed at the end of August 2021 after a year of attempting to connect with representatives of the company. The vendor was not receptive to our attempts to share technical information and collaborate on a fix and response. Finally, on Sept. 8, 2021, XINJE representatives asked that Team82 stop communication. Team82 extended the terms of its coordinated disclosure policy beyond 90 days to nine months before disclosing limited details today to help asset owners prioritize any mitigations.

Engineering Workstation Programs

XINJE’s PLC Program Tool is an engineering workstation program, used in OT environments to communicate with XINJE-produced PLCs. These devices, according to XINJE, are sold not only in China, but also in Europe, North America, Southeast Asia, and elsewhere in a number of markets, including energy, manufacturing, and engineering.

From a security perspective, gaining access to a machine containing the engineering workstation program can allow an attacker to fully meddle with PLCs and other highly sensitive OT equipment with adverse consequences. Therefore, exploiting vulnerabilities in these applications can be used by attackers as a final step toward taking full control of an OT network.

An attacker targeting an engineering workstation could infect lower-level devices such as PLCs, sensors, or pumps.

Malicious Project Files at Heart of a Class of Vulnerabilities

Team82 has taken a special interest in a class of vulnerabilities that involve project files.

Project files are usually archive file formats that contain OLE files, SQLite databases, proprietary binary formats, text files, and directories created within engineering workstations. These programs are used by engineers to monitor, configure, and communicate with programmable logic controllers (PLCs) and other control systems.

The program logic contained in a project file governs ICS devices and oversees processes, and it also may include network configuration data and—at times—a complete OT network layout. For attackers targeting industrial networks—and many of late have been state actors—weaponized project files would likely be central to such a campaign.

When a project file is opened with an engineering station program, the program can quickly communicate with the relevant equipment. Alternatively, the OT engineer can sometimes upload the project file from a PLC, but this requires either running a network discovery tool to find the PLC’s network address (a procedure not supported by all PLCs) or manually entering the relevant network parameters. As a result, many companies opt to use project files, each including the configuration for one or more PLCs.

Vulnerabilities can be triggered by specially crafted project files composed by an attacker when opened by the engineering station program. In this scenario, an attacker could, for example,  replace a legitimate file in a network share used to store the files with a crafted file that would  trigger a vulnerability in the program. We discovered such vulnerabilities in the XINJE PLC Program Tool, which can allow an attacker to run arbitrary code on a vulnerable endpoint upon opening an exploited project file.

Research Environment Setup a Crucial First Step

As part of our work, we often receive requests to research proprietary protocols in order to maximize our customers’ ability to observe the traffic in their network. At times we have to support older equipment still used in critical roles in production sites, and at other times we even stumble onto equipment manufactured by smaller OT vendors.

The request we received from a customer to analyze protocols used by equipment manufactured by XINJE fell into the latter category.

Our  first step was to create a lab setup; this usually requires purchasing equipment and connecting it to the relevant engineering workstation program. In some cases, even purchasing the equipment can be difficult because the vendor might no longer offer the exact models we need.

What we discovered over time is that a surprisingly wide range of OT equipment can be purchased through eBay. In many cases, once a factory changes its OT equipment, the older, used equipment winds up on eBay and can be purchased easily and shipped to your doorstep.  Equipment offered by XINJE was no exception, and a variety of XINJE products can be purchased through eBay:

Ebay listings for XINJE industrial equipment. 

Once we purchased a PLC, the next step was to install it in our lab, along with a multitude of other OT equipment, and connect it to the engineering workstation program used to configure it.

A XINJE PLC running in a lab setup. 

Chaining Two Vulnerabilities to Load a Malicious File

Once we’ve constructed a suitable setup and finished researching the different protocols used by the equipment, we’re often asked by our customers to look for security issues with the setup.

Pointing out these issues can help users improve their security posture immediately. Responsibly reporting these vulnerabilities to the vendor, can help fix them and improve security across the entire OT space.

In XINJE’s case, we decided to focus on the engineering workstation program called XINJE PLC Program Tool. As mentioned earlier, in such cases project file vulnerabilities are of particular interest. Usually, searching for project file vulnerabilities begins with investigating the structure of the project file used by the engineering workstation program. In the case of XINJE PLC Program Tool, the relevant files are *.xdp files:

XINJE PLC project file structures are .xdp files. 

These project files can be easily identified as zip files, as indicated by the PK\x03\x04 magic, below:

And they can be extracted by almost any archive utility (e.g. 7z). What’s even more interesting, is that when the the program opens a project file, it immediately extracts it to a temporary directory located within its installation directory:

XDPPro.exe writes several files to C:\Program Files\XINJE\XDPPro\tmp

This behavior indicates that the program assumes it’s being executed with administrator privileges. This, in combination with the extracted file being a zip file, immediately makes one wonder whether a zip slip vulnerability (an arbitrary file-overwrite vulnerability) can be leveraged to obtain arbitrary write privileges.

Soon enough we did find a zip slip vulnerability (CVE-2021-34605), which can provide an attacker with arbitrary write privileges with the permissions of the program; in most cases these will be administrator privileges.

The next question is how to reach code execution from an arbitrary file write. Since it makes the most sense for the code to be executed right after the project file is loaded, we can check what the program is doing while opening the project file:

XDPPro.exe attempts to load DNSAPI.dll from C:\Program Files\XINJE\XDPPro, doesn’t find it and falls back to C:\Windows\System32

Interestingly, it’s trying to load .dll files from its local directory with LoadLibrary. When LoadLibrary doesn’t find them, it reverts to searching for them in C:\Windows\System32. Here is where we found our second vulnerability, CVE-2021-34606, a classic DLL hijacking vulnerability.

In order to create a fully-working exploit, we chained our two vulnerabilities:
Once a specially crafted malicious project file is opened by XINJE PLC Program Tool, the zip slip vulnerability will be triggered and a .dll file will be written to the program’s directory in Program Files. Later in the process of loading a new project, this DLL will be loaded instead of the real DLL (located in Windows\System32).

Once the DLL is loaded, malicious code is executed during its DLLMain procedure or in one of the functions imported by the program. An attacker now may gain a foothold on an OT network.

A demonstration of Team82’s proof-of-concept exploit. 

Wrapping Up

Despite the fact that awareness of cybersecurity has been steadily increasing in recent years in the OT world, many engineering workstation programs are still vulnerable to easily exploitable vulnerabilities.

Not all vendors are aware of the fact that project files can be weaponized by attackers as a method to take control of critical OT resources; this is true for most OT personnel as well.

In addition, many vendors still do not have well-defined interfaces for coordinated disclosure of vulnerabilities. As a result, disclosure can take an unnecessarily long time, often passing through sales and/or technical support teams without security knowledge, before reaching the teams responsible for the development of the affected products.

This was a challenging disclosure with XINJE, which thankfully is not the norm within the majority of OT vendors.