CVE-2024-25633

Executive Summary

CVE-2024-25633 is a privilege escalation vulnerability in eLabFTW, an open-source electronic lab notebook. The flaw allows any authenticated regular user to create new, validated user accounts within their team, bypassing administrative controls. If anonymous access is enabled (disabled by default), unauthenticated attackers can also create accounts in any team. This vulnerability affects versions 4.4.0 through 4.9.x. The issue stems from improper authorization checks in the user creation endpoint, where the system fails to verify that the requester has the necessary administrative privileges. The CVSS score is 5.4 (Medium), reflecting the low complexity of exploitation and the potential for unauthorized account creation, which can lead to further lateral movement or data access.

Supply Chain & Package Security

eLabFTW is a PHP application distributed via GitHub and Docker. The vulnerability is in the core application code, not in a third-party package. However, organizations using eLabFTW should verify the integrity of their deployment (e.g., check Docker image hashes or Git tags) to ensure they are running a patched version.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): Low (L) – Requires a valid user account (or anonymous access).
• User Interaction (UI): None (N) – No user action needed.
• Scope (S): Unchanged (U) – The vulnerable component and impacted component are the same.
• Confidentiality (C): Low (L) – Limited information disclosure (account details).
• Integrity (I): Low (L) – Unauthorized account creation.
• Availability (A): None (N) – No impact on availability.

Threat Level: Medium. While the CVSS score is moderate, the ability to create validated accounts without authorization can be a stepping stone for more severe attacks, such as data exfiltration or privilege escalation.

Deep Dive & Mechanics

The vulnerability resides in the user registration/creation functionality. In eLabFTW, administrators can configure who is allowed to create new user accounts. The intended behavior is that only users with the sysadmin or admin role can create accounts. However, due to missing or insufficient authorization checks in the API endpoint responsible for user creation, any authenticated user (or unauthenticated user if anonymous access is enabled) can call this endpoint and create a new, validated account.

The vulnerable code path likely involves a controller or service method that handles user creation. The check for administrative privileges is either absent or incorrectly implemented, allowing the request to proceed even when the requester is a regular user. The new account is created with the validated flag set to true, meaning it can immediately log in and access the team's resources.

The attack flow:

1. Attacker logs in as a regular user (or accesses the endpoint anonymously if enabled).
2. Attacker sends a crafted HTTP request (e.g., POST to /api/users or similar) with parameters for the new user (username, email, password, team ID).
3. The server creates the account without verifying the requester's privileges.
4. The new account is immediately active, allowing the attacker to use it for further actions.

Vulnerable vs. Patched Code

The fix in version 5.0.0 adds proper authorization checks before allowing user creation. Below is a conceptual comparison.

Vulnerable Code (simplified PHP):

// In UserController.php or similar
public function createUser(Request $request) {
    $data = $request->validate([...]);
    // Missing privilege check
    $user = new User();
    $user->fill($data);
    $user->validated = true;
    $user->save();
    return response()->json($user, 201);
}

Patched Code (version 5.0.0):

// In UserController.php
public function createUser(Request $request) {
    // Added authorization check
    if (!$this->authorize('create', User::class)) {
        abort(403, 'Forbidden');
    }
    $data = $request->validate([...]);
    $user = new User();
    $user->fill($data);
    $user->validated = true;
    $user->save();
    return response()->json($user, 201);
}

The patch ensures that only users with the create ability (i.e., administrators) can access the endpoint.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an eLabFTW instance (version 4.4.0 to 4.9.x).
• Valid user credentials (or anonymous access enabled).

Exploitation Steps:

1. Obtain a session cookie or API token for a regular user.
2. Send a POST request to the user creation endpoint (e.g., /api/users or /users/create).
3. Include the required parameters: team, email, firstname, lastname, password.
4. The server responds with the new user details, including a validated account.

Example cURL command:

curl -X POST https://target-elabftw.example.com/api/users \
  -H "Content-Type: application/json" \
  -H "Cookie: elabftw_session=valid_session_cookie" \
  -d '{
    "team": 1,
    "email": "attacker@example.com",
    "firstname": "Attacker",
    "lastname": "User",
    "password": "P@ssw0rd!"
  }'

Expected Response:

{
  "id": 123,
  "email": "attacker@example.com",
  "firstname": "Attacker",
  "lastname": "User",
  "validated": true,
  "team": 1
}

Blue Team (Detection & Hardening)

Detection:

• Monitor for multiple user creation requests from a single IP or user session.
• Alert on user creation events where the creator is not an administrator.
• Review logs for API calls to user creation endpoints from non-admin users.

Hardening:

• Disable anonymous access if not required.
• Restrict user creation to administrators only via configuration.
• Implement rate limiting on user creation endpoints.
• Enable logging and audit trails for all user management actions.

Indicators of Compromise (IOCs)

• Network: HTTP POST requests to /api/users or /users/create from non-admin users.
• Logs: User creation events where created_by field is not an admin user ID.
• System: Unexpected new user accounts in the database, especially those with validated=1 and no corresponding admin action.
• File: No specific file-based IOCs; the vulnerability is logic-based.

Detection Engineering

YARA Rule

rule Detect_eLabFTW_UserCreation_Exploit {
    meta:
        description = "Detects HTTP requests attempting to exploit CVE-2024-25633 in eLabFTW"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-25633"
    strings:
        $method = "POST"
        $path1 = "/api/users"
        $path2 = "/users/create"
        $json_body = /"team"\s*:\s*\d+.*"email"\s*:\s*"[^@]+@[^"]+"/
    condition:
        $method and ($path1 or $path2) and $json_body
}

Sigma Rule

title: eLabFTW Unauthorized User Creation Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects attempts to create users in eLabFTW without proper admin privileges (CVE-2024-25633)
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem:
            - '/api/users'
            - '/users/create'
    condition: selection
falsepositives:
    - Legitimate admin user creation
level: high

Suricata Rule

alert http any any -> any any (msg:"eLabFTW Unauthorized User Creation Attempt (CVE-2024-25633)"; flow:to_server,established; content:"POST"; http_method; content:"/api/users"; http_uri; nocase; content:"team"; http_client_body; content:"email"; http_client_body; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade to eLabFTW version 5.0.0 or later.
2. If upgrade is not possible, disable anonymous access and restrict user creation to administrators only via the configuration panel.
3. Review existing user accounts for any unauthorized creations.

Long-term Measures:

• Implement regular security audits of user accounts.
• Enable multi-factor authentication (MFA) for all users.
• Monitor logs for unusual user creation patterns.
• Apply the principle of least privilege to all user roles.

Workarounds (if patching is delayed):

• Disable the "Allow administrators to create users" option in the admin panel.
• Disable anonymous access.
• Use a web application firewall (WAF) to block requests to /api/users from non-admin IPs.

Valters IT
Securing your digital future, one vulnerability at a time.