Pandora FMS vulnerability, feature or just a bad configuration?
This post is also available in : Spanish
Pandora FMS Vulnerability? Sometimes things may not be what they seem
We recently received a notification from a concerned user, because he had found a “vulnerability” in Pandora FMS. Besides, not just any vulnerability but one that seemed to give root access to the system. Next, this user called k4m1ll0 wrote a post in Medium warning the community about this vulnerability. If you want to read the original post, click here.
Obviously, as soon as we read it, one of our engineers tried to explain to k4m1ll0 that it is not a Pandora FMS vulnerability, but rather it is an issue related to configuration and, therefore, it is contemplated. After exchanging a couple of post comments, we realized that, although k4m1ll0 has been using and analyzing our application in depth, of which we are proud and grateful, he suffers from what could be called “half-truths”. He has faced a certain behavior of the application, but he does not know how or why it happens, so he fills in the blanks with assumptions.
Therefore, instead of continuing to comment in the Medium post, we have decided to write an article where we will prove that it is not a security failure and thus we will take advantage of this opportunity to explain how Pandora FMS infrastructure works for those who still don’t know it. So, it has come in handy, right?
Firstly, I will explain in my own words, what our friend k4m1ll0 has discovered.
The Pandora FMS vulnerability begins when logging in or accessing Pandora FMS web console environment with a global administrator user. Yes, that’s how it all starts. Once you login as an administrator, you must use the alert system to create a command that runs when certain terms are met or when you force the alert from the console.
Technically, what k4m1ll0 has discovered is the alert feature. You can see how it all works in our official documentation: https://pandorafms.com/docs/index.php?title=Pandora:Documentation_en:Alerts
For those who do not want to go into more technical details, I will briefly explain what happens.
If you are administrator, in the web console you may configure a Command, which, as its name indicates, is a system command, or even a compiled script or binary, any execution in the system. You already know that in Pandora FMS we love to give all possible options (the F is for flexibility).
This command can then be used by an Action which, generally speaking, defines the way in which this command will be executed and the parameters it will take. If the command were a ping, in the action we would define how many packets we would send as well as the IP to which we would point, to give a very simple example.
Then, we have to define a Template, which are the terms to trigger the alert. There are many possible terms and one of them is obviously to be able to trigger the Alert manually, thus executing the defined Action.
Up to this point, it seems dangerous, doesn’t it? Would it put our environment at risk? What if that command defined by the administrator was malicious? That’s the point our friend k4m1ll0 got to, and that is why I say it is a “half-truth”, because it is indeed as dangerous as giving your house keys to someone who could have bad intentions. Remember that the first requirement is for you to be tool administrators to create a command. A standard user does not have my house keys, of course, so he cannot create a command.
But don’t just trust me yet, there is still more. You can see for yourself how there is no way for it to be a vulnerability from any point of view.
Now let’s describe the process to launch that command. There is nothing better than knowing how things work to draw your own conclusions.
As we know, Pandora FMS consists of 3 main elements: web console, database, and server. They may or may not be on the same machine. Pandora FMS is an application designed to offer flexibility and scalability as two of its main principles.
It’s very simple: the console is a web interface, which is developed in PHP on a Apache server, which by default runs with a limited Apache user. As we know, the Apache user has virtually no privileges in the system, so it makes no sense for the alert to be executed by the console.
No, what the console does is write the values that you defined in the web forms directly on the database. When launching a manual alert on the console, what it does is put a flag on the database to indicate that the alert should be executed. I don’t see any danger so far.
The MySQL database stores data gives you an interface to insert, modify and check these data and… that’s it. So there is no danger here either.
Finally, there is our server, the Pandora FMS Server, who is responsible for executing the monitoring process. Developed in Perl, with modular servers for different cases, separate thread management for each server, with more configurations and possibilities than a smartphone. Like, basically, a wonder, a work of art of software engineering.
Among the tasks of our server, there is alert execution. Those alerts are read from the database and executed when the triggering terms are met or when the alert is forced from the console. And this is where it is possible to execute commands like root. Mind you, it will depend on the system installation and configuration process when defining the user that will run the server. If the server runs as root, alert commands will be of course executed as root, but if the user running the server (which can be defined when installing the package or changed in the boot script, if it is already installed) is user1, he can only then execute what user1 has permissions to execute, and it will be impossible to have root access to the system, which is not the console system either, it is the server system, which may, unlike the console, not be exposed to the user.
Let’s see an example.
In this environment, the web console is accessed through a reverse proxy that goes to a balancer that balances among 3 consoles.
In turn, these consoles connect to a database that is behind a firewall, which in turn connects to the Pandora FMS server behind another firewall, running the server with a user restricted only to the tasks it needs.
Even if I give you console admin permissions (remember that the first step in terms of security is to define the correct profiles for each user), even so, supposing you are an admin, there is no way you can get root access. You will not even be able to execute any command the system administrator has not given execution permissions to the restricted user User 1.
If you define a command that is not within the list of commands that User 1 has, the server will not be able to execute it, so Pandora FMS vulnerability theory gets completely dismantled through good safety practices.
Finally, I would like to highlight a couple of details. It is true that, by default, if you do not configure it or define it explicitly in the installation, the server will run as root.
This is set on purpose since in small and medium-sized environments and isolated networks, there is no need to have a restricting policy of system user execution and command execution with all the managing burden involved. Just by keeping an appropriate profile creation policy in the console, 99.9% of security problems are avoided.
But, if you still want more security, don’t worry. As we have seen, you can run the server in a restrictive way with a user to whom you assign what permissions it should have and on what. As mentioned, the “F” is for flexibility, so with Pandora FMS you have the whole wide range of tools at your disposal.
If you still have any questions about how the alert system works and its possible configurations, leave a comment, or better yet, go to our forum where a huge community will help you solve all your doubts.