Reversing Custom Protocols in IoT for Fun and CVEs

ISE Labs explores the Drobo 5N2

IoT devices often present unique and unexpected challenges for hackers to overcome. In this blog, we provide an in-depth walkthrough of how we broke custom solutions and built exploits to remotely control the targeted device as a root user. The challenge involves reverse engineering a proprietary protocol used to issue commands and receive data to and from the Drobo NAS 5N2. The blog covers the process of identifying and exploiting CVE-2018–14708, CVE-2018–14709, and CVE-2018–14701.

When we first got the Drobo we thought that it was going to serve a web application like most off-the-shelf Network Attached Storage devices. However, after we tried going to its IP address in a browser we found out that there was no such web app. That led to us running Nmap against it which helped us determine that the only open ports were the ones listed below.

nmap -T4 -A -v -p 1–65535 192.168.1.26

We circled back, read the manual, and found out that the only way to interact with the Drobo 5N2 out-of-the-box was to use the Drobo desktop client. (Maybe next time we will read the manual first.) Next, we will need to install the desktop client and figure out a way to view the traffic between the client and NAS. Traditionally, we have our browser use an HTTP proxy like BurpSuite, but because we don’t know what protocol is being used we are going to use a packet analyzer like Wireshark instead. Capturing and analyzing the traffic between the client and our Drobo will help us figure out what we are working with. Before we start capturing any traffic, I am going to use a filter so that we only capture traffic from the Drobo NAS to reduce the amount of noise captured by Wireshark.

When we start the client, we see that a lot of traffic is sent to our device. While the traffic is being recorded, we will perform a couple actions to have different requests to work with. After capturing the traffic, we will close the application and save the capture. Looking at the capture there appears to be only two ports that are used: port 5000 and port 5001. This looks like what we saw before when we ran NMAP on the device. A closer look at the network traffic reveals that the protocol used by Drobo is XML based as illustrated in the image below. However, as you can tell, there are a lot of details we need to figure out.

When it comes to reverse engineering protocols, we are going to need to understand the importance of the bytes in each request to fully understand how the protocol works. A couple things worth noting:

(1) The user needs to be connected to the Drobo over port 5000. When testing our device, we connected to the Drobo using netcat (nc <ip address of Drobo> <port>).

(2) When we connect to the device on port 5000, the response included in the gist below is returned. (This is an unauthenticated request.)

Analysis of our packet capture reveals that another connection is started on port 5001. This is the XML traffic that we saw before. Each request contains a “CmdID” which is a numeric value that appears to identify the request. The request below returns the “temperature” and the “uptime” of our Drobo.

In theory, that means if we send the same request again, the Drobo ought to return the same response. After copying the raw bytes from that request, we create a python script to test this theory out. The gist below is what we ended up with. The header of the script contains what we know about the protocol so far.

However, after running our script we do not get anything back. Digging through the Wireshark traffic we did not see anything missing. However, after recording our network traffic from the point of launching the Drobo client we were able to determine that there was a request sent at the very beginning that we had missed before. This request only happens once when the client is launched, which would explain why we were unable to find it during our initial analysis. The GitHub gist below contains that request in hex, and the request we used to view the device’s temperature.

Great! It works. Now for something more visual. One of the more interesting functionalities on the device involves turning on the lights on the front of the Drobo, or as my co-worker, Ian Sindermann, likes to call it, party mode. Let’s see if we can get that working.

Here is a gif of us enabling party mode on our Drobo remotely without any authentication.

Last, something dangerous. The following gist will allow you to enable apps on the Drobo. During our research we found that these applications were riddled with vulnerabilities (there is going to be a separate blog post for these soon.)

I know that most of you came here to see a shell. Here is a URL that exploits one of the vulnerabilities we identified in the DroboAccess web application. You should be able to figure out the rest :)

http://192.168.1.26:8080/DroboAccess/delete_user?username=test';/bin/touch%20test_ise2'

Conclusion

Methods used when reverse engineering custom protocols are not all that different from the methods used when reverse engineering any other service. It boils down to breaking the targeted service down into smaller digestible pieces. In addition, we illustrate that making use of a custom protocol does not mean that you do not need encryption or a proper authentication system.