Countersoft Gemini 7.5.0 SQL Injection

Evidence #

During the analysis of the application Countersoft Gemini (version 7.5.0 available publicly on GitHub), I found an authenticated SQL Injection vulnerability within the Search feature, in particular inside the HTTP POST parameter filterForm of the endpoint /workspace/<ID>/items/executefilter.

Normally, visiting the dashboard of the Gemini web application, low-privileged users are able to use the Search feature to filter various items found on the platform.

As an example, the figure below shows the HTTP request automatically sent by the browser when the user performs this search.

As demonstrated above, a single HTTP parameter named filterForm contains several sub-parameters; the searched text is found inside Keywords-T. Analyzing the other sub-parameters, I noticed that the value of the Sort field is directly used inside an SQL statement, as demonstrated below.

The value placed in the Sort field is reflected in two different points:

• as the name of the database table at the start of the statement
• before the end of the statement.

To be more specific, the function that handles this value is named Generate and can be found inside the IssueRepository class of the Countersoft.Gemini.Data.Issues namespace (DLL file Countersoft.Gemini.Data.dll).

Upon further analysis of the application, I noticed that it does not accept every character. As an example, the SQL statement could not be interrupted through a comment ("--" syntax), as the server rejected it.

Since the input value is reflected two times inside the SQL statement, attempting to inject a malicious payload would create an invalid query. To solve this problem, I developed a specially crafted payload to account for the double injection.

Moreover, I noticed that the semicolon (";") character is not blacklisted by the vulnerable function, therefore, it is possible to inject new SQL statements such as UPDATE or DELETE ones. These statements may allow an attacker to modify the data stored inside the database or, alternatively, delete all the tables.

For example, the figure below demonstrates the execution of a time-based payload based on the WAITFOR DELAY statement causing a delay of 20 seconds.

Checking the data saved inside the database, I noticed that the gemini_users table contains a field named apikey, which stores the API keys of the platform users. This key could be used by an attacker to interact with the API endpoints exposed by the application, thus impersonating the victim user.

The screenshot above shows the contents of the database table gemini_users inside the environment used for the tests.

Successively, I attempted to create a payload that could send this information towards an attacker-controller server. To perform this operation, I decided to use a known stored procedure allowing DNS exfiltration, named xp_dirtree.

The following screenshot demonstrates the value obtained through the aforementioned technique.

The value shown in the previous figure represents the API key of the testing user marco.polo , prepended as a fourth-level domain name. Furthermore, based on the official documentation, there exists an API endpoint which allows administrators to read the current configuration of the platform, including a field named ActiveDirectoryPassword.

An attacker may abuse the SQL Injection (SQLi) vulnerability in order to retrieve all the API keys, access this endpoint, and steal the credentials of the Active Directory (AD) account linked to the application.

Additionally, this weakness may be abused, depending on the privileges of the database user, to execute arbitrary commands on the remote system by means of the stored procedure xp_cmdshell, which is disabled by default.

Follows two screenshots demonstrating the execution of a malicious payload that re-enables the aforementioned stored procedure, executes a simple whoami command, and writes its output into a text file stored in the C:\Gemini directory.

Once the forged HTTP request was sent to the server, I noticed that the file pwned.txt was created successfully on the victim host.

Given the evidence above, abusing the SQL Injection vulnerability I was able to obtain Remote Code Execution (RCE) on the underlying system of the database. If an attacker took advantage of this weakness, they could execute malicious commands on the server hosting the database instance, therefore, increasing the attack surface and the associated security risk.

Vulnerability Disclosure Timeline #