icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons_061

[R1] ManageEngine OpManager NMS Server Multiple Vulnerabilities

Critical

Synopsis

During plugin authoring and testing, Tenable discovered several additional vulnerabilities in ManageEngine OpManager.

#1 NMS Server Multiple Method Remote DoS

OpManager uses a custom NMS server written in java that runs in the JVM shared by all OpManager components. The NMS server has FE (frontend) and BE (backend) components that listen on arbitrary adjacent ports (e.g. TCP port 49197, 49253, and 49254 during our testing). These services are easy to identify remotely by sending a crafted request, to which the server will send a serialized response back. The code that first deserializes the packets does not appear to have sanity checks for lengths, or even to see if a field exists. It is possible to send malformed packets to the server repeatedly until the JVM memory is exhausted, or trigger other errors which cause the JVM to restart and deny service until an administrator restarts the service. Tenable created a script (opmanager_exploit4.py) for the vendor that simply sent fuzzed input that triggers such errors leading to an immediate crash, and does not require authentication.

#2 NMS BE Server REFRESH_CLIENTCOUNT Command Java Object Deserialization Remote Code Execution

This vulnerability was successfully exploited on builds 1150 and 1200. On build 1150, the JVM is a low enough version that we can utilize a vulnerable class it ships with. For 1200 (latest version at the time of testing) commons-beanutils ships with a class vulnerable to code injection with object deserialization. The easiest way to exploit this is by sending a crafted 'REFRESH_CLIENTCOUNT' command and control the data to be deserialized. Tenable created a PoC that utilizes a OpManager version dependent payload.bin. For build 1200, an example payload that utilizes commons-beanutils executes the command 'cmd /c whoami > ../help/nessus_1.txt' (under windows commands are run as 'nt authority\system' by default, which is not good we hear). The file can be remotely accessed from the management web server to verify that the attack was successful (e.g. http://[target]/help/nessus_1.txt). For build 1150, the payload utilizing JRE classes work and executes 'cmd.exe /C whoami > help/test_nessus12345678.txt' as nt_authority\system. Again, this file can be remotely accessed from the management web server to verify that the attack was successful (e.g http://[host]:8080/help/test_nessus12345678.txt).

OpManager also ships with Apache Commons FileUpload 1.3.1+, that contains an object called DiskFileItem, which is normally harmless. However, the object can be modified after it is serialized to behave in ways that were not intended. Specifically we can modify DiskFileItem to:

  1. Create a new file anywhere the Java process has permission.
  2. Write anything we would like to that new file.
  3. We can also move (copy and delete) any file on the remote system that we have permission to.

There are two limitations though:

  1. We don’t control the filename. This is generated by DiskFileItem class as upload_$uuid_$counter.tmp.
  2. Files are created using the File.createTempFile() interface. That means the lifetime of the file is totally dependent on the usage of deleteOnExit(), how long the JVM runs, and if it is moved after creation (If the move is done by the exploit then it will still be deleted. However, if the move is done by the InvokerTransformer exploit then it will not be deleted). It is our observation that files live for ~2 minutes when created by NetIQ Sentinel.

Using a 'frohoff' ysoserial payload, an unauthenticated remote attacker can copy and delete arbitrary files.

#3 TFTP Server Unauthenticated File Upload Stored XSS

By default, an unauthenticated user can upload arbitrary files via TFTP that can be accessed under the "tftp_files" directory on the management web server, by an authenticated user. Uploaded files will appear at http://[target]/tftp_files/[uploaded_file]

This is clearly undesirable, as an attacker can upload HTML files that contain malicious JavaScript XSS payloads that could help a remote attacker with gaining access to the admin interface (e.g. cookie stealing). Note that the web server will not run .JSP files unfortunately, but will serve just about any other extension.

#4 TFTP Server Remote Path Disclosure Weakness

In the minor annoyance category, the TFTP server will also disclose the full system path if provided a malformed request. Don't say we never publish PoCs! Consider it a reward for reading this far:

[fox@thepodium ~]$ tftp 192.168.24.70
tftp> get *
Error code 1: File Not Found C:\ManageEngine\OpManager\tftp_files\*

Solution

ManageEngine has released OpManager 12.2 Build 12200 to address these issues.

Disclosure Timeline

2016-03-31 - Issues discovered
2016-04-06 - Submitted to ZDI for consideration, case int3grate0003
2016-04-11 - ZDI declines
2016-04-13 - Issue reported to vendor via security@zohocorp address.
2016-05-17 - Ping vendor for update
2016-07-07 - Ping vendor for update and their views on Chinchillas
2016-07-08 - Vendor replies with input, 1 - 3 will be fixed in 12.1 or 12.2. No input on Chinchillas.
2016-07-12 - Ping vendor, ask for ETA on 12.1
2016-08-18 - Ping vendor for udpate
2016-08-23 - Vendor says both to be fixed in 12.2, targeted end of September
2016-09-20 - Ping vendor to see if still on track for September release
2016-10-19 - Ping vendor for update
2016-10-31 - Vendor says 12.2 delayed to last minute show stoppers. Scheduled for Nov 3 release.
2016-11-24 - Ping vendor for update
2016-11-25 - Vendor says 12.2 was released "a couple days ago"

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 advisories@tenable.com