CVE-2021-43609: CVE-2021-43609 Write-up

Flashback time! This technical blog post looks at one of the early vulnerabilities uncovered by the Division 5 research program. The team undertook research into the Spiceworks Help Desk application. The following write-up is from the researcher on this vulnerability: Aidan Stansfield.

About Spiceworks Help Desk Server

This application comes in both an on-premises and cloud hosted package. Due to the Spiceworks terms of use, I performed my research upon the on-premises application, so that I was only attacking my own infrastructure and data.

The on-premises application is called Spiceworks Help Desk Server (HDS), and is packaged into an Open Virtual Appliance (OVA) file that can be run with various virtualisation technologies. The main purpose of the application is to facilitate IT support, allowing users to submit ‘tickets’ to the help desk such that an agent can look at the ticket and provide appropriate help to the user.

Exploring inside the OVA file, I located the Spiceworks HDS application and found it to be a Ruby on Rails application. This was great news as it simplified the vulnerability research process since the source code is provided and does not need to be decompiled.

Identifying SQL Injection

While performing source code review, I identified a SQL Injection vulnerability in:

The vulnerable function, order_by_for_ticket can be found below (with some irrelevant code removed for the sake of brevity). The purpose of this function is to order a list of tickets based upon a specific column and direction (e.g., order the tickets by the date submitted).

Here we see that if the attacker can control the ‘order’ and ‘dir’ parameters to this function, then they can control the SQL that is passed to the ‘@scope.order’ function. This can be abused to perform Blind Boolean SQL injection.

Path from Request to Vulnerable Function

Before delving into the SQL injection, it’s important to first see where and how this function is called.

Checking for references to this function, we see it is called by the order_by function as defined below:

The normalize_order function takes an order object and normalizes it into the format ['sort’, ‘direction’]. It does this by splitting the order objects on spaces or hyphens, which we will keep a note of for later. The order_by function is called from within the index function of the /opt/tron/embedded/service/tron-rails/app/controllers/api/tickets_controller.rb file, which defines the /api/tickets route. This function can be seen below:

To summarise, the SQL injection can be reached by requesting the /api/tickets endpoint with a sort query string parameter. This will call the order_by function, which normalises the sort query string parameter to extract the column name and direction, before passing them over to the vulnerable order_by_for_ticket function. This means that any agent or admin user is able to execute this SQL injection.

Executing SQL Injection

By adding some debug statements into the source code, it was possible to identify the underlying SQL query that is run. Requesting the /api/tickets?sort=order+direction+junk endpoint, we see the following SQL statement is made:

Note that ‘junk’ does not appear anywhere within the SQL statement. This is because the normalize_order function splits the sort query string parameter based upon spaces or hyphens, and assigns the first two items to the order and direction respectively. Therefore, we cannot use spaces or hyphens in our payload. To get around this, we can replace spaces with SQL comments (e.g., /**/). Requesting /api/tickets?sort=order/**/direction/**/junk results in the following SQL statement:

Notice that ‘junk’ now appears within the payload, and a default direction of ‘asc’ is assigned since our payload did not contain any spaces or hyphens. Since we only control the ORDER BY parameter, we cannot simply leak arbitrary database results directly into the page. However, as alluded to earlier, we can achieve Blind Boolean based injection to leak arbitrary data. Consider the following SQL statement:

When $condition is true, the select case statement will return 1, and so the results will be ordered by the 1st column. When $condition is false however, the select case statement will return 1/(SELECT 0), which will cause a division by zero error within the database and cause the application to return a 500 internal server error.

For example, setting the condition to 1=1 will return true, and a 200 response code:

Whereas setting the condition to 1=2 will return false, and a 500 response code:

Escalating to RCE

Since the database user possesses ‘super’ privileges, this SQL injection can be used to read arbitrary local files with the pg_read_file PostgreSQL command. A particular file of interest is the environment configuration file, which details all of the environment variables and secrets used by the Rails application. This file can be found at the following location: /var/opt/tron/etc/env.

Included in this configuration is the secret_key_base, which is a secret used to sign all serialized cookies. Once the secret_key_base is leaked from the environment configuration, an attacker can send specially crafted requests and gain remote code execution through deserialization of signed malicious data.

The ability to force a Rails application to deserialize arbitrary code after the disclosure of the secret_key_base is considered part of the intended internal functionalities of Rails applications and is not a separate vulnerability within the Spiceworks codebase. For technical discussion of this technique and why it is considered an intended internal functionality, see the below disclosure:

• https://hackerone.com/reports/473888

Extending upon the information provided within that report, the following payload can be used to send a reverse shell to back to an attacker once the secret_base_key is known.

The Fix

The order_by_for_ticket function has been patched in Spiceworks HDS version 1.3.3 by enforcing the ‘order’ and ‘dir’ parameters to be one of various set options, as can be seen below:

Summary

CVE-2021-43609 allows an authorised remote attacker to exploit a Blind Boolean SQL injection to read arbitrary data and files, leading to RCE through deserialization techniques inherent to Ruby on Rails. Spiceworks HDS versions < 1.3.3 are vulnerable. A proof of concept (POC) exploit can be found at CVE-2021-43609-POC. An example of the entire exploit chain can be found below:

Disclosure Timeline

• 02/09/2021 - Vulnerability identified

• 08/09/2021 - Initial reach out to Spiceworks Ziff Davis

• 23/09/2021 - Spiceworks Ziff Davis first response

• 23/09/2021 - Vulnerability is reported

• 30/10/2021 - Spiceworks Ziff Davis advises the vulnerability has been remediated

• 13/11/2021 - CVE-2021-43609 is assigned