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:
- Create a new file anywhere the Java process has permission.
- Write anything we would like to that new file.
- We can also move (copy and delete) any file on the remote system that we have permission to.
There are two limitations though:
- We don’t control the filename. This is generated by DiskFileItem class as
upload_$uuid_$counter.tmp.
- 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:
[[email protected] ~]$ tftp 192.168.24.70
tftp> get *
Error code 1: File Not Found C:\ManageEngine\OpManager\tftp_files\*
