CVE-2024-36676

Executive Summary

CVE-2024-36676 is a vulnerability in BookStack, an open-source platform for organizing and storing information. The flaw resides in the application's access control mechanisms, specifically affecting public-facing forms. An unauthenticated attacker can exploit this to confirm the existence of registered users on the system and launch a targeted denial-of-service (DoS) attack by flooding those users with notification emails. This vulnerability has a CVSS score of 0.0 (pending official analysis), but based on the description, it represents a moderate risk due to information disclosure and potential service disruption. The attack vector is network-based, requires no authentication, and has low complexity, making it easily exploitable. The vendor has released a patch in version 24.05.1.

Supply Chain & Package Security

BookStack is a PHP application built on the Laravel framework. The vulnerability is not directly in a package dependency but in the application's own access control logic. However, the application relies on Composer for PHP package management. Users should ensure that all dependencies are up-to-date and that the application is not running with unnecessary packages that could expand the attack surface. The primary supply chain risk is the use of outdated or vulnerable third-party libraries, though this specific CVE is in the core application code.

CVSS Breakdown & Threat Level

While the official CVSS score is 0.0 (unassigned), a reasonable assessment based on the vulnerability description is:

• Attack Vector (AV): Network (N) - Exploitable remotely.
• Attack Complexity (AC): Low (L) - No special conditions required.
• Privileges Required (PR): None (N) - No authentication needed.
• User Interaction (UI): None (N) - No user action required for exploitation.
• Scope (S): Unchanged (U) - The vulnerable component and the impacted component are the same.
• Confidentiality (C): Low (L) - Confirmation of user existence is a minor information leak.
• Integrity (I): None (N) - No data modification.
• Availability (A): Low (L) - Targeted email DoS can degrade service for specific users.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L Estimated Base Score: 5.4 (Medium)

Threat Level: Medium. The vulnerability allows for user enumeration and targeted DoS, which can be used as a precursor to more sophisticated attacks (e.g., password spraying, social engineering).

Deep Dive & Mechanics

The vulnerability stems from improper access control checks on public-facing forms within BookStack. These forms, such as registration or password reset requests, are designed to be accessible without authentication. However, the application fails to adequately validate whether the user submitting the form is authorized to perform the action or whether the action should be rate-limited.

Mechanism:

1. An attacker sends a request to a public-facing form endpoint (e.g., /password/email or /register).
2. The attacker provides an email address or username that they wish to verify.
3. The application, due to missing or incorrect access control, processes the request and returns a response that differs based on whether the user exists (e.g., "Email sent" vs. "User not found").
4. This allows the attacker to build a list of valid user accounts.
5. The attacker can then repeatedly submit the same form for a known user, causing the application to send multiple notification emails (e.g., password reset links) to that user's email address, effectively performing a targeted email DoS.

The root cause is a missing $this->authorize() or similar permission check in the controller handling the form submission. The application should verify that the user is allowed to perform the action, even for public forms, by implementing rate limiting and ensuring that the response does not leak user existence.

Vulnerable vs. Patched Code

The vulnerability is in the controller logic for public forms. The following is a conceptual comparison.

Vulnerable Code (Pre-v24.05.1):

// In a controller handling password reset requests
public function sendResetLinkEmail(Request $request)
{
    $this->validate($request, ['email' => 'required|email']);

    // Missing authorization check
    // $this->authorize('sendPasswordResetLink');

    $user = User::where('email', $request->email)->first();

    if ($user) {
        // Send password reset email
        Mail::to($user->email)->send(new PasswordResetLink($user));
        return response()->json(['message' => 'Reset link sent.']);
    } else {
        return response()->json(['message' => 'User not found.']);
    }
}

Patched Code (v24.05.1):

// In a controller handling password reset requests
public function sendResetLinkEmail(Request $request)
{
    $this->validate($request, ['email' => 'required|email']);

    // Added authorization check
    $this->authorize('sendPasswordResetLink');

    // Rate limiting to prevent DoS
    $key = 'password-reset:' . $request->ip();
    if (RateLimiter::tooManyAttempts($key, 5)) {
        return response()->json(['message' => 'Too many attempts.'], 429);
    }
    RateLimiter::hit($key, 60);

    // Generic response to prevent user enumeration
    $user = User::where('email', $request->email)->first();
    if ($user) {
        Mail::to($user->email)->send(new PasswordResetLink($user));
    }

    // Always return the same message
    return response()->json(['message' => 'If the email exists, a reset link has been sent.']);
}

The patched code adds an authorization gate, implements rate limiting, and returns a generic response regardless of whether the user exists, thus preventing both user enumeration and email DoS.

