Icinga has published a total of five updates yesterday for Icinga Director and one of its dependencies, the incubator module. Their main purpose is to fix two Cross-Site-Request-Forgery (CSRF) vulnerabilities. We treat them with a very high criticality and advice to upgrade immediately.
- Upgrade
icinga-php-incubatorto version 0.22.0 - Upgrade
icinga-directorto version 1.11.1. The fix got also backported to 1.10.3, 1.9.2 and 1.8.2
It applies to every version of the Icinga Director. We have disclosed this on February the 5th to our partners already and they to their customers shortly after. If you are not one of them or you have not acted yet, please do so before reading on.
Done. So, what’s the fuss?
Think for a moment about what the Icinga Director allows you to do. Right, to easily modify the monitoring environment. Icinga, to name it. Icinga, being a monitoring tool, has access to a variety of parts in your infrastructure. To access them, it also knows of various secrets and passwords.
Now imagine the type of user interacting with the Icinga Director. I don’t want to blame them of course, but the meta description on Github talks of point & click users after all… and that’s important if you continue to imagine how a potential attack unfolds.
Social Engineering
To exploit these vulnerabilities, an attacker needs the following information:
- Is Icinga being used?
- What’s the IP address/hostname and path where Icinga Web is served?
- Who can access Icinga Web and has access to the Icinga Director?
Some of our users do not disclose the use of Icinga publicly. But many do, be it on their website, on conferences or on our community forum. If you ever noticed, some of the posts in the forum even contain the URL to Icinga Web sometimes, of course with the host name or IP address included. The matter of knowing who can access Icinga Web might also be solved by looking at a company’s website or for employees on platforms such as LinkedIn.
What I want to outline here, is the complexity of the preparations needed to perform the attack in the first place. There are plenty of technical unknowns regarding the infrastructure as well. But the documentation and support policies of Icinga can already provide some clues in that regard. This means, you probably don’t need to be afraid of the infamous script-kiddy, but of the more professional and thorough attempts.
The Exploit
Once all the required information is gathered, the next step is known as a phishing attack. A victim needs access to Icinga Web as well as sufficient access rights to interact with the Icinga Director. They are contacted and incentivised to click a link. The link needs to be opened in a browser where another tab is active in which Icinga Web is loaded and the victim is logged in. (It’s possible to get around that, but assumes a Cross-Site-Scripting (XSS) vulnerability which is fixed already. Details can be found in the advisory on Github.)
The only remaining defense might be the browser used by the victim. Firefox prevents it with its total cookie protection, which is a feature of the standard or strict privacy mode. Safari also got a similar privacy feature to prevent cross-site tracking. Any browser based on Chromium (e.g. Chrome, Opera, Edge) relies on a cookie attribute and applies a suitable default for cookies that don’t have this attribute set, which is the case for Icinga Web. Though, the latter might not apply in case a web server edits Icinga Web’s cookies to disable this, since some single-sign-on (SSO) integrations depend on it.
If the browser does not prevent it, the website the victim opens by clicking the link, is able to transmit data to Icinga Web in the background. In the foreground, the website shows the victim something which ensures the tab isn’t closed as the attack consists of a chain of actions. These actions however, are not visible to the victim and can freely manipulate the monitoring configuration.
The Impact
I don’t go into detail what is actually possible. Anyone with experience in this, doesn’t need to be told. Anyone else, neither. Just some very basic hints where you might find traces if it already happened to you:
- Do all custom commands and their templates look familiar to you? Is every commandline what you expect it to be?
- Are there any import sources which fetch data from an unknown REST API?
You might have noticed where this leads to: Injecting foreign code to steal information or gain system access.
If the attacker went that far, and the host(s) where Icinga is running on are connected to the internet, you should also inspect the network activity and look out for suspicious connections.
The Bottom Line
I hope I made it clear that the vulnerability is serious, but only under very specific circumstances. It is not exploitable without at least some effort, if this eases your worries. Have you upgraded already?
