This blog covers 2 vulnerabilities discovered in LoadMaster load balancers. CVE-2024-2448 is an authenticated command injection vulnerability and CVE-2024-2449 is a Cross-Site Request Forgery (CSRF) protection bypass vulnerability. The CSRF could be combined with the command injection and leveraged to execute commands on LoadMaster load balancers by targeting a user of the administration web user interface (WUI).
These vulnerabilities were discovered alongside the previously disclosed unauthenticated command injection during our research on LoadMaster.
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.
An authenticated command injection vulnerability exists in the “/progs/hg_cfg/add_rs/” endpoint of the Admin WUI of LoadMaster. This vulnerability is possible to be exploited by a user with any permissions as long as they can authenticate to the WUI.
The Vulnerability stems from the use of an “eval” statement in the Bash CGI script responsible for processing requests to the “/progs/hg_cfg/add_rs/” endpoint. “add_rs” represents add real server in the application.
Let’s take a look at what happens when a request is made to the “add_rs” endpoint. It is processed by a Bash CGI script.
The “add_rs” command calls “addSelectedRS” with the argument passed to the endpoint (“add_rs/ARGUMENT”). After this, it calls “do_show_rs”.
In the “addSelectedRS” function the argument is base64 decoded [1] and if a matching entry does not already exist, it will add the ‘SELECED_RS=”ARGUMENT”’ variable to the file at the $FENV path [2].
Next, “do_show_rs” will be called which is responsible for displaying the “rs” (real server) information. “do_show_rs” just adds some static HTML and calls the “showRSSelection_T” function.
Looking at “showRSSelection_T” we can see that the “SELECTED_RS” variable we inserted prior, is extracted using grep and then the result is passed directly to “eval” [1]. This means we can break out of the intended command of evaluating the variable and execute our own command.
It is possible to execute arbitrary commands by using control characters such as “;ls /;”, or command substitution $(ls /) and then base64 encoding and passing in as an argument. Either will cause the command “ls /” to be executed after the grep command executes. Adding “1>&2” to the end of the command will also redirect stdout to stderr and ensure the output is displayed in the HTML.
This image shows executing the command “ls / 1>&2” as described.
The LoadMaster WUI uses a referrer header validation to prevent CSRF. This validation performs a regex check on all state changing requests to try and ensure the requests are coming from the same page which the request is issued to.
We discovered there was a flaw in the way the regex check was being implemented which allowed it to be bypassed and opened the application up to CSRF. This could allow any admin action to be performed if an authenticated user was targeted with the CSRF. The flaw was that the referer header’s origin was not being correctly validated and as long as the path of the URL matched enough of the targeted path, the request would succeed.
So using our example from the command injection, if you are targeting “/progs/hg_cfg” the referer header would need to be “Referer: https://attacker.com/progs/hg_cfg”.
Invalid path, fails the CSRF checks.
Path which matches passes the CSRF check, regardless of the origin.
If an attacker gains access to the Admin WUI with any permissions, they can compromise the LoadMaster entirely by abusing this command injection. In addition, by combining both of these vulnerabilities together, it would be possible to target an authenticated user of the application and force them to execute commands on the LoadMaster.
This GIF demonstrates the CSRF vulnerability. Although the command execution breaks the response in the browser, we can see the command successfully executed when viewing the request in Burp Suite.
This image shows a stand alone POC for CVE-2024-2448 being used to execute a command and read “/etc/shadow”.
This post demonstrated how the vulnerabilities CVE-2024-2448 and CVE-2024-2449 in Progress Kemp LoadMaster load balancers can be combined to execute unauthorized commands, thereby compromising the security of the affected systems. These vulnerabilities highlight the potential dangers of authenticated command injection and CSRF
It is important for administrators and users of LoadMaster devices to apply the necessary patches and follow the recommended security measures provided by the vendor to mitigate these risks.
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: https://twitter.com/daveysec
02/08/2024 | CSRF reported to Progress Software. |
02/09/2024 | Command Injection report to Progress Software. |
2/26/2024 | Issues Triaged. |
3/22/2024 | Rhino was notified of the fixes. |
4/23/2024 | Rhino discloses vulnerabilities. |