HPE Insight Cluster Management Utility

# RCE In HPE Insight Cluster Management Utility (CVE-2024-13804) ## TL;DR An unauthenticated remote code execution vulnerability exists in HPE Insight Cluster Management Utility (CMU) v8.2 (), which allows an attacker to bypass authentication and execute commands or code on the backend. CVE ID assigned: [CVE-2024-13804](https://nvd.nist.gov/vuln/detail/CVE-2024-13804). ## 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: {% code lineNumbers="true" %} ```xml HPE Insight Cluster Management Utility HPE

CMUServerIP=target-ip CMUServerPort=1099 debug=false 3Ddebug=false

``` {% endcode %} 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](http://java-decompiler.github.io) 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](https://www.jetbrains.com/idea/download/#section=mac) 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.

Removing the invalid signatures from the archive

### 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. The folks from MITRE did an excellent job here. I'm not sure if I would have succeeded without them. 2023-05-02: Contact HPE PSRT ()\ 2023-05-02: HPE PSRT () 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. MITRE asks writeup reference\ 2025-02-08: Sent a link to this blog post as reference\ 2025-02-10: MITRE forwards the reference to the blog to be included in the CVE publication\ 2025-03-04: Contacted MITRE to follow-up\ 2025-03-08: MITRE explains HPE indicated they would publish soon, but did not do so. MITRE sent HPE a reminder and offered to transfer the CVE ID to them\ 2025-03-21: Contacted MITRE to follow-up\ 2025-03-31: Mitre offered an ultimatum to HPE to publish the CVE themselves\ 2025-03-31: HPE published CVE\
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://red.0xbad53c.com/vulnerability-research/rce-in-hpe-insight-cluster-management-utility-cve-2024-13804.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.