This is going to be another analysis over the livestream event done by the Independent Security Evaluators (ISE). ISE does fantastic research, particularly in the IoT space. A few of research cases include a campaign called SOHOpelessly Broken that specializes in breaking Small Office Home Office (SOHO) routers, their case study on the security of hospitals and vulnerability analysis on many different IoT devices. In these livestreams, the hackers among us are able to learn about the process that goes into hacking a device, what to look for within a device and much more. I wrote up a similar write up on two other livestream exploits, which can be found at Analysis of Exploit of a NAS Device and Analysis of Exploitation Video of SNMP if you are interested. However, all of the fame and glory should go to the security researchers at ISE for being such a large figure and educator in the cyber security industry.

Rick Ramgattie is a security analysis at ISE, where he does security consulting and research within the cyber security space, including publications in CSRF by deciphering Java RNG, routers and embedded devices. Throughout the livestream I was really amazed at the amount of awareness over explaining each and every step to the audience in such a simple and elegant way. I would highly recommend watching the video on the livestream; this is only meant to make it easier for someone to follow. So, thanks so much for this fantastic exploit and explanation Rick! Also, thanks to Ian for helping creating the exploit!

My Thoughts

This video was quite amazing at demonstrating the vulnerability. However, I'd like to set the bar even lower for people/ take notes for myself to use in the future. Below are my takeaways from the penetration test. To start with, I will talk about basic terms and technologies used to have a better understanding of the situation and tools used to exploit the device.

Terminology/Technology

NAS (Network Attached Storage)

A good link for describing a NAS can be found here. Essentially, a NAS is a computer level, file storage system that can be viewed remotely.

Basic Networking

In order to connect to an application or service, we define these areas as IP addresses, which can correspond to domain names. A port is a particular socket on the IP being connected to. An example of a common port is http, which by convention, used on port 80. The Nmap tool is used in order to scan for the open ports and what services they are each running. A tutorial can be found at https://github.com/mdulin2/nmap_writeup.

Attacking Methodologies

There are three types of attacking: white, grey and black box. With a black box attack, an attacker only has the application itself, with no specs, code or anything on how it works. Black box attacks tend to only find the low hanging fruit because it is difficult to have a firm grasp on the system. A white box attack is the opposite; the attacker has the code for the device itself! This gives the attacker the ability to understand the logic and implementation of the system, giving them a much greater ability to exploit something on the system. ISE likes to do a white box analysis on devices because they like to find the issues with the underlying structure of the device, as opposed to easy, low hanging fruit. Often, the most serious attacks take a very deep level of understanding that cannot be obtained with a black box approach. A grey box is simply a mixture of the two above.

XML (eXtensible Markup Language)

A language that is commonly used to transport data in a flexible, agreed upon and organized manner. XML is similar to JSON in the way that it was created to be a unified way to transfer data. XML looks like HTML in that it uses tags such as <Attribute>.

Wireshark

A network protocol analyzer. The tool allows for someone to view, organize and analyze the individual packets that were being sent on the network. These captures can happen in real time or be saved for future analysis.

Vim

Vim is an amazingly simple text editor that runs within the terminal. Although it may not be the easiest tool to use, the usage by Rick shows off the incredibly fast capabilities of Vim within the terminal. Other similar tools include Nano and Emacs.

Netcat (nc)

A common computer network utility for reading and writing connections. Netcat is extremely versatile, making it a useful tool within any hackers toolbox.

Reconnaissance

To start with, the ISE folks wanted to understand how the Drobo device worked. Without understanding what the device is capable of, there is no way to know how to exploit it. Some penetration testers will go as far as to say the reconnaissance step is the most important; it allows an attacker to establish possible weak-points in the service. So, they played around with the functionality of the device until they understood what it was capable of. One item that I found particularly interesting, that Rick pointed out, was about the serial number of the device. When doing attempting to do some exploitation, it is important to know which values are what. In this case, knowing the value of the serial number turned out to be an important value to remember.

After playing with the functionality of the device, they figured it would be fruitful to map what services were available on the device; which led them directly over to nmap, the port scanner to understand the services offered by a device. He used:

 nmap -T4 -A -v ip_address_value

With some trivial services coming up, a few things should be noted: look for version numbers of services, as something may be out of date with a known vulnerability, creating an easy exploit plain. But, nothing had a known vulnerability; time to take a deeper look into this. He noticed that nmap was unable to determine what a few of the protocols were on non-traditional ports. At this point, because they were protocols not recognized by nmap and on uncommon ports, they were able to determine that a custom protocol was likely being utilized.

