Introduction

Affected Product Summary

While researching the Progress Kemp LoadMaster load balancer we discovered an unauthenticated command injection in the administrator web interface of the appliance. This allowed full compromise of the LoadMaster if you could reach the administrator web user interface (WUI). The vulnerability was assigned CVE-2024-1212 and has since been patched.

LoadMaster is a load balancer and application delivery controller. It ensures high availability and reliable performance for web and application servers by distributing traffic efficiently. LoadMaster can be deployed in various environments to suit different business needs, including options for hardware, virtual machines, and cloud platforms (AWS and Azure).

During this research we used the virtual machine image to test the LoadMaster load balancer locally as well as tested against the AWS Marketplace AMI.

After spinning up the virtual machine (VM), we gained access to the file system on the virtual disk, enabling us to examine the binaries and source code files. LoadMaster employs Httpd to relay HTTP requests to CGI Bash scripts for processing. Following an exploration of the web interface, we shifted our focus to the optional REST API.

The API lives at the endpoint “/access”. A request to this endpoint is processed by a Bash script. The Bash script calls the “access” binary at “/bin/access” to set up permissions and then process the API request.

1. First the code tries to locate the API command [1] which is the second part of the path. For example, in a call to “/access/set” “set” would be the command.
2. The next block [2] performs some checks on the command and parameters and returns a 404 if they are not as expected.
3. Taking these points into consideration a path like: “/access/set?param=enableapi&value=1” should pass these checks and reach the “verify_perms()” function [3].

This would also allow the verify_perms() function to be reached even if the API is disabled in the application (disabled being the default setting).

Below you can see a normal request to “/access” with the API disabled. The request fails and returns a 404 as expected.

Now that we confirmed we can reach the “verify_perms()” function, let’s see what it does.

Within the “verify_perms()” function there is a call to “v1getuser()” which handles looking up the user making the request for the v1 API endpoint. Within “v1getuser()” these next two images show that the “REMOTE_USER” [1] and the “REMOTE_PASS” [2] environment variables are retrieved and then passed into the “validu()” [3] function.

The “REMOTE_USER” and “REMOTE_PASS” environment variables are set when the basic authentication header is decoded by the httpd server. The “validu()” function is used to check if the user is valid based on those variables.

Next, looking at the “validu()” function we start to see something quite interesting. The “REMOTE_USER” and “REMOTE_PASS”, which can be controlled by any unauthenticated user by sending a basic authentication request, are used to construct a command with __sprintf_chk() [1] and then passed into a “system()” call [2] without any validation or sanitization.

At this point:

1. We can bypass the disabled API restrictions and reach it even if it is disabled.
2. We can supply unauthenticated user input, including special characters, as a basic authentication header.
3. That input is eventually evaluated by a “system()” call which executes commands.

Let’s see if this can result in command injection. 

It is possible to break out of the context of the command in the “-u” parameter using a single quote, and then terminate the command using a semicolon and execute our own command.

Decoded basic authorization

This blog post highlights an application that accepted user input and directly passed it to a function designed to execute the input as a shell command. The vulnerability was uncovered through tracing of the input and assessing its processing at each step.

Directly passing user input to system functions is strongly discouraged due to the significant security risks involved. If the operation is necessary, ensure that the user input is strictly validated and sanitized of any control characters prior to being passed to the function. It is imperative to conduct thorough reviews of both the code and applications in use as this exposes a critical attack surface.

Rhino wants to thank Progress software for working with us in quickly implementing a patch for this vulnerability.

As always, feel free to follow us on Twitter or LinkedIn and join our Discord server for more releases and blog posts. 

Twitter: https://twitter.com/rhinosecurity
LinkedIn: https://www.linkedin.com/company/rhino-security-labs/
Discord: https://discord.gg/TUuH26G5
Researcher/Author’s Twitter: https://x.com/daveysec