Report and research by Kelly Leuschner.

WAGO makes several programmable automation controllers that are used in many industries including automotive, rail, power engineering, manufacturing and building management. Cisco Talos discovered 41 vulnerabilities in their PFC200 and PFC100 controllers. In accordance with our coordinated disclosure policy, Cisco Talos worked with WAGO to ensure that these issues were resolved and that a firmware update is available for affected customers.

Since a patch has been available to affected customers for some time, we wanted to take this opportunity to discuss several attack chains that exploit WAGO’s cloud connectivity client known as “dataagent” to gain root access to the device. You can also catch a technical presentation of these vulnerabilities at the virtual CS3Sthlm conference on Oct. 22, 2020.

WAGO provides a cloud connectivity feature for users to access remote telemetry from their devices and even issue firmware updates remotely. Cloud connectivity provides an interesting attack vector, where the attack originates from a trusted cloud provider but the cloud instance itself is attacker-controlled. The scenario we will dive into today is one where the attacker has access to legitimate cloud infrastructure and can abuse WAGO’s custom protocol to gain root privileges on the device.

We’ll first dive into the technical details of each of the vulnerabilities themselves. Then we’ll discuss how these vulnerabilities can be combined in two distinct attack chains that result in the ability to gain root privileges on the device.

Recon

Understanding the vulnerabilities

Firmware update command remote code execution (TALOS-2019-0954/CVE-2019-5161)

One of the features enabled by dataagent is the ability to update firmware on devices from the cloud. This feature immediately stood out to us, as it would involve multiple files and eventually execute system commands on the device to perform the update. Eventually, we discovered multiple vulnerabilities in the handling of the firmware update command of the dataagent service. This service handles communication with various cloud platforms that support the MQ Telemetry Transport (MQTT) protocol.

The firmware update functionality is designed such that the cloud application will send a JSON-encoded message via the MQTT protocol. Here’s an example of the command to begin a firmware update:

CommandId: 506

<cloud-supplied-value>

iot

DOWNLOAD_FIRMWARE

FirmwareControlFile

FirmwareControlFile

TargetPath

START

fwupdate_background_service

/tmp

Improper host validation (TALOS-2019-0953/CVE-2019-5160)

Now that we have found vulnerabilities in the firmware update command supported by dataagent, let’s see if there are any constraints regarding which cloud platform may send that command. The dataagent service can be configured to connect to multiple cloud infrastructure vendors including: WAGO Cloud, Microsoft Azure, IBM Cloud, Amazon Web Service and SAP IoT Services.

fwupdate_background_service script

WAGO Cloud

WAGO Cloud

WBM information exposure of admin credentials (TALOS-2019-0923/CVE-2019-5134 & TALOS-2019-0924/CVE-2019-5135)WBM admin credentials are needed to configure dataagent with an attacker-controlled hostname. The WBM users are isolated from the Linux system users as a security measure on the device. With two vulnerabilities in the PasswordCorrectfunction from login.php we could leak the hashed user credentials. Below is the PasswordCorrect function:

/etc/lighttpd/lighttpd-htpassword.user

iocheckCache.xml command injection and code execution(TALOS-2019-0961/CVE-2019-5166-TALOS-2019-0963/CVE-2019-5182)

/tmp

iocheckd 

xmlHostnameNodeValue

Exploitation

We’ll walk through two exploit chains, each executing commands from the cloud resulting in code execution in the root context on the device. The first will be using the firmware update preinstall hook, and the second will involve using the firmware update mechanism to place an iocheckCache.xml file on the device which will then be leveraged to gain command execution as the root user. These exploitation examples were performed on version 13 of the PFC 200 firmware which can be found here.

Connect to attacker-controlled cloud

crypt()

hashcat

T@l0s

Attack chain 1: Preinstall hook

Now that the device is configured to connect to our attacker-controlled cloud, we can exploit the firmware update preinstall hook vulnerability (TALOS-2019-0954) to execute OS commands as the root user. To exploit this vulnerability, the attacker must create two files: the XML control file and a shell script that will run as root on the system. These two files must be hosted on a server that the device can download via curl. For this example, we will host the files on a Microsoft Azure storage account. Here’s the contents of the XML control file:

rauc

telnetd

Microsoft provides a helpful extension to Visual Studio Code which allows users to monitor messages from IoT devices. When connecting to Azure IoT Hub for the first time, the device sends these two messages indicating the protocol versions the device supports:

CloudHello

Attack chain 2: IocheckCache.xml

/tmp

iocheckCache

telnetd

iocheckd

Conclusion

This post highlighted an interesting attack vector, using attacker-controlled cloud infrastructure to impersonate a vendor cloud application. Although Azure IoT Hub does provide encryption and authentication, WAGO did not implement additional validation of the cloud application itself. Cloud connectivity is increasing in Industrial applications and manufacturers should keep in mind that data originating from the cloud should be treated as untrusted data. When chained together, these vulnerabilities provide an attacker with root remote access. An attacker could then use that access to disrupt any of the critical processes that the WAGO PFC handles.

Coverage

The following SNORTⓇ rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Snort Rules: 52023, 52131, 52237, 52238, 52407, 52408, 52412