Custom Protocol

Well, now what? We have a custom protocol on ports 5000 and 5001; what does an attacker do with something this obscure? Personally, I felt that a custom protocol was going to be a nightmare to figure out. But, the ISE members even claimed custom protocols are a good thing to find. The reason being that with a completely new protocol, there are likely going to be many mistake that have been made within the implementation of it. We can expand this understanding to not just network protocols; but any service created from scratch is likely going to have a vulnerability in it, such as a cryptographic function, new web framework among others.

Understanding the Protocol

Now that the custom protocol had been discovered, it was time to figure out how it worked, always known as reverse engineering the protocol. The first action that Rick performed was to connect to the Drobo device with netcat. Surprisingly, the device connected to the netcat connection without any authentication. No authentication is needed to run commands on the device; this allows for anyone with the capability to connect to the Drobo device to alter the state of it! This is a major red flag! Rick, with his understanding of what the Drobo device services are, reads the XML to find quite a bit of information about the device. To make this even more interesting, none of the data was encrypted. He discovers the hard drive information, firmware number and serial number. This sort of information is very valuable when a remote attacker is trying to verify is the device is vulnerable to an attack.

To further understand the protocol, Rick dives into the wonderful world of packet analysis. This allows for a someone to directly view and understand the network traffic between the device and the application interfacing with the device. He opens up Wireshark to understand the network protocols. The only way to truly reverse engineer a protocol is to give the request different values and see what happens; this can be very tedious and annoying but can yield fantastic results! The best way to do this follows these steps:

1. Run some action on the application itself.
2. Understand/see the results on the device; in this case the Drobo machine.
3. Go to Wireshark to see the packet that was sent in order to complete the request
4. Repeat...

If these steps are followed over and over again, it will become obvious which commands do what actions! Which essentially allows you to reverse engineer the protocol. The commands will be quite obvious, after a while, to control the device. But, the hardest item in the reverse engineering protocol is figuring out the structure of the packets. Rick mentions that it took his colleague an immense amount of time to figure out which bytes were associated with the size of the information being sent...Doing this sort of reverse engineering on a device is difficult! But, security by obscurity will never work; these protocols will eventually be reverse engineered.

Attacking the Device

At this point, Rick and Ian decided to go after the Drobo web application to see if any RCE's could be executed remotely on the Drobo device. A major reason to go after the web application is because the source code is readily available to read (creating a white box problem to solve) and it a common way people access the Drobo machine.

Dangerous Functions

A major claim that Rick makes is "One thing you should focus on is finding dangerous functions at the beginning. A lot languages have functions are that 'bad'". What wise words; this narrows down the surface to only a minimal set of files to start with. Why dig deeper than we need if a shell is easily obtainable? If these functions are not found, then it may be necessary to dive deeper. In PHP, there are functions such as 'exec' and 'system' that allow a user to execute a bash script on the OS. If these functions are not escaped correctly, then many exploitable vectors may arise in the code.

Following Logic

In order to actually find a vulnerability, it is extremely important to be able to follow how the program works. This includes the flow from file to file, access points from the web application, branches or forks in the road and just basic logic steps in the program. The only way to get better at this is simply writing and reading as much code as possible. By doing this, you will start to understand programs are written in order to exploit them.

Rick chooses a request called enable_user. Within this function, there is an if statement that requires that the enabled parameter be set to true. So, adding this parameter to the Get request is important! Again, being able to follow the flow will take to the "enableUser" function, where the exec is being used at. The payload needs to be inside of the username with the password not being NULL.

Entering the Exploitation Zone!

Now, Rick had figured out his injection point. So, how do we exploit this? With the exec, we have the ability to execute whatever we want on the underlying Linux OS!

Initial Payload

At the beginning, all that needs to be done is something simple, such as creating a file on the OS. The payload for creating a file looks like:

 DroboAccess/enable_user.php?username=test';%20touch%20testise%20'&enabled=true

Here's a quick breakdown of the payload:

