(Non) security monitoring systems: NagiosXI

Now, in a company of any size, this or that monitoring system is often used, periodically in one or the other they find vulnerabilities (which are closed by patches) and weaknesses (to which eyes are closed). Today we will talk about the NagiosXI monitoring system and talk about how to use it during the Pentest. And also we give the opinion of the developers regarding the problem of the safety of their product.

Older versions don't go anywhere

Although we mentioned bug fixes, you can often stumble upon an outdated monitoring system. Further actions are quite trivial. We check the version (for example, using this script ), then we find the list of vulnerabilities for a particular assembly and easily continue the escalation in the network. The urgency of the problem is given by the fact that many CM users do not restrict access from outside. The Censys.io scanner, at the request of nagiosxi, reports 1002 available services, and a quick analysis immediately finds systems vulnerable to RCE .


Often, the attacker does not need to have any specialized skills. For a random system from our sample, it is enough to launch a ready exploit .
')
It would seem, what could be worse than compromising a server? It's time to remember about the existence of auxiliary plug-ins, which are almost never updated, and no less vulnerabilities to them. The popular NRPE plugin can be found quite often, it is used to execute remote commands on monitored hosts. It is a ticking time bomb, if the dont_blame_nrpe option is turned on in its config (which seems to hint), but few people think about security risks when solving their short-term tasks in this way.


In tutorials and guides, it is recommended to use dont_blame_nrpe = 1 in your configurations to correct many errors.

Periodically, we stumble upon the use of an outdated version of this plugin, a vulnerability in which allows remote code execution .

Developers have time to think about your safety.

Time goes by, vulnerabilities are eliminated, and responsible system administrators update their systems in a timely manner, believing that in this way they become protected from intruders. This is partly so - in such conditions, the script-kiddy cannot do any harm without having an exploit worker at hand - but if we are talking about an option in which the attacker starts exploring the system, then you can find a lot of interesting things.

This summer, we looked at the most up-to-date version of NagiosXI 5.4.8, and found in it a number of weaknesses and vulnerabilities, several xss and the ability to download a malicious component that will add a shell to a web server and will be available to an unauthorized user. We informed the system developers about this, after a short time we received an answer.


Not a bug, but a feature!

As is often the case, the rescue of drowning people is the work of the drowning people themselves. Given the unhindered ability to go through passwords, not to mention systems with standard credentials, vulnerable systems will suffice for a small botnet. Apparently, the ability to leave the shell after penetrating the administrative panel will not be eliminated for quite a long time, until this problem is perceived by the developers as a bug.
We, of course, understand how the development of products in IT companies.

But we can not fail to note that in August the POC of the social attack vector was introduced, which after one inaccurate user click adds a shell to the remote server . The developers have promised to filter the values ​​that fall into the variables, but six months later, in version 5.4.12, nothing has changed in this regard.



In order to facilitate the task of researchers and identify threats to the administrators of monitoring systems, a periodically updated readings appeared on the operation of the CM . Follow the link for more information on the attack vectors listed above for an attack during penetration testing.

Finally

I would also like to note that similar materials are being prepared for other popular (and not so) monitoring systems. Special thanks to these guys: ro421 , PenGenKiddy , sabotaged , NetherNN .

In addition, all not indifferent people can contribute to the formation of this memo and supplement it with their own materials on any monitoring system known to you.