Offensive Security and Application Security Perspectives

Vulnerability Research

Command Injection on the Monitoring Appliances

Name: Mutiny Monitoring Appliance

Vendor: Mutiny

Virtual Appliance: Download Page

Vulnerability: Command Injection

Affected Versions: Versions before 6.1.0-5263

CVE ID: CVE-2018-15529

This post will cover an authenticated command injection vulnerability that I discovered on a monitoring appliance. 

For this example, I have a Mutiny virtual appliance running at the IP address 10.10.10.10 in Virtual Box. The maintenance.cgi script on port 81 is the target. You will need to check if the default credentials work, hunt for the credentials, or try a smart password attack to login.  The default credentials worked for me since this is a virtual appliance. After logging in, this is what the page looks like and we will exploit the highlighted upload feature.

I would also like to note that I could not find any other way to execute arbitrary commands as a legitimate user with normal access. The Mutiny developers obviously didn’t want their end-users to poke around the file system.

Now back to the upload feature. This upload feature is intended for the system upgrade file that can be found on Mutiny’s Download page. You are supposed to download the file (e.g., CentOSmutinyBundle-6.1.0-5191.tgz.gpg) and upload the file to upgrade the appliance. Instead of uploading Mutiny’s upgrade file, I created an empty text file and uploaded it.

The appliance returned an error message so I could only upload files that end in “.gpg”.

Remember, a legitimate upgrade filename from Mutiny’s download page looks like this “CentOSmutinyBundle-6.1.0-5191.tgz.gpg”. I changed the “upgrade.txt” filename to” upgrade.tgz.gpg” to match an expected filename.

I received an error message, but it was a different error message. The appliance tried to at least process my file this time!

After much thinking, I determined that Mutiny has to be putting this filename inside of a system function within the code to process a file with that file extension. If Mutiny isn’t sanitizing the filename, then I may be able to inject commands within the filename.

I created a new file with an OS command within backticks. The command is “sleep 5”. If the HTTP response took 5 seconds or longer then this could be a command injection vulnerability.

I used Burp Suite to intercept the HTTP request in order to modify the filename with the OS command.

It Worked! I had a blind command injection, and it did not break the appliance since the upgrade process did not start because the file was empty.


The Exploit

I wrote an exploit that exploits the command injection vulnerability so I could move away from using the browser and Burp Suite. I tested the exploit by pinging my Kali box at 10.10.10.3

I used TCPDump to capture the ICMP packets. The exploit was working. Mutiny was pinging my Kali box.

It was time to get a shell on the appliance. I base64 encoded a bash reverse shell so the command would not get mangled in transit, then Mutiny would decode the command and execute it.

A root shell on Mutiny!


Timeline

  • August 12, 2018 – A detailed report and exploit was sent to the vendor.
  • August 13, 2018 – The vendor released a patch (version 6.1.0-5263).
  • August 19, 2018 – Mitre assigned a CVE.
  • August 22, 2018 – Published
  • December 9, 2018 – Published a detailed write-up (this post).