Vladimir had the opportunity to test the security of the Centreon MAP plugin (centreon-map-server) during an internal pentest on a monitoring infrastructure.
According to the documentation, this plugin “is capable of displaying efficient graphical overviews and mapping correlated data into user-relevant custom views.” It is an extension that requires a valid Centreon License.
Our pentester discovered an authentication bypass at the plugin API level followed by remote access to process memory. This could allow an unauthenticated attacker with access to the Web interface to recover all the secrets found in the process’s memory, which notably includes all the secrets used by the Centreon checks.
Centreon being more often than not a central component in an Information System, this information leak can lead to the compromise of other applications and servers, or even of the IS as a whole.
The vulnerability, with a CVSSv3 8.3 score, has been fixed in the following versions:
centreon-map-21.10.8
centreon-map-22.04.2
centreon-map-22.10.1
A mention of the vulnerability can be found in the plugin’s release notes as well as in the acknowledgments on Centreon’s GitHub.
Vulnerability analysis
The plugin exposes a “beta” API whose documentation is public.
In order to call the API in an authenticated way, a “Studio-Session” HTTP header must be sent. Its content is given by the API in the “studioSession” JSON variable upon successful authentication.
Having no accounts to authenticate to the API, the pentester quickly tries a few weak login/password combinations on the following API endpoint:
POST /centreon-studio/api/beta/authentication
“admin:admin”, “admin:centreon”, “admin:password”…
Each time, the same message is returned by the application suggesting that the accounts are not valid:
Then comes the test with an account name that is unlikely to exist:
Interesting ! Could it be that all the first tests are actually valid?
Using one of the studioSession cookies on an authenticated endpoint validates the first vulnerability: the beta Centreon Map API only needs a valid username to authenticate the user. In this case, the admin account allows authentication with any password.
The troubleshooting documentation mentions an eye-catching call:
GET /centreon-studio/api/beta/actuator/health
The Spring Boot Actuator was previously covered in the Apereo CAS configuration flaw article. It is always interesting to enumerate which functionalities are exposed by the Actuator service.
Using the newly acquired admin session, Vladimir proceeds to list the available Actuator calls by simply accessing:
GET /centreon-studio/api/beta/actuator/
“health”, “beans”, “env”, “configprops”, “loggers”, “jolokia”, “heapdump”… many possibilities of exploitation are present. But for some obscure reason, only GET requests seem to be accepted and although listed, Jolokia does not seem accessible (no Jolokia RCE then…).
Heapdump, on the other hand, works fine and allows the pentester to recover memory from the process. To his surprise, the dump contains the Centreon check command lines with, in particular, the accounts used to access the services.
The second Centreon Map vulnerability is therefore to have left sensitive Actuator calls by default that can allow, depending on the configuration of the targeted Centreon application, to gain access to other components of the Information System.
POC
Linux commands to reproduce the vulnerability :
Recommendations
The recommendations are to be addressed on two levels: the software publisher, and the configuration of Centreon.
The correction part of the Centreon MAP plugin revolves around the change of the source code related to authentication, in order to verify the password, as well as the default deactivation of sensitive Actuator endpoints.
Regarding the installation of Centreon, it is necessary to reduce the attack surface as much as possible and to respect the principle of least privilege:
-
- Use accounts with the minimum privileges necessary for the checks carried out
- Use complex and unique secrets and passwords, which cannot be reused in a password spraying attack for example
- Only expose Centreon web interfaces and administration services to relevant personnel (e.g. to an administration VLAN only)
- Apply Centreon security recommendations: https://docs.centreon.com/docs/administration/secure-platform/ and https://docs.centreon.com/docs/graph-views/secure-your-map-platform/
- Keep components up to date (core and extensions)
These advices are to be adapted according to the context of each one.
Communication with the software publisher
Centreon’s Coordinated Disclosure process is well documented at the following URL: https://github.com/centreon/centreon/security/policy#security-policy.
The response was quick, and the vulnerability management and communication process very well handled by Centreon.
16/11/2022: First email sent by Vladimir following the Centreon process
16/11/2022: Response from Centreon indicating that they are starting the analysis
17/11/2022: The vulnerability is reproduced and Centreon validates the proposed severity (CVSSv3 8.3)
22/11/2022: Synchronization meeting with Centreon
29/11/2022: Publication of corrected versions
17/01/2023: Mention on the Centreon GitHub security page
19/01/2023: Publication of this article
🛡️ DSecBypass accompanies you on your internal security audits. Do not hesitate to contact us for additional information and/or a personalized quote 📝.
