Overview
SonicWall Capture Labs threat research team became aware of the threat CVE-2024-36412, assessed its impact and developed mitigation measures for this vulnerability.
CVE-2024-36412 is a critical vulnerability affecting SuiteCRM, an open-source Customer Relationship Management (CRM) software developed by SalesAgility. Present in versions prior to 7.14.4 and 8.6.1, this flaw involves improper neutralization of user-supplied input in SQL commands, enabling attackers to perform SQL injection attacks. While the vulnerability could theoretically allow unauthorized manipulation of the database such as accessing, modifying or deleting sensitive data, the practical exploitation scenario tested primarily demonstrated a JavaScript XSS blind SQL injection. In our testing, queries like SELECT LOAD_FILE(‘/etc/passwd’) were executed in memory but did not return output due to the absence of code in responseEntryPoint.php to display the data. The issue, associated with CWE-89, has a maximum CVSS base score of 10.0 and an EPSS probability of 4.62%, placing it in the 93rd percentile of likely-to-be-exploited vulnerabilities. Versions 7.14.4 and 8.6.1 include patches to mitigate this vulnerability. Users are strongly encouraged to update their systems to secure against potential exploitation. For additional information, refer to the advisory published by SalesAgility on GitHub.
Technical Overview
The provided code (Figure 1) and related functions—clean_incoming_data(), securexss(), and securexsskey()—are designed to mitigate the risk of Cross-Site Scripting (XSS) and other injection-based attacks by sanitizing both the keys and values of incoming request data. clean_incoming_data() applies XSS filters to user inputs in the following super global variables $_REQUEST, $_POST, and $_GET, then utilizes clean_string() and related logic to further scrub parameters like login_theme or module based on predefined character sets. At the same time, securexss() focuses on transforming potentially dangerous strings by replacing HTML-special characters and javascript: substrings to reduce the risk of malicious scripts executing within the application. Additionally, securexsskey() ensures that parameter names themselves do not contain harmful characters, thereby preventing attackers from launching sophisticated XSS vectors that rely on tainted keys.
Figure 1: clean_incoming_data()
Despite these measures, the sanitization routines (Figure 2) primarily target malicious HTML, JavaScript and other client-side injection techniques. They do not thoroughly address SQL injection risks. As shown in the javascript:” payload scenario (Figure 3), although the code successfully disrupts the javascript: substring and encodes potentially dangerous characters, it fails to detect or remove appended SQL commands hidden after the sanitized portion. In a blind SQL injection attack, an attacker leverages these remaining SQL statements to manipulate the application’s underlying database queries, often by introducing sleep functions or other database operations that produce measurable timing differences.
Figure 2: securexss() w/preg_replace()
The existing code provides a substantial defense against traditional XSS attacks, especially through its integration with the AntiXSS engine, which removes dangerous attributes like style and onerror it does not fully neutralize payloads that blend JavaScript-like strings with hidden SQL injection vectors. Although the xss_clean() method offered by the AntiXSS library effectively sanitizes HTML and script inputs, it is not designed to detect or remove SQL commands embedded deep within user-provided strings. To comprehensively mitigate such blind SQL injection threats, developers should augment their XSS-focused measures with robust server-side parameterization and secure database handling. This multi-pronged approach, combining the strengths of AntiXSS filters with proper SQL sanitization, ensures a far more resilient defense against a broad spectrum of injection-based attacks.
Triggering the Vulnerability
The vulnerability requires the attacker to craft an input parameter that initially appears to be a JavaScript-based XSS payload but actually contains embedded SQL injection code. This combination requires the following steps.
- Include a javascript: substring followed by encoded or disguised SQL statements in the query parameter.
- Make use of the delegate parameter or another accepted parameter to carry the payload, such as javascript:” +AND+(SELECT…).
- Access the vulnerable endpoint (e.g., index.php) with carefully constructed GET parameters that combine disarmed JavaScript with appended SQL injection code.
- Observe timing delays or response changes in the application’s behavior, indicating successful execution of the injected SQL commands.
Exploitation
The demonstration in Figure 3, we leverage Burp Suite to exploit the identified vulnerability by sending a specially crafted GET request to the target endpoint. By inserting a malicious payload into a parameter that initially appears related to JavaScript functionality, we can bypass the XSS-focused sanitization layers. This payload includes hidden SQL commands that the server’s input filtering fails to remove, resulting in a blind SQL injection scenario. With Burp Suite’s capabilities, we intercept and modify the request in real-time, analyze the server’s responses, and observe timing differences that confirm successful execution of the injected queries.
Figure 3: JavaScript XSS Blind SQL Injection Demonstration
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:
- IPS: 20542 SuiteCRM JavaScript XSS Blind SQL Injection
Remediation Recommendations
To mitigate or eliminate the risks posed by this vulnerability, consider implementing the following measures:
- Remove or replace any hard-coded credentials within the codebase.
- Utilize up-to-date Intrusion Prevention Service (IPS) signatures to effectively filter network traffic.
- Restrict user permissions by following the principle of least privilege to prevent unnecessary high-level access.
- Regularly update and patch systems, including both the application and its dependencies, to address and prevent known vulnerabilities.
