CVE-2024-27715

Executive Summary

CVE-2024-27715 is a privilege escalation vulnerability in Eskooly Free Online School Management Software version 3.0 and earlier. The flaw resides in the Password Change mechanism, allowing a remote attacker to escalate privileges by sending a crafted request. This vulnerability can lead to unauthorized access to administrative functions, data exfiltration, and potential full system compromise. No official patch has been released, and the CVSS score is currently unassigned (0.0). The EPSS score is 0.0%, indicating low exploitation probability at this time, but the lack of a patch makes it a significant risk for organizations using this software.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (Unassigned)
• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality (C): High (H)
• Integrity (I): High (H)
• Availability (A): High (H)
• Threat Level: Critical (based on impact, despite unassigned score)

Deep Dive & Mechanics

The vulnerability exists in the password change functionality of Eskooly. The application fails to properly validate the current user's session or authorization level when processing password change requests. By manipulating parameters in the HTTP request (e.g., user ID, token, or role), an attacker can change the password of any user, including administrators, without proper authentication. This allows a low-privileged user or an unauthenticated attacker to escalate privileges to admin level.

The core issue is a lack of server-side authorization checks. The application likely relies on client-side controls or insufficient session validation, making it susceptible to parameter tampering.

Vulnerable vs. Patched Code

No patched version is available. The vulnerable code likely resembles:

// Vulnerable: No check if the current user is allowed to change the target user's password
if (isset($_POST['change_password'])) {
    $user_id = $_POST['user_id'];
    $new_password = $_POST['new_password'];
    // Directly update password without verifying authorization
    $query = "UPDATE users SET password = '$new_password' WHERE id = $user_id";
    mysqli_query($conn, $query);
}

A patched version would include:

// Patched: Verify the current user's session and authorization
session_start();
if (isset($_POST['change_password'])) {
    $current_user_id = $_SESSION['user_id'];
    $target_user_id = $_POST['user_id'];
    // Ensure the current user is either admin or changing their own password
    if ($_SESSION['role'] == 'admin' || $current_user_id == $target_user_id) {
        $new_password = password_hash($_POST['new_password'], PASSWORD_DEFAULT);
        $query = "UPDATE users SET password = ? WHERE id = ?";
        $stmt = mysqli_prepare($conn, $query);
        mysqli_stmt_bind_param($stmt, "si", $new_password, $target_user_id);
        mysqli_stmt_execute($stmt);
    } else {
        die("Unauthorized");
    }
}

Exploitation & Lab Setup

Red Team

1. Setup: Deploy Eskooly v3.0 in a lab environment (e.g., using XAMPP on a local VM).
2. Recon: Identify the password change endpoint (e.g., /change_password.php).
3. Craft Request: Use Burp Suite or cURL to intercept and modify the password change request. Change the user_id parameter to an admin user's ID (e.g., 1).
4. Execute: Send the crafted request with a new password for the admin account.
5. Escalate: Log in with the admin account using the new password.

Example cURL command:

curl -X POST http://target/change_password.php \
  -d "user_id=1&new_password=hacked123&confirm_password=hacked123"

Blue Team

1. Monitor: Look for unusual password change requests, especially those with different user_id values than the logged-in user.
2. Log Analysis: Check web server logs for multiple password change attempts from the same IP or to multiple user IDs.
3. Harden: Implement server-side authorization checks immediately. Use prepared statements to prevent SQL injection.
4. WAF Rules: Deploy a Web Application Firewall (WAF) rule to block requests where the user_id parameter does not match the session user ID (unless admin).

Indicators of Compromise (IOCs)

• Network: HTTP POST requests to /change_password.php with parameters user_id and new_password.
• Logs: Multiple password change events for different users from the same source IP.
• System: New admin accounts or unexpected password changes for existing admin accounts.
• File: Modified user database entries (e.g., users table) with altered password hashes.

Detection Engineering

YARA Rule

rule CVE_2024_27715_Eskooly_PrivEsc {
    meta:
        description = "Detects exploitation attempts of CVE-2024-27715 in Eskooly"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-27715"
    strings:
        $s1 = "change_password.php" ascii nocase
        $s2 = "user_id=" ascii nocase
        $s3 = "new_password=" ascii nocase
    condition:
        all of them
}

Sigma Rule

title: Eskooly Privilege Escalation via Password Change
id: 8f4a3b2c-1d5e-6f7a-8b9c-0d1e2f3a4b5c
status: experimental
description: Detects exploitation of CVE-2024-27715 by monitoring for password change requests with mismatched user IDs.
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: POST
        cs-uri-stem: '/change_password.php'
        cs-uri-query|contains: 'user_id='
    condition: selection
falsepositives:
    - Legitimate admin password changes for other users
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-27715 Eskooly Privilege Escalation Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/change_password.php"; http_uri;
    content:"user_id="; http_client_body;
    content:"new_password="; http_client_body;
    sid:1000001;
    rev:1;
    reference:cve,2024-27715;
)

Remediation & Mitigation

• Immediate: Disable the password change functionality if not essential, or restrict access to authenticated users only.
• Short-term: Implement server-side authorization checks to ensure the requesting user has permission to change the target user's password.
• Long-term: Upgrade to a patched version once released by the vendor. If no patch is forthcoming, consider migrating to an alternative school management solution.
• Compensating Controls: Use a Web Application Firewall (WAF) to block suspicious password change requests. Enable detailed logging and monitoring for password change events.

Valters IT
Securing Digital Frontiers