CVE-2024-23335

Executive Summary

CVE-2024-23335 is a medium-severity vulnerability in MyBB, a free and open-source forum software. The flaw resides in the backup management module of the Admin Control Panel (Admin CP). An authenticated administrator with access to the backup management feature can specify .htaccess as the name of a backup file to be deleted. This action can inadvertently remove the .htaccess file that Apache web servers use to restrict direct HTTP access to the backup directory. Once this protective file is removed, previously stored backup files (which may contain sensitive database dumps and user data) become accessible over HTTP to any unauthenticated user. The vulnerability is patched in MyBB version 1.8.38. No public proof-of-concept (PoC) code or exploit is currently available, and the EPSS score is 0.0%, indicating a very low probability of active exploitation in the wild.

Supply Chain & Package Security

MyBB is a PHP-based application distributed as a zip archive from its official website and GitHub repository. The vulnerability does not directly affect a package manager (NPM, PyPI, Go, Ruby). However, administrators should verify the integrity of their MyBB installation by checking file hashes provided by the vendor. The supply chain risk is low, as the vulnerability is patched in the latest release and no malicious code has been reported.

CVSS Breakdown & Threat Level

• CVSS Score: 4.7 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:L
• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): High – An attacker must have administrator-level access to the Admin CP.
• User Interaction (UI): None – No user action is needed.
• Scope (S): Unchanged – The exploit does not affect other components.
• Confidentiality (C): Low – Backup files may contain sensitive data.
• Integrity (I): None – No data modification is possible.
• Availability (A): Low – The .htaccess file is deleted, potentially exposing backups.

Threat Level: Medium. The requirement for admin privileges reduces the likelihood of exploitation, but the potential exposure of sensitive backup data makes it a significant risk for affected forums.

Deep Dive & Mechanics

The vulnerability is rooted in insufficient input validation within the backup management module. The module allows administrators to delete backup files by specifying a filename. The code does not properly sanitize or restrict the filename parameter, allowing an attacker to pass .htaccess as the value. When the deletion routine executes, it removes the .htaccess file from the backup directory (/admin/backups/ by default). On Apache servers, this file typically contains directives like:

Deny from all

This directive prevents direct HTTP access to the directory. Once deleted, any file in the backup directory (e.g., backup_2024-01-01.sql) becomes accessible via a direct URL like https://example.com/admin/backups/backup_2024-01-01.sql. An unauthenticated attacker can then download these files, potentially gaining access to the entire database, including user credentials, private messages, and other sensitive data.

The vulnerability is classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), as the application fails to restrict the path to a safe directory, allowing deletion of files outside the intended scope.

Vulnerable vs. Patched Code

Vulnerable Code (MyBB < 1.8.38):

In the file admin/modules/tools/backupdb.php, the deletion logic likely resembles:

$filename = $mybb->input['filename'];
if (file_exists(MYBB_ADMIN_DIR . 'backups/' . $filename)) {
    unlink(MYBB_ADMIN_DIR . 'backups/' . $filename);
}

No validation is performed to ensure the filename is a valid backup file (e.g., ending in .sql or .gz). The path is directly concatenated, allowing traversal or arbitrary file deletion.

Patched Code (MyBB 1.8.38):

The patched version introduces a whitelist check:

$filename = $mybb->input['filename'];
$allowed_extensions = array('sql', 'gz', 'zip');
$extension = pathinfo($filename, PATHINFO_EXTENSION);
if (!in_array($extension, $allowed_extensions)) {
    // Reject the request
    flash_message($lang->error_invalid_backup_file, 'error');
    admin_redirect('index.php?module=tools-backupdb');
}
if (file_exists(MYBB_ADMIN_DIR . 'backups/' . $filename)) {
    unlink(MYBB_ADMIN_DIR . 'backups/' . $filename);
}

Additionally, the .htaccess file is now regenerated after any deletion to ensure protection is restored.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Valid admin credentials for the MyBB Admin CP.
• Network access to the target server.

Steps:

1. Log in to the Admin CP.
2. Navigate to Tools & Maintenance > Backup Database.
3. In the "Delete a Backup" section, enter .htaccess as the filename.
4. Submit the deletion request.
5. Verify the .htaccess file is removed by attempting to access https://target.com/admin/backups/.
6. If successful, download any backup files present (e.g., backup_2024-01-01.sql).

Lab Setup:

• Install MyBB 1.8.37 on an Apache server with PHP.
• Create a backup file via the Admin CP.
• Ensure the /admin/backups/ directory has an .htaccess file with Deny from all.

No public exploit code is available.

Blue Team

Detection:

• Monitor Admin CP access logs for unusual backup deletion requests, especially those with filename=.htaccess.
• Alert on any successful deletion of .htaccess files in the /admin/backups/ directory.
• Use file integrity monitoring (FIM) to detect changes to .htaccess files.

Hunting:

• Search web server logs for requests to /admin/backups/ followed by direct access to backup files.
• Look for HTTP 200 responses to requests for .sql or .gz files in the backup directory.

Mitigation:

• Immediately upgrade to MyBB 1.8.38.
• If upgrade is not possible, manually restore the .htaccess file with Deny from all and restrict write permissions to the backup directory.
• Implement a Web Application Firewall (WAF) rule to block requests with filename=.htaccess in the Admin CP.

Indicators of Compromise (IOCs)

• File Deletion: Absence of .htaccess in /admin/backups/.
• Network Traffic: HTTP requests to /admin/backups/*.sql or /admin/backups/*.gz from external IPs.
• Log Entries: Admin CP access logs showing filename=.htaccess in POST requests to index.php?module=tools-backupdb.
• File Hashes: Backup files with MD5 hashes that match known database dumps.

Detection Engineering

YARA Rule

rule CVE_2024_23335_MyBB_Backup_Deletion {
    meta:
        description = "Detects attempts to delete .htaccess via MyBB backup module"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-23335"
    strings:
        $s1 = "filename=.htaccess" ascii wide nocase
        $s2 = "tools-backupdb" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: MyBB Backup Module .htaccess Deletion Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to delete the .htaccess file via the MyBB backup management module.
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-23335
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: POST
        cs-uri-query|contains: 'index.php?module=tools-backupdb'
        cs-uri-query|contains: 'filename=.htaccess'
    condition: selection
falsepositives:
    - Legitimate admin actions (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-23335 MyBB Backup Module .htaccess Deletion Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"index.php?module=tools-backupdb"; http_uri;
    content:"filename=.htaccess"; http_client_body;
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update MyBB to version 1.8.38 or later. This is the only complete fix.
2. Restore .htaccess: If the file was deleted, recreate it in /admin/backups/ with the following content:

   Deny from all
   

3. Verify Backups: Check if any backup files were accessed by reviewing server access logs.

Long-Term Measures:

• Implement strict file permissions on the backup directory (e.g., chmod 700).
• Use a Web Application Firewall (WAF) to block malicious requests.
• Regularly audit Admin CP access logs for suspicious activity.
• Enable file integrity monitoring (FIM) for critical directories.

Workarounds:

• If upgrading is not possible, manually restrict the backup deletion functionality by editing the PHP code to whitelist allowed file extensions (as shown in the patched code section).

Valters IT
Securing Digital Frontiers