Exploitation & Lab Setup

Red Team

Objective: Confirm user existence and perform targeted email DoS.

Prerequisites:

• A target BookStack instance running a version prior to v24.05.1.
• A list of potential email addresses or usernames to test.

Steps:

1. User Enumeration:

   • Send a POST request to the password reset endpoint (e.g., /password/email).
   • Payload: email=test@example.com
   • Observe the response. If the response is "Reset link sent.", the user exists. If "User not found.", the user does not exist.
   • Repeat for a list of emails to build a user database.

   # Example using curl
   curl -X POST https://target.bookstack.local/password/email \
     -H "Content-Type: application/json" \
     -d '{"email": "admin@example.com"}'
   

2. Targeted Email DoS:

   • Once a valid user is identified, repeatedly send the password reset request for that user.
   • This will cause the application to send multiple password reset emails to the victim's inbox, potentially overwhelming their email and causing service disruption.

   # Example using a loop
   for i in {1..100}; do
     curl -X POST https://target.bookstack.local/password/email \
       -H "Content-Type: application/json" \
       -d '{"email": "admin@example.com"}'
   done
   

Blue Team

Detection:

• Monitor for a high volume of requests to public-facing form endpoints (e.g., /password/email, /register) from a single IP address.
• Look for patterns of requests with different email addresses followed by repeated requests for a single email address.
• Alert on HTTP 429 (Too Many Requests) responses if rate limiting is partially implemented.

Mitigation:

• Immediately upgrade BookStack to v24.05.1 or later.
• Implement Web Application Firewall (WAF) rules to rate-limit requests to sensitive endpoints.
• Monitor email server logs for a sudden spike in password reset or notification emails.
• Use CAPTCHA on public forms to prevent automated abuse.

Indicators of Compromise (IOCs)

• Network:

  • High volume of POST requests to /password/email, /register, or similar endpoints from a single IP.
  • Requests containing a large number of distinct email addresses in a short period.
  • Repeated requests for the same email address to the password reset endpoint.

• Host:

  • Application logs showing multiple "Reset link sent." or "User not found." responses from the same IP.
  • Email server logs showing a high volume of password reset emails sent to a single recipient.

• File:

  • No specific file-based IOCs.

Detection Engineering

YARA Rule

rule Detect_BookStack_User_Enumeration_Attempts {
    meta:
        description = "Detects potential user enumeration attempts against BookStack CVE-2024-36676"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-36676"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $s1 = "password/email" ascii wide nocase
        $s2 = "register" ascii wide nocase
        $s3 = "Reset link sent." ascii wide nocase
        $s4 = "User not found." ascii wide nocase
    condition:
        any of ($s1, $s2) and any of ($s3, $s4)
}

Sigma Rule

title: BookStack User Enumeration via Public Forms
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects multiple requests to BookStack public forms with different email addresses, indicating user enumeration.
author: Valters IT
date: 2024/01/01
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-36676
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem:
            - '/password/email'
            - '/register'
    condition: selection
    timeframe: 5m
    aggregation:
        - field: c-ip
          function: distinct_count
          value: cs-uri-query
          condition: gt 10
falsepositives:
    - Legitimate users with multiple email addresses
level: medium

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"CVE-2024-36676 BookStack User Enumeration Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/password/email"; http_uri;
    content:"email"; http_client_body;
    pcre:"/email=[^&]+/";
    threshold: type both, track by_src, count 10, seconds 300;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update BookStack to version 24.05.1 or later. This is the only complete fix.
2. Rate Limiting: If immediate upgrade is not possible, implement rate limiting at the web server or WAF level for the /password/email and /register endpoints.
3. CAPTCHA: Add CAPTCHA challenges to public forms to prevent automated requests.

Long-Term Measures:

1. Access Control Review: Conduct a thorough review of all public-facing endpoints to ensure proper authorization checks are in place.
2. Generic Error Messages: Ensure that all public forms return generic success/failure messages that do not reveal user existence.
3. Monitoring: Implement logging and alerting for unusual patterns of requests to sensitive endpoints.
4. Security Audits: Regularly perform security audits and penetration testing on the application.

Workaround (if patching is delayed):

• Disable public registration if not required.
• Use a reverse proxy (e.g., Nginx) to block or rate-limit requests to the vulnerable endpoints.

# Nginx rate limiting example
limit_req_zone $binary_remote_addr zone=bookstack:10m rate=5r/m;

location /password/email {
    limit_req zone=bookstack burst=3 nodelay;
    proxy_pass http://bookstack_backend;
}

Report generated by Valters IT DevSecOps & CTI Framework