Vladimir a eu l’occasion de tester la sécurité du plugin Centreon MAP (centreon-map-server) lors d’un test d’intrusion interne sur une infrastructure de monitoring.
D’après la documentation, ce plugin « est capable d’afficher des aperçus graphiques efficaces et de cartographier des données corrélées dans des vues personnalisées pertinentes pour l’utilisateur ». C’est une extension qui nécessite une License Centreon valide.
Notre pentester a découvert un contournement d’authentification au niveau de l’API du plugin suivi d’un accès distant à la mémoire du processus. Cela pourrait permettre à un attaquant non authentifié ayant accès à l’interface Web de récupérer l’ensemble des secrets se trouvant en mémoire du processus, ce qui inclut notamment tous les secrets utilisés par les checks Centreon.
Centreon étant un composant souvent central dans un Système d’Information, cette fuite d’information peut donner lieu à la compromission d’autres applications et serveurs, voir du SI dans son ensemble.
La vulnérabilité, d’un score CVSSv3 8.3, a été corrigée dans les versions suivantes :
centreon-map-21.10.8
centreon-map-22.04.2
centreon-map-22.10.1
Une mention de la vulnérabilité peut être trouvée dans les notes de release du plugin ainsi que dans les remerciements sur le GitHub de Centreon.
Analyse de la vulnérabilité
Le plugin expose une API « beta » dont la documentation est publique.
Afin d’appeler l’API de manière authentifiée, un entête HTTP « Studio-Session » doit être envoyé. Son contenu est donné par l’API dans la variable JSON « studioSession » lors d’une authentification réussie.
Ne disposant pas de comptes pour s’authentifier sur l’API, l’auditeur tente rapidement quelques combinaisons d’identifiants / mots de passe faibles sur le point d’API suivant :
POST /centreon-studio/api/beta/authentication
« admin:admin », « admin:centreon », « admin:password »…
A chaque fois, le même message est renvoyé par l’application laissant supposer que les comptes ne sont pas valides :
Puis vient le test avec un nom de compte qui a peu de chances d’exister :
Intéressant ! Se pourrait-il que tous les premiers tests soient en réalité valides ?
L’utilisation d’un des cookies studioSession sur un endpoint authentifié permet de valider la première vulnérabilité : l’API beta Centreon Map n’a besoin que d’un nom d’utilisateur valide pour authentifier l’utilisateur. En l’occurrence, le compte admin permet de s’y authentifier avec n’importe quel mot de passe.
La documentation d’aide à la résolution de problèmes mentionne un appel qui attire l’œil :
GET /centreon-studio/api/beta/actuator/health
L’Actuator Spring Boot a précédemment été couvert dans l’article sur un défaut de configuration d’Apereo CAS. Il est toujours intéressant d’analyser quelles fonctionnalités sont accessibles sur le service Actuator.
Utilisant la session admin nouvellement acquise, Vladimir entreprend de lister les appels Actuator disponibles avec un simple accès à :
GET /centreon-studio/api/beta/actuator/
« health », « beans », « env », « configprops », « loggers », « jolokia », « heapdump »… de nombreuses possibilités d’exploitation sont présentes. Mais pour une raison obscure, seulement les requêtes GET semblent être acceptées et bien que listé, Jolokia ne semble pas accessible (pas de RCE Jolokia donc…).
En revanche, heapdump fonctionne correctement et permet à l’auditeur de récupérer la mémoire du processus. A sa surprise, le dump contient les lignes de commande des checks Centreon avec, en particulier, les comptes utilisés pour accéder aux services.
La deuxième vulnérabilité Centreon Map est donc d’avoir laissé par défaut des appels Actuator sensibles pouvant permettre, selon la configuration de l’application Centreon ciblée, d’obtenir des accès à d’autres composants du Système d’Information.
POC
Commandes Linux permettant de reproduire la vulnérabilité :
Préconisations
Les préconisations sont à adresser sur deux plans : l’éditeur, et la configuration de Centreon.
La partie correction du plugin Centreon MAP s’articule autour du changement du code source lié à l’authentification, afin de vérifier le mot de passe, ainsi qu’à la désactivation par défaut des appels Actuator sensibles.
En ce qui concerne l’installation de Centreon, il est nécessaire de réduire au maximum la surface d’attaque et de respecter le principe de moindre privilège :
-
- Utiliser des comptes avec les privilèges minimums nécessaires aux checks réalisés
- Utiliser des secrets et mots de passe complexes et uniques, qui ne peuvent pas être réutilisés dans une attaque par password spraying par exemple
- N’exposer les interfaces Web et services d’administration Centreon qu’au personnel concerné (par exemple à un VLAN d’administration seulement)
- Appliquer les recommandations de sécurité Centreon: https://docs.centreon.com/docs/administration/secure-platform/ et https://docs.centreon.com/docs/graph-views/secure-your-map-platform/
- Garder les composants à jour (core et extensions)
Ces recommandations sont à adapter en fonction du contexte de chacun.
Communication avec l’éditeur
Le processus de divulgation coordonnée de Centreon est bien documenté à l’URL suivante: https://github.com/centreon/centreon/security/policy#security-policy.
La réponse a été rapide, et le processus de gestion de la vulnérabilité et de communication très bien géré par Centreon.
16/11/2022 : Premier mail envoyé par Vladimir en suivant le processus de Centreon
16/11/2022 : Réponse de Centreon indiquant qu’ils commencent l’analyse
17/11/2022 : La vulnérabilité est reproduite et Centreon valide la sévérité (CVSSv3 8.3) proposée
22/11/2022 : Réunion de synchronisation avec Centreon
29/11/2022 : Publication des versions corrigées
17/01/2023 : Mention sur la page sécurité du GitHub Centreon
19/01/2023 : Publication de cet article
🛡️ DSecBypass vous accompagne sur vos audits de sécurité internes. N’hésitez pas à nous contacter pour des informations complémentaires et/ou un devis personnalisé 📝.
