CVE-2024-51489

Executive Summary

CVE-2024-51489 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 user-to-user messaging, allowing an attacker to forge requests that can send messages to any user, including administrators, without proper CSRF token validation. This can be exploited when a victim interacts with a malicious link or page. The issue is fully addressed 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 at this time.

Supply Chain & Package Security

Ampache is a PHP-based application typically deployed via Git or manual installation. There is no official NPM, PyPI, Go, or Ruby package for Ampache. The vulnerability is in the core application code, not in a third-party dependency. Users should verify the integrity of their Ampache installation by checking the source code against 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) – The attack can be launched remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication needed to trigger the CSRF.
• User Interaction: Required (UI:R) – The victim must click a link or visit a malicious page.
• Scope: Unchanged (S:U) – The vulnerable component and the attacker’s target are the same.
• Confidentiality Impact: None (C:N) – No data exposure.
• Integrity Impact: Low (I:L) – An attacker can send messages on behalf of the victim.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: Medium. While the CVSS score is moderate, the ability to send messages to administrators could be leveraged for social engineering or further attacks.

Deep Dive & Mechanics

The vulnerability resides in the messaging functionality of Ampache. When a user sends a message to another user, the application uses a CSRF token to prevent cross-site request forgery. However, the token parsing logic does not properly validate the token’s origin or integrity. Specifically, the application fails to verify that the token matches the current session or that it was generated by the server for the intended action.

An attacker can craft a malicious HTML page or link that, when visited by an authenticated Ampache user, triggers a forged request to send a message to any user (e.g., an administrator). The request includes a CSRF token that is either missing, invalid, or reused from a previous session. Because the server does not adequately validate the token, the request is processed, and the message is sent.

The attack flow:

1. Attacker identifies a target Ampache instance and a victim user (e.g., an admin).
2. Attacker crafts a malicious page containing a form or JavaScript that sends a POST request to the Ampache messaging endpoint.
3. The victim, authenticated to Ampache, visits the malicious page.
4. The browser automatically sends the forged request with the victim’s session cookie.
5. The server processes the request due to insufficient CSRF token validation, sending a message from the victim to the attacker’s chosen recipient.

Vulnerable vs. Patched Code

Vulnerable Code (pre-7.0.1): The CSRF token validation likely checks only for the presence of a token, not its validity. For example:

// Vulnerable: Only checks if token exists
if (isset($_POST['csrf_token'])) {
    // Process message
}

Patched Code (7.0.1): The fix adds proper validation, ensuring the token matches the session and is not reused:

// Patched: Validates token against session
if (isset($_POST['csrf_token']) && $_POST['csrf_token'] === $_SESSION['csrf_token']) {
    // Process message
} else {
    // Reject request
}

The exact patch can be found in the Ampache GitHub repository commit history for version 7.0.1.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A running Ampache instance (version < 7.0.1) with at least one authenticated user.
• A victim user who will click a malicious link.

Exploitation Steps:

1. Identify the messaging endpoint (e.g., /messages.php?action=send).
2. Craft a malicious HTML page that auto-submits a form to this endpoint:

<html>
<body>
<form id="csrf" action="http://target-ampache/messages.php?action=send" method="POST">
  <input type="hidden" name="to" value="admin">
  <input type="hidden" name="message" value="You have been compromised!">
  <input type="hidden" name="csrf_token" value="invalid_or_empty">
</form>
<script>document.getElementById('csrf').submit();</script>
</body>
</html>

3. Host this page on an attacker-controlled server.
4. Send the link to the victim (e.g., via email or social engineering).
5. When the victim visits the page while authenticated to Ampache, the message is sent.

Note: No public exploit code is available; this is a conceptual demonstration.

Blue Team (Detection & Defense)

Detection:

• Monitor for unusual spikes in message sending activity.
• Look for messages sent with missing or invalid CSRF tokens in server logs.
• Use web application firewalls (WAF) to block requests with missing or malformed CSRF tokens.

Defense:

• Upgrade to Ampache 7.0.1 immediately.
• Implement additional CSRF protections, such as SameSite cookies and custom headers.
• Educate users about phishing and malicious links.

Indicators of Compromise (IOCs)

• Network IOCs:
  • POST requests to /messages.php?action=send with missing or invalid csrf_token parameter.
  • Referer headers from unexpected domains (e.g., attacker-controlled sites).
• Host IOCs:
  • Server logs showing repeated failed CSRF token validation attempts.
  • Unexpected messages in user inboxes, especially from administrators.
• File IOCs:
  • Modified messages.php or related files if an attacker gains code execution.

Detection Engineering

YARA Rule

rule CVE_2024_51489_CSRF_Ampache {
    meta:
        description = "Detects Ampache CSRF vulnerability exploitation attempts"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-51489"
    strings:
        $csrf_param = "csrf_token" nocase
        $message_action = "action=send" nocase
        $message_to = "to=" nocase
    condition:
        all of them
}

Sigma Rule

title: Ampache CSRF Token Validation Bypass
id: 8a3f7c2e-5d1b-4a9f-8c6e-2b1a3d4f5e6c
status: experimental
description: Detects HTTP requests to Ampache messaging endpoint with missing or invalid CSRF token
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/messages.php?action=send'
    filter:
        cs-uri-query|contains: 'csrf_token='
    condition: selection and not filter
falsepositives:
    - Legitimate requests with valid tokens (should be rare)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-51489 Ampache CSRF Exploit Attempt"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/messages.php"; content:"action=send"; within:20; http.client_body; content:!"csrf_token"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade to Ampache version 7.0.1 or later.
2. If upgrade is not possible, disable the messaging feature temporarily.
3. Implement a Web Application Firewall (WAF) rule to block requests to /messages.php without a valid CSRF token.

Long-term Measures:

• Regularly update Ampache and all dependencies.
• Conduct security audits of custom code.
• Enable logging and monitoring for suspicious activities.
• Use Content Security Policy (CSP) headers to mitigate XSS and CSRF.

Workarounds:

• No official workarounds exist. The only solution is to upgrade.

Valters IT
Securing Digital Frontiers