Written By the Claroty research team (Team82).
Claroty’s Team82 has uncovered and disclosed multiple vulnerabilities in Dataprobe’s iBoot-PDU, the company’s intelligent power distribution unit product.
iBoot-PDU can be managed from any location via a web-based interface; devices that are not directly connected to the internet can also be managed via Dataprobe’s cloud-based platform.
Some of the vulnerabilities uncovered by Team82 can lead to unauthenticated remote code execution on the iBoot-PDU.
Team82 has also developed a means by which it can enumerate cloud-connected iBoot-PDU devices, expanding the available attack surface to all connected devices.
An attacker would be able to remotely exploit these vulnerabilities either through a direct web connection to the device or via the cloud.
This research is an extension of Team82’s previous work exploiting cloud-based OT devices. Read “Top-Down, Bottom-Up: Exploiting Vulnerabilities in the OT-Cloud Era” here.
Dataprobe has addressed these vulnerabilities in a new version update. Users are urged to update to Version 1.42.06162022. Dataprobe also recommends users disable SNMP, telnet, and HTTP, if not in use, as a mitigation against some of these vulnerabilities.
ICS-CERT has issued an advisory as well. Find it here.
Introduction
Power distribution units (PDUs) are common devices found in industrial environments, data centers, and elsewhere where power supplies must be in proximity of rack-mounted equipment. Some PDUs can be accessed and managed remotely.
Attacking a remotely exploitable vulnerability in a PDU component such as the web-based interface or cloud-based management platform puts an attacker within arm’s length of disrupting critical services by cutting off electric power to the device and subsequently, anything plugged into it.
Team82 recently concluded research into Dataprobe iBoot-PDUs, an advanced device that provides users with real-time monitoring capabilities and remote access. A 2021 Censys report revealed that more than 2,000 PDUs are exposed to the internet, with 31% of those being Dataprobe devices.
That report prompted us to examine the security of Dataprobe iBoot-PDUs and determine whether we could remotely access the device, bypassing authentication requirements, and gaining code execution. We also wanted to reach iBoot-PDUs that were not directly connected to the internet, but instead were managed by an integrated cloud platform.
Team82 was able to uncover seven vulnerabilities, all of which were disclosed to Dataprobe, which patched them in a recent update. Users are urged to implement these fixes. Dataprobe also recommends users disable SNMP, telnet, and HTTP, if not in use, as a mitigation against some of these vulnerabilities.
This research builds on previous work done by Team82 on the security of cloud-based management platforms. In July 2021, Team82 published a report called “Top-Down and Bottom-Up: Exploiting Vulnerabilities in the OT Cloud Era.”
That report featured research that uncovered vulnerabilities in market-leading WAGO PLCs that could enable an attacker to target a cloud-based management system, as well as flaws in CODESYS’ Automation Server platform used to manage industrial devices from the cloud. The flaws Team82 disclosed were remotely exploitable and could be used to target a cloud-based management console from a compromised field device, or take over a company’s cloud and attack PLCs and other devices to disrupt operations.
Inside the iBoot-PDU
iBoot-PDU is a switched and managed power distribution unit (PDU), and through it, users may independently and remotely control outlets using a built-in web interface, or over protocols such as telnet and SNMP.
The device runs on an ARM-based processor, the Linux operating system, and uses lighttpd as its web server. The webroot is located at /var/iBB2-WebPages and the main web logic is written in PHP.
Some of the main binaries that operate the device are:
- Ibootbar2d: Responsible for the cloud connection and SNMP handling
- dxpd: A daemon responsible for Dataprobe’s proprietary DxP protocol
- discoveryd: A discovery protocol implementation
- libdbconfig.so: main logic implemented for all database actions
iBoot-PDU also offers the iBoot Cloud Service, which is a portal that can be used for device control through the cloud without exposing the device to the internet.
Exposure of iBoot-PDU Devices
Censys, developers of the popular Censys scanner and platform used to identify devices that are reachable over the internet, published a report in July 2021 that identified 2,617 devices used to remotely manage and monitor electric sockets.
About 31% of those were Dataprobe devices; that percentage does not include devices that are connected only via the cloud.
The results of the Censys report prompted us to better understand the available attack surface for cloud-connected power distribution units, and how attackers would potentially remotely exploit such devices.
After analyzing the attack surface, we started our research with a few goals:
- Execute code on internet-connected devices through either:
- Authentication bypass
- Pre-auth code execution
- Reach devices that are not publicly facing using the iBoot Cloud Service while bypassing network address translation (NAT) and firewalls to infiltrate organizations through the smart connectivity channel in order to:
-
- Execute code on cloud-connected devices
- Obtain cloud credentials in order to move laterally through the network
Code Execution on Internet-Connected Devices
The Censys report revealed SNMP (UDP 161) and HTTP (TCP 80/443) as the two most exposed ports; since SNMP was less common, we started with the HTTP web server. iBoot-PDU’s web server is commonly exposed to the internet, and is the common interface to manage iBoot-PDUs.
Using the web interface, users can configure the PDU, view device details, and control the electric outlets on the device. Every time users click the virtual on/off buttons for an outlet, an electrical relay opens or closes the circuit to that specific outlet.
Pre-auth RCE: git-update.php (CWE-123)
The first step we take when researching web servers is mapping all accessible pages and the authentication required to access them while focusing on the pre-auth routes. In this case, we had the device firmware, therefore we used it to extract all of the file names that are in the web directory in order to map out all of the possible routes. After a bit of searching we came across an old, unused PHP page that is still accessible on the server without any authentication required:
iBB2-WebPages/php/git-update.php
We assume that this page was used internally for testing different firmware on devices and is not in use for some time. The most important thing is that anyone can interact with this route because it doesn’t check for authentication headers.
The script above downloads all of the main firmware’s php web pages from a private git repository and replaces the old web pages with the files downloaded from the git repository. The git-update.php page receives two parameters via HTTP POST:
branch
token
The first thing the script does is to verify both parameters are not empty, meaning we have to include both in our HTTP post.
After checking the parameters are not empty, they are formatted into a github url:
The script then downloads the github repository as a zip file, extracts it, and replaces the webroot directory of the device with the content of the downloaded zip. Since we don’t have a valid access token for the github repository and we don’t have any control over the repository itself, this seemed like a dead end. Looking at the script for a while, we finally had an idea: both the token and branch parameters sent in our POST request are not sanitized. This means we have full control over these parameters.
If we manage to change the files downloaded to the device and write our own php files, we would essentially get remote code execution on the device. The easiest payload we can use is a small php webshell.
We still have a few obstacles before we can successfully execute code using this page. In order to control the content downloaded to the device we need to:
- Control the requested github repository (URL) downloaded to the device
- Use a repository that we can control and know the access key
The first task is simple, set the branch parameter to:
../../../<repo-user>/<repo>/zipball
This allows us to fully control the repository that will be downloaded. When resolving the URL, each “../” will go one directory up the URL. This means the final URL will start at https://api.github.com/repos/. This gives us a fresh start to build our own URL pointing to any repository we want.
Unfortunately when we tried to set set an arbitrary <repo-user> with a valid access token, we came across the following error:
An error message returned by github when using access_token.
It turns out that sending tokens as URL parameters to github has been deprecated for a while, and that’s why we assume this script is no longer in use.
We mentioned earlier that both the branch and token parameters cannot be empty, but any request made to github with an access token returns an error. Before we try to think of a solution, let’s take a quick look at how URL parameters are formatted. The token parameter that we send using HTTP POST is formatted into the url parameter “access_token.”
URL parameters are structured this way:
uri?param1=val1¶m2=val2
- ?: beginning of url parameters
- param1=val: first parameter key=value
- &: beginning of a new parameter
- param2=val2: second parameter key=value
Parameters sent in an HTTP POST are not URL-encoded, meaning we can send %26 (encoded &) as a post parameter. This will pass the check that the parameter is not empty and will be formatted into the github URL.
Since & starts a new parameter—thus ending the previous one—if we use & as the value of the access_token parameter, github will assume that the parameter has no value and ignore the token.
Therefore, the final payload to trigger this vulnerability would be:
And the URL will look like this:
And the final URL will be resolved and handled as:
If we use any public repository that contains a php webshell, this will result with a webshell for the attack:
Even though we already found a pre-auth remote code execution on the device, we decided to continue going over the accessible web pages list we constructed earlier and found two more vulnerabilities.
What About Devices Not Exposed to the Internet? Moving to the Cloud
Not all iBoot-PDUs connected to the internet are publicly facing. Many devices are behind NAT routers and firewalls. In the past, users had to choose between:
- Exposing devices to the internet in order to control them remotely with greater risk of attacks on the devices
- Keeping devices local without the ability to control them from outside the network
Modern solutions implemented a constant session for the edge device to a cloud-based platform in which users can remotely control through a central location: the cloud platform.
Cloud Web Pages Enumeration
Dataprobe’s iBoot Cloud Service platform can directly control outlets and also has a feature to access the device’s main management page from the cloud. This feature enables users to remotely connect to their device without exposing it to the internet.
The iBoot-PDU cloud management interface.
Every time users connect to a device over the cloud a unique URL is created. For example:
https://c1b2c3d4.device.iboot.co
- The first 8 characters of the address are random making it unlikely to brute force
How are these URLs generated? To access the device web server via the cloud, an HTTP request is made to iboot.co/toDevice.php?device=<device_id> The response contains the URL (ex https://c1b2c3d4.device.iboot.co) that mirrors the web page of the device (specified by deviceid). It’s important to note that deviceid is a simple sequential numeric ID that can be easily guessed (1, 2, 3 ..).
In order to call the toDevice URI, we also need a valid cookie.
Cloud Cookie
Every time users connect to the iBoot-PDU cloud using valid credentials they get a cookie that is used for further actions. The cookie used for the toDevice URI has to be a real valid cookie in order for the server to respond with the device URL. However, we discovered that the cookie does not have to be linked to any device meaning one user can use their own cookie to query other devices connected to the cloud.
Device ID
Cloud device ID is a sequential identifier that is incremented every time a device is registered to the cloud.
The fact that the device ID is not random and we can query any device using a valid cloud cookie means we can request the web page for every device connected to the cloud.
This exposes all cloud connected devices to the HTTP-based attacks described in this report.
PWNing All the Devices
We now have the ability to expose all the cloud-controlled iBoot-PDU devices and exploit them remotely through their web interface while bypassing NAT, routers, and firewalls. An attacker gaining such an ability would probably start to exploit the internal network because that’s where they would have an initial foothold.
We were pondering what else is possible from an attacker’s perspective. What about controlling the physical socket outlets? Having the ability to remotely shut down power on devices within the internal network would leverage the virtual network world to impact the physical one. This is scary.
iBoot-PDUs use relays in order to control outlets. A relay is a physical electric switch controlled by a signal. Putting it in simple terms, relays receive a signal and open/close a circuit according to the signal.
The image below shows an example of how iBoot-PDUs signal using general purpose IOs (GPIO) in order to open/close the circuit connected to the power outlet on the device and therefore control which devices receive power.
The exploit chain used to open or close and electric relay.
Conclusion
Team82’s disclosure of seven vulnerabilities in Dataprobe’s iBoot-PDU illustrates the need to assess the risk posed by all connected devices within an enterprise. Even an innocuous power distribution unit remotely managed over the internet or via a cloud-based management platform can provide a determined attacker to target the network, or with a way to disrupt essential services by cutting power to devices plugged into a PDU.
This report demonstrates how an attacker can enumerate connected PDUs through a simple CENSYS search in order to understand the available attack surface. The vulnerabilities eventually uncovered by Team82 and patched by Dataprobe allowed for authentication bypass and pre-authentication code execution on internet-connected devices. For cloud-managed PDUs, Team82 was able to reach those devices by exploiting access control flaws in order to bypass network address translation and firewall protections. Doing so enables an attacker to execute code on cloud-connected PDUs, or obtain cloud credentials to move laterally on the network.
Successful exploits could allow attackers to shut down servers and other networking equipment housed in data centers that are normally adequately powered by a PDU.
The Vulnerabilities
CWE-78: OS Command Injection
CVSS v3 score: 9.8
A specific function does not sanitize the input provided by the user, which may expose the affected an OS command injection vulnerability.
CWE-22: Path Traversal
CVSS v3 score: 9.8
The device’s existing firmware allows unauthenticated users to access an old PHP page vulnerable to directory traversal, which may allow a user to write a file to the webroot directory.
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
CVSS v3 score: 5.3
The affected product exposes sensitive data concerning the device.
CWE-284 Improper Access Control
CVSS v3 score: 8.6
The affected product allows an attacker to access the device’s main management page from the cloud. This feature enables users to remotely connect devices, however, the current implementation permits users to access other device’s information.
CWE-285: Improper Authorization
CVSS v3 score: 5.3
Certain PHP pages only validate when a valid connection is established with the database. However, these PHP pages do not verify the validity of a user. Attackers could leverage this lack of verification to read the state of outlets.
CWE-286: Incorrect Authorization
CVSS v3 score: 5.3
Unauthenticated users could open PHP index pages without authentication and download the history file from the device; the history file includes the latest actions completed by specific users.
CWE-918: Server-Side Request Forgery
CVSS v3 score: 5.3
A specially crafted PHP script could use parameters from a HTTP request to create a URL capable of changing the host parameter. The changed host parameter in the HTTP could point to another host that will send a request to the host or IP specified in the changed host parameter.
