CVE-2025-23203

Executive Summary

CVE-2025-23203 is an authorization bypass vulnerability in Icinga Director, a configuration deployment tool for the Icinga monitoring system. The flaw allows authenticated users with restricted permissions to access and modify configuration objects (services, notifications, service sets, scheduled downtimes) that they should not be able to see or edit. By exploiting this vulnerability, a low-privileged user can enumerate hidden hosts, retrieve sensitive configuration data, and alter monitoring settings, potentially leading to data breaches and further exploitation of the monitoring infrastructure. The vulnerability affects all versions from 1.0.0 up to (but not including) 1.10.4 and 1.11.4. Patches are available in versions 1.10.4 and 1.11.4. As a temporary workaround, the Director module should be disabled for all non-admin users.

Supply Chain & Package Security

This vulnerability affects the Icinga Director module, which is distributed as part of the Icinga Web 2 ecosystem. The module is typically installed via package managers (e.g., apt, yum) or from source. Organizations should verify the integrity of their Icinga packages and ensure they are sourced from official repositories. The vulnerability does not directly impact the supply chain of third-party dependencies, but the compromised configuration data could be used to pivot to other systems.

CVSS Breakdown & Threat Level

CVSS Score: 5.5 (Medium) Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

• Attack Vector (AV): Network – The vulnerability is exploitable over the network via the REST API.
• Attack Complexity (AC): Low – No special conditions are required; the attacker only needs to send crafted API requests.
• Privileges Required (PR): Low – An authenticated user with any level of access to the Director module is required.
• User Interaction (UI): None – No user interaction is needed.
• Scope (S): Unchanged – The vulnerability does not affect resources beyond the Director module.
• Confidentiality (C): Low – Sensitive configuration data (e.g., host names, service definitions) can be disclosed.
• Integrity (I): Low – Restricted users can modify configuration objects they should not have access to.
• Availability (A): None – The vulnerability does not affect availability.

Threat Level: Medium. While the CVSS score is moderate, the potential for data breaches and configuration tampering in a monitoring system (which often has privileged access to other systems) elevates the risk.

Deep Dive & Mechanics

The vulnerability stems from improper authorization checks in several REST API endpoints of the Icinga Director module. The affected endpoints fail to enforce object-level access controls when querying or modifying configuration objects. Specifically:

• /icingaweb2/director/service: When the host name is omitted from the query, the endpoint returns all services, including those belonging to hosts the user is restricted from accessing.
• /icingaweb2/director/notification: Returns notification objects without verifying the user's permissions on the associated hosts or services.
• /icingaweb2/director/serviceset: Returns service set definitions without proper authorization checks.
• /icingaweb2/director/scheduled-downtime: Returns scheduled downtime objects without verifying the user's access to the target hosts.
• /icingaweb2/director/services?host=filteredHostName: Returns a 200 OK status code even when the host is filtered, allowing an attacker to confirm the existence of a host they should not know about.

The root cause is a missing or insufficient check on the user's permissions for each object returned by the API. The Director module relies on a role-based access control (RBAC) system, but the API endpoints do not consistently apply these restrictions to individual objects. This allows a user with, for example, read-only access to a subset of hosts to enumerate all hosts and modify their configurations.

Vulnerable vs. Patched Code

The vulnerability is fixed by adding proper authorization checks to the affected API endpoints. The patched code ensures that before returning or modifying an object, the system verifies that the authenticated user has the necessary permissions for that specific object.

Vulnerable Code (Conceptual):

// In a controller method for listing services
public function listAction() {
    $services = $this->getAllServices(); // No permission filtering
    return $this->jsonResponse($services);
}

Patched Code (Conceptual):

// In a controller method for listing services
public function listAction() {
    $user = $this->getCurrentUser();
    $services = $this->getAllServices();
    $filteredServices = array_filter($services, function($service) use ($user) {
        return $user->hasPermission('director/service', $service->getHost());
    });
    return $this->jsonResponse(array_values($filteredServices));
}

The exact patch details are available in the Icinga Director repository (versions 1.10.4 and 1.11.4). The fix involves adding calls to the authorization service in each affected endpoint.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an Icinga Web 2 instance with the Director module enabled.
• A valid user account with at least "read" access to the Director module (e.g., a user with the "director/read" permission).

Exploitation Steps:

1. Enumerate Hidden Hosts: Send a GET request to the /icingaweb2/director/services endpoint with a known filtered host name:

   curl -u 'attacker:password' 'https://icinga.example.com/icingaweb2/director/services?host=secret-host'
   

   If the response is 200 OK (even with an empty body), the host exists. If 404, it does not.

2. List All Services (Including Restricted):

   curl -u 'attacker:password' 'https://icinga.example.com/icingaweb2/director/service'
   

   This returns all services, including those for hosts the user should not see.