• DroboAccess/enable_user.php is the page being access with a get request.
• Username has some weird values in it! A breakdown of that:
  • 'test' is a placeholder for the username being used.
  • %20 is simply a space, that is URL encoded. Initially, the request was not working because the values were not URL encoded.
  • 'touch' is the bash command to create a file. 'testise' is just the name of the file.
  • The single quotes(') are used to escape the string that the username is initially encapsulated in. Notice how there are two different single quotes; one to escape the string, the other way to reenter the escaped string. We need entire command to still work, which is what the second single quote is used for.
• 'enabled' is set to true in order to follow the correct path to the vulnerable function.

How to Get the Shell

At this point, Rick had the ability to create a file on the OS with an injected command. It was time to get a shell out of this!

But, how to get the shell? Rick then goes to the bin (short for binaries) directory, where a large selection of the devices applications can be found. After looking through these binaries, Rick comes to the conclusion that Telnet would be an excellent way to get a /bin/sh out of it.

Final Payload

After figuring out that Telnet was an available service to run, Rick creates a payload to allow for him to connect to the device. I will only talk about the new points in this payload:

 DroboAccess/enable_user?username=test';/usr/sbin/telnetd%20-l/bin/sh&enabled=true

• /usr/sbin/telnetd calls the binary for telnet directly, leaving no doubt which program is being called.
• -l is used in order to specify the user upon login. Hence, the /bin/sh is used here.
• /bin/sh in order to complete the shell payload! Gives us the ability to do whatever we want on the device!

Finally, run nc ip_adress port_number and you have got a root shell! Boom! There it is; an unauthenticated RCE on the Drobo device via the web application. Game over!

Little Points

Finding the Web Application

Common web servers to search for include httpd, nginx and apache. Once on the device, grepping (a string search) for httpd, nginx or apache will guide us to the source code on the web application.

Embedded Systems of Tools

When using the normal command line tools on an embedded system, sometimes a version of the tool will not have all of the functionality on it. A few solutions to this: moving the binary or source code to another system with the proper tools or find a different solution to the problem that you are trying to solve. Also, it is common for embedded devices to have a Unix based OS running.

Live Debugging

I enjoyed watching Rick go through the entire livestream debugging, as this is extremely difficult to do. Little things, such as trying to change to a directory, that happens to be a file are often good for us to see! Further than the little issues, understanding what could be causing the issues is important. For instance, when the telnet port would not connect, Rick had to figure out why. In the end, another program was being ran on it. But, he went through some steps to get there. Understanding the thought process to solve tedious and annoying issues is valuable to see.

Conclusion

ISE, thanks so much for livestreaming these exploits; it is helping the security community grow! I appreciate the dedication to the security community with this, alongside hosting the IoT village at several conferences and the other amazing pieces of research, such as the patient health attacks at hospitals.

Major S/O to Rick and Ian for finding the exploit in the first place! I love the excitement you two come into this field with; it makes the security world so much fun! Cannot wait for more similar videos.

Hope you learned something from this! I really enjoyed listening to a professional pen tester go through his mindset when testing something. I look forward to becoming a better pen tester and finding exploits myself! Cheers from Maxwell Dulin (ꓘ).

Questions

After posting this, I had several questions, which Rick Ramgattie was kind enough to respond on 10/5/2018. The questions and answers are below:

Question: How did Ian and Rick figure out the size on the request?
Response: When we began reverse engineering the protocol we issued a handful of requests and began taking a look at them in Wireshark. We saw that when issuing requests the first couple of bytes were the same. There was a part in the middle that changed between different requests, and the rest was the ASCII values for the XML data that was being sent to the user. Focusing on the parts that changed in the middle, we issued the requests again to see if it was a counter or just random data. The middle part stayed the same when it was the same request, so we began thinking about its meaning. Ian and I threw some ideas out and after verifying the length of the payload we determined that it was the size.

Question: How many functions did you check before you found this particular RCE?
Answers: After we gained SSH access to the device, we pulled off the source from the Drobo and began looking for functionality that would allow us to get a shell. The first page we looked at made use of a command that executed OS Commands and executed these commands based on user input. It was very straight forward.

Question How many hours in total did it take to reverse engineer the protocol and then get to a /bin/sh?
Answer: It took us about 16 hours together to figure out the protocol. The OS command injection was straight forward after enabled SSH. We got it within minutes of SSHing onto the device.

Questions:You mentioned something about 'dropping on by'? Do you mean coming in to the office? If so, that would be a blast to be around this group of fantastic engineers!
Answers: We take the village to a lot of conferences. We are actually at Derbycon right now. We love talking about application security with people. We are going to be at the IoT Security Summit, and BSides DC next.

Major shout out to Rick for responding to these questions and to the rest of the ISE team for the livestream videos. Please keep up the security outreach, as I believe it is making a major difference!