Description
The vulnerability in question allows an attacker to access arbitrary files which are readable by the process running Icinga Web 2. (This is usually the web server or fpm process)
To exploit this vulnerability the attacker has to acquire the following knowledge:
- The URI at which Icinga Web 2 is accessible
- An installed additional (non-core) module, which can be leveraged (Subject to trial-and-error)
- The module's install path (Subject to common knowledge and trial-and-error)
A valid user login is NOT required.
The attack is performed by sending a HTTP GET or POST request to a particular route of Icinga Web 2.
The request has to include the module's name and the desired (relative) file path.
Example:
- Icinga Web 2 is accessible at /icingaweb2
- The business process module is installed and enabled
- The module is installed at /usr/share/icingaweb2/modules
Applicable request to access /etc: "GET /icingaweb2/static/img?module_name=businessprocess&file=../../../../../../../etc/os-release"
Since when does it exist?
Since the initial 2.0.0 stable release.
Am I affected?
If you had already been a victim of this vulnerability can only be verified by inspecting the web server's access log.
Manifestations of such a request in the access log can be identified with this command:
grep -Pie '(?<=GET|POST ).+/static/img?(.*file=((\.|%2e)(\.|%2e)(/|%2f)){3,}\S*| )' access.log
Which modules can be leveraged?
Known and publicly available modules:
- https://github.com/Icinga/icingaweb2-module-businessprocess
- https://github.com/Icinga/icingaweb2-module-director
- https://github.com/Icinga/icingaweb2-module-reporting
- https://github.com/nbuchwitz/icingaweb2-module-map
- https://github.com/Mikesch-mp/icingaweb2-module-globe
We would like to emphasize that a module itself is NOT the cause nor affected. None of the listed modules require a fix in this regard.