Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] ManageEngine AssetExplorer /workorder/FileDownload.jsp fName Parameter Traversal Remote File Disclosure

Medium

Synopsis

On October 6, 2015, xistence[at]0x90.nl disclosed a traversal issue in ManageEngine ServiceDeskPlus. According to the timeline included, the issue was fixed by ManageEngine with the release of version ServiceDesk 9.1 build 9111 on September 28, 2015 (reference SD-60283, 60280).

During plugin development, a Tenable researcher discovered that ManageEngine AssetExplorer appeared to be vulnerable to a similar traversal. In the file C:\ManageEngine\AssetExplorer\applications\extracted\AdventNetAssetExplorer.eear\AdventNetServiceDeskWC.ear\AdventNetServiceDesk.war\WEB-INF\lib\SDJSPClasses.jar, the org.apache.jsp.workorder.FileDownload_jsp.java file appears to be a Java Servlet that serves the URL pattern /workorder/FileDownload.jsp according to \applications\extracted\AdventNetAssetExplorer.eear\AdventNetServiceDeskWC.ear\AdventNetServiceDesk.war\WEB-INF\web.xml. When installed on Windows (due to the way the OS parses relative paths), an unauthenticated traversal allows for accessing arbitrary files outside the server's path. At the time the Servlet processes a GET request, the current directory is [PRODUCT_INSTALLATION_DIR]\bin. If an attacker sends a GET request with a specially crafted fName parameter to cause the Servlet to interpret "..<os_path_seperator>server<os_path_seperator>default<os_path_seperator>log<os_path_seperator>support<os_path_seperator>null<os_path_seperator>../../../../../../../<arbitrary_absolute_file_path>", the relative path specifications causes Windows to traverse back to the root directory of the drive letter even though the "support" and "null" sub-directories do not exist.

Based on the initial disclosure and internal research, it appears that both ServiceDeskPlus and AssetExplorer both use the vulnerable SDJSPClasses.jar file. The changelog for each product shows it was thought to be fixed in AssetExplorer build 6113. However, it appears that build 6113 simply changed the URL pattern *.jsp in web.xml to require authentication. This means that in build 6113, all URLs ending with .jsp (with a few exceptions) will be subject to authentication. However, the path traversal vulnerability doesn't go away, it just requires authentication. In an application with multiple user roles, it may not be expected that an authenticated user should have access to potentially sensitive files on the underlying file system, so this still poses a security risk.

Solution

ManageEngine has released AssetExplorer version 6.1 build 6116 that properly fixes this issue. Note that the release notes do not make mention of this issue, while clearly listing four other vulnerabilities that were fixed.

Disclosure Timeline

2015-11-12 - Vendor informed via [email protected]
2015-11-12 - Vendor auto reply, ##7323624 assigned
2015-11-24 - Ping vendor for update
2015-11-24 - Vendor says issue fixed, will be in next SP released "mid of next month"
2016-02-10 - Ping vendor for update
2016-02-10 - Vendor says SDP (9121) fixes. Tenable tests AE (6116) confirms fixed.
2016-02-17 - Issue disclosed

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]