CVE-2021-32747 in Web
Summary
by MITRE • 07/13/2021
Icinga Web 2 is an open source monitoring web interface, framework, and command-line interface. A vulnerability in which custom variables are exposed to unauthorized users exists between versions 2.0.0 and 2.8.2. Custom variables are user-defined keys and values on configuration objects in Icinga 2. These are commonly used to reference secrets in other configurations such as check commands to be able to authenticate with a service being checked. Icinga Web 2 displays these custom variables to logged in users with access to said hosts or services. In order to protect the secrets from being visible to anyone, it's possible to setup protection rules and blacklists in a user's role. Protection rules result in `***` being shown instead of the original value, the key will remain. Backlists will hide a custom variable entirely from the user. Besides using the UI, custom variables can also be accessed differently by using an undocumented URL parameter. By adding a parameter to the affected routes, Icinga Web 2 will show these columns additionally in the respective list. This parameter is also respected when exporting to JSON or CSV. Protection rules and blacklists however have no effect in this case. Custom variables are shown as-is in the result. The issue has been fixed in the 2.9.0, 2.8.3, and 2.7.5 releases. As a workaround, one may set up a restriction to hide hosts and services with the custom variable in question.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/15/2021
The vulnerability CVE-2021-32747 affects Icinga Web 2, an open source monitoring web interface that serves as a framework and command-line interface for Icinga 2 monitoring systems. This security flaw exists in versions between 2.0.0 and 2.8.2 where custom variables are improperly exposed to unauthorized users. Custom variables in Icinga 2 represent user-defined key-value pairs that are commonly used to store sensitive information such as authentication credentials for services being monitored. These variables typically contain secrets that are critical for system security and proper authentication with monitored services.
The technical implementation flaw stems from the application's handling of custom variables within its user interface and API endpoints. While Icinga Web 2 includes built-in protection mechanisms through user role configuration, these safeguards fail when accessing custom variables through an undocumented URL parameter. This parameter allows unauthorized access to custom variable data through affected routes, bypassing the normal protection rules and blacklists that should obscure sensitive information. The vulnerability specifically impacts the display and export functionality of custom variables, where protection rules that normally show `*` for sensitive values are completely ignored. Additionally, blacklists that should hide entire custom variables are also ineffective when this undocumented parameter is used, resulting in complete exposure of sensitive data.
The operational impact of this vulnerability is significant as it directly compromises the security of monitoring systems that rely on Icinga Web 2 for administration. Attackers who can access the monitoring interface can extract authentication credentials, API keys, and other sensitive configuration data that should remain protected. This exposure creates a substantial risk for organizations using Icinga for critical infrastructure monitoring, as it undermines the security controls designed to protect sensitive operational data. The vulnerability is particularly concerning because it affects the data export capabilities, meaning that when administrators export monitoring data to JSON or CSV formats, the sensitive custom variables remain visible in the exported files, potentially exposing them to unauthorized parties.
The vulnerability is classified under CWE-200 as "Information Exposure" and aligns with ATT&CK technique T1552.001 "Credentials in Files" and T1552.004 "Credentials in Registry" as it exposes sensitive configuration data that should remain protected. The issue has been resolved in versions 2.9.0, 2.8.3, and 2.7.5 through proper implementation of access controls that respect protection rules and blacklists regardless of how custom variables are accessed. Organizations should immediately upgrade to these patched versions to ensure their monitoring systems remain secure. As a temporary workaround, administrators can implement restrictions to hide hosts and services containing sensitive custom variables, though this approach provides only partial protection compared to the proper security fix. The vulnerability demonstrates the importance of proper access control implementation and the need for comprehensive security testing of all API endpoints, particularly those that provide data export capabilities.