CVE-2024-51487

Executive Summary

CVE-2024-51487 is a Cross-Site Request Forgery (CSRF) vulnerability in Ampache, a web-based audio/video streaming application and file manager. The vulnerability exists in the token parsing implementation for catalog activation and deactivation actions. An attacker can craft a malicious request that, when triggered by an authenticated administrator, changes catalog states without proper CSRF token validation. This could lead to unauthorized modification of streaming library configurations, potentially disrupting service or enabling further attacks. The vulnerability is patched in Ampache version 7.0.1. No public proof-of-concept or exploit code is currently available, and the EPSS score is 0.0%, indicating low exploitation activity. However, given the administrative nature of the affected functionality, immediate patching is recommended.

Supply Chain & Package Security

Ampache is a PHP-based application typically deployed via Git or manual installation. It is not distributed through package managers like NPM, PyPI, Go, or Ruby. The vulnerability does not directly affect software supply chains, but administrators should verify the integrity of their Ampache installation and ensure they are using the official repository.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) – the victim must click a link or visit a malicious page.
• Scope: Unchanged (S:U)
• Confidentiality Impact: None (C:N)
• Integrity Impact: Low (I:L) – attacker can toggle catalog states.
• Availability Impact: None (A:N)

Threat Level: Medium. The vulnerability requires user interaction and only allows modification of catalog states, not data exfiltration or full compromise. However, in a production environment, disabling catalogs could cause denial of service for streaming content.

Deep Dive & Mechanics

The vulnerability resides in the catalog management functionality of Ampache. When an administrator activates or deactivates a catalog, the application processes a token for CSRF protection. The token parsing logic fails to properly validate the token, allowing requests without a valid token to be accepted. This is a classic CSRF vulnerability (CWE-352).

Attack Flow:

1. An attacker crafts a malicious HTML page or link that sends a POST request to the Ampache server, targeting the catalog activation/deactivation endpoint (e.g., /admin/catalog.php?action=enable_catalog&catalog_id=X).
2. The attacker lures an authenticated administrator to visit the malicious page (e.g., via phishing email or forum post).
3. The administrator's browser automatically sends the request, including their session cookies.
4. The server processes the request without validating the CSRF token, changing the catalog state.

Impact: An attacker could disable critical catalogs, causing streaming services to fail, or enable unauthorized catalogs, potentially exposing unintended content. This could also be used as a stepping stone for further attacks, such as social engineering or privilege escalation.

Vulnerable vs. Patched Code

The vulnerable code is in the token validation logic for catalog actions. In versions prior to 7.0.1, the CSRF token check is either missing or improperly implemented.

Vulnerable Code (Pre-7.0.1):

// In admin/catalog.php or similar
if ($_REQUEST['action'] == 'enable_catalog') {
    $catalog_id = intval($_REQUEST['catalog_id']);
    // Missing or weak CSRF token check
    Catalog::update_state($catalog_id, 1);
}

Patched Code (7.0.1):

// In admin/catalog.php or similar
if ($_REQUEST['action'] == 'enable_catalog') {
    // Proper CSRF token validation
    if (!Core::check_csrf_token($_REQUEST['csrf_token'])) {
        Error::add('general', T_('Invalid CSRF token'));
        return false;
    }
    $catalog_id = intval($_REQUEST['catalog_id']);
    Catalog::update_state($catalog_id, 1);
}

The patch adds a call to Core::check_csrf_token() which validates the token against the user's session. Without this check, the request is rejected.

Exploitation & Lab Setup

Red Team

Prerequisites:

• An authenticated Ampache administrator session.
• Knowledge of the target Ampache URL and catalog IDs.

Exploitation Steps:

1. Identify the target Ampache instance and obtain a valid catalog ID (e.g., by observing the admin interface).
2. Create a malicious HTML page that automatically submits a form to the vulnerable endpoint.

Example Malicious HTML:

<html>
<body>
<form action="http://target-ampache/admin/catalog.php" method="POST" id="csrf_form">
    <input type="hidden" name="action" value="enable_catalog">
    <input type="hidden" name="catalog_id" value="1">
</form>
<script>
    document.getElementById('csrf_form').submit();
</script>
</body>
</html>

3. Host the HTML page on an attacker-controlled server.
4. Send a phishing email to the administrator with a link to the malicious page.
5. When the administrator visits the page, the form is submitted, and the catalog state changes.

Note: No public exploit code is available. The above is a conceptual demonstration.

Blue Team

Detection:

• Monitor for unusual POST requests to /admin/catalog.php with parameters action=enable_catalog or action=disable_catalog.
• Look for requests lacking a valid csrf_token parameter.
• Analyze web server logs for referrer headers from unexpected domains.

Prevention:

• Ensure Ampache is updated to version 7.0.1 or later.
• Implement additional CSRF protections such as SameSite cookies (set to Lax or Strict).
• Use web application firewalls (WAF) to block requests to admin endpoints without proper tokens.
• Educate administrators about phishing risks and the importance of not clicking suspicious links while logged into Ampache.

Indicators of Compromise (IOCs)

• Network IOCs:
  • POST requests to /admin/catalog.php with action=enable_catalog or action=disable_catalog without a csrf_token parameter.
  • Referrer headers from domains not associated with the Ampache instance.
• Host IOCs:
  • Unexpected changes in catalog states in the Ampache database (table catalog).
  • Log entries in Ampache's error log indicating "Invalid CSRF token" (if patched, but may indicate attempted exploitation).
• File IOCs:
  • Presence of malicious HTML files on the server (if attacker uploaded them).

Detection Engineering

YARA Rule

rule Detect_Ampache_CSRF_Exploit {
    meta:
        description = "Detects HTTP requests targeting Ampache catalog CSRF vulnerability"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-51487"
    strings:
        $action_enable = "action=enable_catalog"
        $action_disable = "action=disable_catalog"
        $catalog_id = "catalog_id="
        $no_csrf = "csrf_token" nocase
    condition:
        (($action_enable or $action_disable) and $catalog_id) and not $no_csrf
}

Sigma Rule

title: Ampache CSRF Catalog Modification Attempt
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects POST requests to Ampache admin catalog endpoints without CSRF token
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-method: POST
        c-uri|contains: "/admin/catalog.php"
        cs-uri-query|contains|all:
            - "action=enable_catalog"
            - "catalog_id="
        cs-uri-query|contains: "csrf_token"
    condition: selection and not cs-uri-query|contains: "csrf_token"
falsepositives:
    - Legitimate admin actions with missing token (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"Ampache CSRF Catalog Modification Attempt"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/admin/catalog.php"; http.uri; content:"action=enable_catalog"; http.uri; content:"catalog_id="; http.uri; content:!"csrf_token"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Ampache to version 7.0.1 or later. This is the only official fix.
2. If immediate upgrade is not possible, implement a virtual patch using a WAF to block requests to /admin/catalog.php that do not contain a csrf_token parameter.
3. Review and rotate all administrator session tokens.

Long-Term Measures:

• Enforce the use of SameSite cookies (set to Lax or Strict) for all Ampache cookies.
• Implement additional CSRF protections such as custom headers (e.g., X-Requested-With: XMLHttpRequest) for sensitive actions.
• Conduct regular security audits of the Ampache codebase, focusing on CSRF token validation.
• Educate administrators on phishing awareness and the risks of CSRF.

Workarounds:

• No official workarounds exist. The only safe mitigation is upgrading to 7.0.1.

Valters IT
Securing Digital Frontiers