RCE In HPE Insight Cluster Management Utility (CVE-2024-13804)
I discovered an unauthenticated RCE in HPE CMU in 2023 by weaponising the Java client application against the server. The techniques discussed here, can also be applied to other Java applications.
TL;DR
An unauthenticated remote code execution vulnerability exists in HPE Insight Cluster Management Utility (CMU) v8.2 (https://www.hpe.com/psnow/doc/c04111735), which allows an attacker to bypass authentication and execute commands or code on the backend.
Introduction
Hewlett Packard Enterprise (HPE) Cluster Management Utility (CMU) is a powerful tool designed for managing and monitoring high-performance computing (HPC) clusters. It provides administrators with centralized control over large-scale compute environments, enabling efficient deployment, monitoring, and maintenance of nodes within a cluster. With features like automated provisioning, health monitoring, and workload management, HPE CMU helps organizations optimize their HPC infrastructure for maximum performance and reliability.
However, like any complex software managing critical IT environments, HPE CMU is not immune to security vulnerabilities. In this post, we will explore a vulnerability in HPE CMU. Unfortunately, the product is End-Of-Life and will no longer receive any additional updates. Therefore, it is crucial to restrict access to this environment at network level to limit exposure.
Java FX / JNLP Client Apps
When accessing the web page of CMU in the browser, it allows you to download a GUI jnlp (Java client) application. FX applications (jnlp extension) are just XML files that will download and run the specified class of a jar file with given arguments in a local GUI. The CMU jnlp contains the following XML content:
In this case, the application downloads the cmugui_standalone.jar file, which connects to the backend server over port 1099. The user can simply open this application and view some data without authorization. However, there is no permission to use Cluster Administration or anything else without proper authentication.
Many menu items related to administration appear to be grayed out, so let's download the jar for further analysis.
Jar Decompilation
Since the application is a jar file, it can be decompiled, updated and recompiled. The first step would be to decompile cmugui_standalone.jar. For example, JD-GUI can be used to decompile the application.
Take note of the Java version of the app, as it will be important when recompiling the application after weaponization at a later stage.
Now use file > save all sources to save the decompiled files to a zip.
Source Code Analysis
We can now initiate the code review process.
IDE Setup
Download an IDE, such as IntelliJ IDEA Community Edition and create a new Java project with a Java version similar to the decompiled jar. The Java version in the decompiled app was 1.7. However, in this case JDK 1.8 also worked and was easier to obtain.
Unzip the decompiled source code and add the contents to a decompiled_src folder in the project. This way we can review it and make modifications later to override existing functions.
Create a lib folder and add the initial jar here.
Go to File > Project Structure and add a new module in the modules tab:
Now, open the artifact and add a jar as output artifact. Choose the "from modules and dependencies option". This ensures the project is compiled to a jar again once modifications are made.
Authentication bypass
Now we are ready to browse the source code. The first thing we will try to figure out is how the authentication and authorization mechanism works. While searching for admin functionality, the first thing that stands out are the many isAdmin occurrences. For example, the package com.hpe.cmu.gui.model contained a check to validate if the user is admin. This is shown in the following code snippet.
As most experienced pentesters know, client-side authorization checks do not mean anything without server-side validation. We could simply set all instances of isAdmin to true and recompile the application. This can be done by copying the java files we would like to edit to the source folder. Make sure to use the same package name (directory path) as the original file and also copy over the MANIFEST.MF file.
After recompiling, we can observe that we already got rid of the grayed-out areas in the Cluster Administration menu. Of course, this is not necessarily proof of any vulnerability unless we can actually execute additional functionality.
Implementing Remote Code Execution
We already know that the application communicates to the backend over port 1099 (Java RMI), which is perhaps even most famous for the many exploits that exist. However, I could not find an immediate direct way to exploit it by accessing this port.
A short search through the source code for the RMI implementation revealed how to execute commands on the backend via implemented RMI classes.
Since we know that the isUserAdmin check is likely executed (multiple times) throughout the code, we can call the ExecuteCmdLine method of the RMI model from here to execute commands on the backend and print output to stdout. In the following screenshot, we print the output of the ifconfig Linux command.
Recompiling The Application
Now it's just a matter of recompiling the client application to a jar and executing it. To achieve this, we can copy the modified AdminUserModel java file to the source folder. Again, make sure to use the same package name (directory path) as the original file. Also copy over the MANIFEST.MF file
Now go to build > Build Artifacts...
Sometimes you may encounter signature issues when running the jar. These can be avoided by simply opening the final jar with an archive tool like Winrar and removing .SF and .RSA file from META-INF.
Remote Code Execution
Finally, execute the jar from the commandline to start the application and trigger the ifconfig command. As we can see, the ifconfig command executes successfully.
Impact
This proof of concept demonstrates the possibility to execute commands remotely on the Cluster's management node. Furthermore, these commands are executed as the root user, which means full system access. On top of this, CMU is cluster management software so this means full control over all nodes in the cluster as well. E.g., it was possible to also connect to ILO interfaces of nodes.
Mitigation
Unfortunately, the software is considered End of Life (EoL) and will likely not receive any update given that this is a design flaw and requires significant effort to fix.
If you still have this software running in the environment, the main recommendation would be to isolate it from the rest of the environment at network level.
Disclosure Timeline (YYYY-MM-DD)
This timeline illustrates perfectly why I prefer not to chase CVEs.
2023-05-02: Contact HPE PSRT (security-alert@hpe.com) 2023-05-02: HPE PSRT (security-alert@hpe.com) responds findings will be assessed. 2023-06-05: Requested Update from HPE PSRT (no response) 2023-11-17: Requested Update from HPE PSRT (no response) 2024-03-21: Contacted CERT about vulnerability and unresponsive vendor 2024-03-21: Response from CERT 2024-03-21: Provided additional details to CERT on tested version 2024-05-28: Response from CERT that CVE request is relayed to ENISA 2024-10-28: Follow-up from CERT to submit via MITRE 2024-10-28: Send vulnerability details to MITRE 2024-10-31: MITRE asks if I contacted HPE first 2024-11-01: Explained the process I went through to MITRE 2024-11-20: MITRE gets HPE to agree on CVE 2025-01-02: Requested update on CVE status from MITRE 2025-01-09: MITRE responds with the question if I received the CVE ID from HPE (not the case) 2025-01-13: MITRE reaches out to HPE again 2025-01-31: MITRE forwards the CVE ID CVE-2024-13804, which they just received from HPE
Last updated
