{"id":2600,"date":"2023-01-17T13:37:59","date_gmt":"2023-01-17T12:37:59","guid":{"rendered":"https:\/\/www.dsecbypass.com\/?p=2600"},"modified":"2024-02-07T09:15:25","modified_gmt":"2024-02-07T08:15:25","slug":"centreon-map-vulnerability","status":"publish","type":"post","link":"https:\/\/www.dsecbypass.com\/en\/centreon-map-vulnerability\/","title":{"rendered":"Centreon map vulnerability"},"content":{"rendered":"

[et_pb_section fb_built=”1″ _builder_version=”4.17.3″ _module_preset=”default” custom_padding=”0px||||false|false” global_colors_info=”{}”][et_pb_row _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/www.dsecbypass.com\/wp-content\/uploads\/2023\/01\/Centreon_Logo_RVB_HD_Cut_compress-300×67.png” alt=”Centreon's logo” title_text=”Centreon's Logo” align=”center” _builder_version=”4.19.4″ _module_preset=”default” background_color=”RGBA(255,255,255,0)” width=”50%” module_alignment=”center” global_colors_info=”{}”][\/et_pb_image][et_pb_text _builder_version=”4.23.2″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n

Vladimir had the opportunity to test the security of the Centreon MAP<\/a> plugin (centreon-map-server) during an internal pentest<\/a> on a monitoring infrastructure.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

The vulnerability, with a CVSSv3 8.3 score<\/a>, has been fixed in the following versions:<\/p>\n

\n

centreon-map-21.10.8<\/p>\n

centreon-map-22.04.2<\/p>\n

centreon-map-22.10.1<\/p>\n<\/blockquote>\n

A mention of the vulnerability can be found in the plugin’s release notes<\/a> as well as in the acknowledgments<\/a> on Centreon’s GitHub.<\/p>\n

[\/et_pb_text][et_pb_text module_id=”sauvegarder” _builder_version=”4.23.2″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n

Vulnerability analysis<\/h2>\n

The plugin exposes a “beta” API whose documentation<\/a> is public.<\/p>\n

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.<\/p>\n

Having no accounts to authenticate to the API, the pentester quickly tries a few weak login\/password combinations on the following API endpoint:<\/p>\n

\n

POST \/centreon-studio\/api\/beta\/authentication<\/p>\n<\/blockquote>\n

“admin:admin”, “admin:centreon”, “admin:password”…<\/p>\n

Each time, the same message is returned by the application suggesting that the accounts are not valid:<\/p>\n

\"Centreon<\/p>\n

\n

Then comes the test with an account name that is unlikely to exist:<\/p>\n

\"Login<\/p>\n

Interesting ! Could it be that all the first tests are actually valid?<\/p>\n

Using one of the studioSession<\/em> cookies on an authenticated endpoint validates the first vulnerability: the beta Centreon Map API only needs<\/em> a valid username to authenticate the user. In this case, the admin account allows authentication with any password.<\/p>\n

The troubleshooting<\/a> documentation mentions an eye-catching call:<\/p>\n

\n

GET \/centreon-studio\/api\/beta\/actuator\/health<\/p>\n<\/blockquote>\n

The Spring Boot Actuator was previously covered in the Apereo CAS configuration flaw article<\/a>. It is always interesting to enumerate which functionalities are exposed by the Actuator service.<\/p>\n

Using the newly acquired admin session, Vladimir proceeds to list the available Actuator calls by simply accessing:<\/p>\n

\n

GET \/centreon-studio\/api\/beta\/actuator\/<\/p>\n<\/blockquote>\n

“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…).<\/p>\n

Heapdump<\/em>, on the other hand, works fine and allows the pentester to recover memory from the process. To his surprise, the dump<\/em> contains the Centreon check command lines with, in particular, the accounts used to access the services.<\/p>\n

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.<\/p>\n

[\/et_pb_text][et_pb_text module_id=”virus” _builder_version=”4.19.4″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n

POC<\/h2>\n

Linux commands to reproduce the vulnerability :<\/p>\n

\n