Julianbrost

**Name of the Vulnerable Software and Affected Versions** Icinga 2 versions 2.3.0 through 2.13.14 Icinga 2 versions 2.3.0 through 2.14.8 Icinga 2 versions 2.3.0 through 2.15.2 **Description** Icinga 2 is an open source monitoring system. The MSI installer did not configure appropriate permissions for the `%ProgramData%icinga2var` folder on Windows systems. This allowed all local users to read the folder's contents, including the private key of the user and synced configuration. All installations on Windows are affected. **Recommendations** Icinga 2 versions prior to 2.13.14 should be upgraded. Icinga 2 versions prior to 2.14.8 should be upgraded. Icinga 2 versions prior to 2.15.2 should be upgraded. Upgrade Icinga for Windows to at least version v1.13.4. Upgrade Icinga for Windows to at least version v1.12.4. Upgrade Icinga for Windows to at least version v1.11.2. Manually update the ACL for the folder `C:ProgramDataicinga2var` (and `C:Program FilesWindowsPowerShellmodulesicinga-powershell-frameworkcertificate`) including every sub-folder and item to restrict access for general users, only allowing the Icinga service user and administrators access.

**Name of the Vulnerable Software and Affected Versions** Icinga PowerShell Framework versions prior to 1.13.4 Icinga PowerShell Framework versions prior to 1.12.4 Icinga PowerShell Framework versions prior to 1.11.2 **Description** The Icinga PowerShell Framework allows configuration and monitoring of Windows environments. Versions prior to 1.13.4, 1.12.4, and 1.11.2 have permissions set on the `certificate` directory that grant all users read access. This exposes the private key of the Icinga certificate for the host. The affected directory is located at `C:Program FilesWindowsPowerShellmodulesicinga-powershell-frameworkcertificate`. All installations are affected. **Recommendations** Versions prior to 1.13.4: Upgrade to version 1.13.4 or later. Versions prior to 1.12.4: Upgrade to version 1.12.4 or later. Versions prior to 1.11.2: Upgrade to version 1.11.2 or later. As a workaround, restrict access to the `C:Program FilesWindowsPowerShellmodulesicinga-powershell-frameworkcertificate` directory and its subfolders, allowing only the Icinga service user and administrators access. Additionally, restrict access to the `C:ProgramDataicinga2var` directory and its subfolders to address a similar issue in Icinga 2.

**Name of the Vulnerable Software and Affected Versions** Icinga versions prior to 2.11.10 Icinga versions 2.12.0 through 2.12.4 **Description** The issue concerns the exposure of credentials for external services through the API to authenticated API users with read permissions for the corresponding object types. Specifically, `IdoMysqlConnection` and `IdoPgsqlConnection` expose the password of the user used to connect to the database, `IcingaDB` exposes the password used to connect to the Redis server, and `ElasticsearchWriter` exposes the password used to connect to the Elasticsearch server. An attacker who obtains these credentials can impersonate Icinga to these services and add, modify, and delete information there. If credentials with more permissions are in use, this increases the impact accordingly. **Recommendations** For Icinga versions prior to 2.11.10, update to version 2.11.10 or later to resolve the issue. For Icinga versions 2.12.0 through 2.12.4, update to version 2.12.5 or later to resolve the issue. As a temporary workaround, restrict API user permissions to not allow querying of any affected objects, either by explicitly listing only the required object types for object query permissions, or by applying a filter rule.

**Name of the Vulnerable Software and Affected Versions** Icinga versions 2.4.0 through 2.12.4 **Description** The issue concerns a monitoring system that checks network resource availability and generates performance data. It may allow privilege escalation for authenticated API users. With a read-only user's credentials, an attacker can view most attributes of config objects, including the `ticket salt` of `ApiListener`. This information is sufficient to compute a ticket for every possible common name, which, along with the master node's certificate and a self-signed certificate, can be used to request a desired certificate from the system. This certificate may then be used to steal an endpoint or API user's identity. **Recommendations** For versions 2.4.0 through 2.12.4, update to version 2.12.5 or 2.11.10 to resolve the issue. As a temporary workaround, consider specifying queryable types explicitly or filter out ApiListener objects to minimize the risk of exploitation.