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. CVE ID assigned: 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:

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0" codebase="https://target-ip/">
	<information>
		<title>HPE Insight Cluster Management Utility</title>
		<vendor>HPE</vendor>
		<homepage href="http://www.hpe.com/info/cmu"/>
		<offline-allowed/>
	</information>
	
	<resources>
		<jar href="cmugui_standalone.jar" main="true"/>
	</resources>
	
	<!-- settings -->
	<resources>
		<j2se version="1.7+" max-heap-size="768m" href="http://java.sun.com/products/autodl/j2se"/>
	</resources>
	<security>
		<all-permissions/>
	</security>
	<application-desc main-class="com.hpe.cmu.gui.view.SplashScreen">
		<argument>CMUServerIP=target-ip</argument>
		<argument>CMUServerPort=1099</argument>
		<argument>debug=false</argument>
		<argument>3Ddebug=false</argument>
	</application-desc>
</jnlp>

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.

Anonymous access to the application

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.

Opening the jar with JD-GUI

Take note of the Java version of the app, as it will be important when recompiling the application after weaponization at a later stage.

Manifest.mf

Now use file > save all sources to save the decompiled files to a zip.

Saving decompiled source code

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.

Creating a new project

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.

Add decompiled source to project

Create a lib folder and add the initial jar here.

Add original jar as library

Go to File > Project Structure and add a new module in the modules tab:

Register orginal jar

Successfully added library

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.

Configure jar output

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.

isadmin validation

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.

New menu items

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.

RMI Interaction

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.

Updated isUserAdmin() function

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

Updating the AdminUserModel.java file

Now go to build > Build Artifacts...

Rebuilding the jar

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.

Successful ifconfig execution

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 ([email protected]) 2023-05-02: HPE PSRT ([email protected]) 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