3. Modify a Restricted Service:

   curl -u 'attacker:password' -X POST 'https://icinga.example.com/icingaweb2/director/service' \
     -H 'Content-Type: application/json' \
     -d '{"object_name": "restricted-service", "host": "secret-host", "check_command": "check_dummy", "vars": {"state": 0}}'
   

   This creates or modifies a service on a restricted host.

4. List Notifications for Restricted Hosts:

   curl -u 'attacker:password' 'https://icinga.example.com/icingaweb2/director/notification'
   

Lab Setup:

• Deploy Icinga 2 with Icinga Web 2 and the Director module (version < 1.10.4 or < 1.11.4).
• Create two users: admin (full access) and restricted (limited to a subset of hosts).
• Configure a host secret-host that is only accessible to admin.
• Log in as restricted and attempt the above requests.

Blue Team

Detection:

• Monitor API access logs for unusual patterns, such as a user accessing /director/service without specifying a host, or accessing /director/services?host= with multiple host names.
• Look for 200 OK responses to /director/services?host= followed by POST requests to /director/service for the same host.
• Alert on any modification of configuration objects by users who should not have write access to those objects.

Hunting:

• Query Icinga Web 2 audit logs for actions performed by users with the director/read permission on objects belonging to hosts outside their allowed scope.
• Review the director_activity_log table in the Icinga Director database for unexpected changes.

Mitigation:

• Immediately upgrade to Icinga Director 1.10.4 or 1.11.4.
• If upgrade is not possible, disable the Director module for all non-admin users by removing their access in the Icinga Web 2 user management interface.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Repeated GET requests to /icingaweb2/director/service without a host parameter from a low-privileged user.
  • GET requests to /icingaweb2/director/services?host=<hostname> where <hostname> is a known sensitive host.
  • POST/PUT requests to /icingaweb2/director/service or /icingaweb2/director/notification for objects belonging to restricted hosts.

• System IOCs:

  • Unexpected entries in the director_activity_log table showing modifications by users with limited permissions.
  • Icinga Web 2 audit logs showing access to endpoints by users who should not have access to the underlying objects.

• File IOCs:

  • Modified configuration files in /etc/icingaweb2/modules/director/ (if the attacker gains write access to the filesystem).

Detection Engineering

YARA Rule

rule CVE_2025_23203_Icinga_Director_AuthBypass {
    meta:
        description = "Detects exploitation attempts of CVE-2025-23203 in Icinga Director logs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-23203"
        severity = "medium"
    strings:
        $s1 = "/icingaweb2/director/service" ascii wide nocase
        $s2 = "/icingaweb2/director/notification" ascii wide nocase
        $s3 = "/icingaweb2/director/serviceset" ascii wide nocase
        $s4 = "/icingaweb2/director/scheduled-downtime" ascii wide nocase
        $s5 = "/icingaweb2/director/services?host=" ascii wide nocase
    condition:
        any of ($s*) and #s5 > 5
}

Sigma Rule

title: CVE-2025-23203 - Icinga Director Authorization Bypass
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects attempts to exploit the authorization bypass vulnerability in Icinga Director REST API.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-23203
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains:
            - '/icingaweb2/director/service'
            - '/icingaweb2/director/notification'
            - '/icingaweb2/director/serviceset'
            - '/icingaweb2/director/scheduled-downtime'
            - '/icingaweb2/director/services?host='
    condition: selection
falsepositives:
    - Legitimate admin users performing authorized actions
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-23203 - Icinga Director Authorization Bypass Attempt";
    flow:to_server,established;
    content:"/icingaweb2/director/"; http_uri;
    pcre:"/\/icingaweb2\/director\/(service|notification|serviceset|scheduled-downtime|services\?host=)/Ui";
    classtype:attempted-recon;
    sid:10000001;
    rev:1;
    reference:cve,2025-23203;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Icinga Director to version 1.10.4 or 1.11.4 (or later). This is the only complete fix.
2. If upgrade is not feasible, disable the Director module for all users except those with the admin role. This can be done in Icinga Web 2 under "Authentication" -> "Roles" by removing the director/* permissions from non-admin roles.

Long-term Measures:

• Implement strict role-based access control (RBAC) for all Icinga Web 2 modules.
• Regularly audit user permissions and review access logs.
• Enable and monitor Icinga Web 2 audit logging to detect unauthorized access attempts.
• Apply the principle of least privilege: grant only the minimum permissions required for each user's role.
• Keep all Icinga components up to date with the latest security patches.

Workaround Details: To disable the Director module for non-admin users:

1. Log in to Icinga Web 2 as an admin.
2. Go to "Configuration" -> "Authentication" -> "Roles".
3. Edit each non-admin role and remove all permissions under the "Director" section (e.g., director/*).
4. Save the changes.

This will prevent non-admin users from accessing any Director functionality, effectively mitigating the vulnerability until an upgrade can be performed.

Valters IT