10 min de lecture - Contournement d’authentification LibreNMS : rétablir la confiance dans la supervision

Un serveur de supervision n’est presque jamais un simple tableau de bord. Il connaît les équipements, leur organisation, les interfaces importantes et, dans certains déploiements, les moyens de s’y authentifier. Si son contrôle d’accès cède, le problème dépasse largement l’application qui affiche les graphiques.

Ce risque est devenu actuel le 23 août 2026. Le projet LibreNMS a publié un avis critique sur un contournement de l’authentification de l’API. L’avis attribue un score CVSS v4 de 9,2 à la faille, indique que les versions jusqu’à 26.7.0 sont touchées et désigne la version 26.8.0 comme corrigée. Le 24 août, le CERT-FR a publié son propre avis sur cette faille et un second problème d’injection d’arguments.

Pour les startups, PME et ETI qui exploitent LibreNMS, la première tâche est claire : déterminer la version déployée et mettre à jour les systèmes touchés. La tâche suivante est plus délicate. Il faut décider à quoi faire confiance après la correction. Une mise à jour réussie ne dit pas si l’API était accessible auparavant, si un jeton actif remplissait le prérequis d’attaque ou si des identifiants d’équipements et des données de supervision ont été consultés.

Ce que les avis établissent

L’avis critique décrit une confusion de types dans le contrôle des jetons API de LibreNMS. Dans une configuration touchée, une requête non authentifiée peut correspondre à un jeton actif existant. L’appelant obtient alors les droits du propriétaire de ce jeton. Le projet indique qu’une réponse de l’API listant les équipements peut contenir des identifiants SNMP enregistrés. Si la requête correspond au jeton d’un administrateur, elle peut atteindre des fonctions de l’API capables d’exécuter du code sur l’hôte LibreNMS.

Un prérequis compte particulièrement. Selon l’avis, au moins un jeton API doit être actif. Une installation dépourvue de jeton actif n’offre aucune correspondance au contournement. Cela ne dispense pas de la mise à jour, mais modifie l’analyse d’exposition.

Le second avis du projet sur une injection d’arguments concerne aussi les versions jusqu’à 26.7.0 et désigne 26.8.0 comme version corrigée. Il décrit une méthode permettant à un utilisateur de franchir les limites de supervision entre équipements et, potentiellement, de modifier des données RRD. Une authentification est normalement nécessaire. L’avis précise toutefois qu’une configuration autorisant les graphiques sans authentification peut supprimer cette condition.

Les sources ne signalent pas d’exploitation observée de ces failles. Elles ne disent pas non plus que chaque instance LibreNMS exposait son API sur Internet, conservait des identifiants réutilisables ou possédait un jeton administrateur actif. Une version touchée ne prouve pas une compromission. L’absence de rapport public d’exploitation ne prouve pas davantage l’innocuité.

Pourquoi la supervision change la réponse

La supervision concentre une vue d’ensemble qui peut aussi fournir une carte utile à un intrus.

Le plan de supervision concentre quatre formes de confiance :

• La confiance dans l’inventaire. Noms, adresses, interfaces et sites révèlent l’organisation de l’environnement.
• La confiance dans les identifiants. Les éléments SNMP peuvent ouvrir d’autres accès selon le protocole et la configuration.
• La confiance dans les signaux. Si les données changent, un graphique normal n’est plus une preuve fiable.
• La confiance opérationnelle. La supervision peut commander alertes, tickets, automatismes et astreintes.

Le logiciel peut donc être corrigé alors que les identifiants, intégrations et signaux historiques restent incertains.

Prendre la première décision à partir des preuves

Avant de modifier de nombreux systèmes, recueillez les informations nécessaires pour qualifier l’exposition dans le processus de réponse à incident.

Nommez aussi l’absence de preuve. Si les journaux ont expiré ou si l’historique du proxy n’a jamais été conservé, consignez cette lacune. Un journal manquant n’est pas un journal sans anomalie.

Une séquence de réponse exploitable

1. Limiter l’exposition et préserver les éléments utiles

Restreignez les accès inutiles à l’interface web et à l’API LibreNMS pendant l’analyse. Préservez les journaux pertinents de l’application, du proxy, de l’authentification, de la base, du conteneur et de l’hôte avant qu’une rotation ou une reconstruction ne les efface. Notez les heures dans un fuseau commun.

Si une compromission semble plausible ou si le système est critique, laissez le responsable de l’incident décider de la capture et de l’isolement sans détruire les preuves.

2. Mettre à jour par la voie prise en charge

Faites passer les installations touchées à la version 26.8.0, ou à une version ultérieure actuellement prise en charge par le projet. Dans son guide officiel de mise à jour, LibreNMS indique qu’une installation standard se met à jour chaque jour et documente ./daily.sh pour une mise à jour manuelle. Les déploiements par conteneur, paquet ou service géré peuvent suivre une autre voie. Vérifiez donc l’application réellement exécutée après le changement au lieu de considérer qu’une commande ou un téléchargement d’image a suffi.

Consignez la version précédente, la source de la mise à jour, l’opérateur, l’heure et la validation après changement.

3. Examiner les jetons par propriétaire et par droit

Listez les jetons API actifs et identifiez le propriétaire humain ou technique de chacun. Désactivez ceux qui n’ont plus de propriétaire ou de finalité. Pour les autres, examinez les droits, les réseaux sources, les intégrations et les traces d’usage pendant la période touchée.

Traitez d’abord les jetons administrateurs et ceux utilisés par de nombreuses intégrations. Coordonnez les dépendances, puis vérifiez que les anciennes valeurs ne fonctionnent plus. Sans carte des dépendances, une rotation massive peut couper des alertes utiles.

4. Examiner les identifiants des équipements

Déterminez ce que LibreNMS pouvait récupérer depuis les équipements supervisés et ce que les identifiants autorisent. Un accès SNMP en lecture seule et un identifiant privilégié réutilisable n’ont pas la même conséquence. Délimitez la récupération selon le protocole, le droit, l’accessibilité réseau et les preuves disponibles.

Coordonnez avec les responsables réseau le remplacement des clés SNMPv3 ou des communautés réutilisables. Testez la collecte après chaque lot pour ne pas perdre toute visibilité sur le parc.

5. Valider les signaux ailleurs

Comparez les signaux LibreNMS avec les journaux des équipements, la télémétrie cloud, les flux réseau ou une autre source. Recherchez les changements inexpliqués, les nouveaux jetons, le trafic API inhabituel et les interruptions de collecte.

N’utilisez pas la preuve de concept publique sans autorisation. Sur votre propre parc, les essais doivent rester approuvés, isolés et non destructifs.

6. Clore avec des critères explicites

Les recommandations actuelles du NIST sur la réponse à incident demandent de sélectionner, délimiter et vérifier les actions de rétablissement, puis de traiter les causes avant le retour d’un système restauré en production. Appliquez ce principe ici. La clôture doit indiquer la version exécutée, les voies d’exposition étudiées, les identifiants modifiés, les lacunes de preuve restantes et la personne qui accepte le risque résiduel.

Notre guide plus large sur le rétablissement après incident propose une structure pour les preuves, le confinement et la remise en service.

Repenser la frontière de supervision après le rétablissement

Gérez la supervision comme un service d’infrastructure privilégié.

Réduisez d’abord l’accessibilité. Limitez utilisateurs et intégrations aux interfaces nécessaires, et soumettez l’API à une politique réseau explicite.

Réduisez ensuite le pouvoir des identifiants. Préférez un secret par usage, la lecture seule lorsqu’elle suffit et un propriétaire nommé pour chaque jeton.

Centralisez les journaux hors de l’hôte et conservez-les assez longtemps pour enquêter après une divulgation tardive. Le serveur ne doit pas détenir l’unique trace de sa propre activité.

Enfin, testez l’indisponibilité, la perte de confiance et l’isolement de la plateforme. Définissez la source secondaire utilisée pour les opérations critiques.

Une revue de l’infrastructure et de l’ingénierie sur mesure doit relier propriété, réseau, secrets, mises à jour, preuves et rétablissement.

Questions pour la prochaine revue d’exploitation

1. Quelles personnes et quels services possèdent les jetons API LibreNMS actifs ?
2. L’API est-elle accessible depuis des réseaux qui n’en ont pas besoin ?
3. Quels identifiants d’équipements le serveur peut-il récupérer, et avec quels droits ?
4. Où se trouvent les journaux de la supervision si ce système devient non fiable ?
5. Quelle télémétrie secondaire soutient les décisions pendant l’isolement ou le rétablissement ?
6. Quelles preuves faut-il réunir avant de rendre sa confiance normale à la plateforme ?

Si plusieurs réponses reposent sur la mémoire, l’organisation conserve une lacune opérationnelle même après la correction.

Sources et limites

• L’ avis critique du projet LibreNMS sur l’authentification API, publié le 23 août 2026, fournit versions, prérequis, gravité et conséquences.
• L’ avis du projet sur l’injection d’arguments dans RRDtool décrit les limites entre équipements et le risque pour les données.
• L’ avis CERTFR-2026-AVI-1076 du 24 août consigne les risques et renvoie aux avis du projet.
• Le guide de mise à jour de LibreNMS documente les voies de mise à jour standard et manuelle du projet.
• Le NIST SP 800-61r3 fournit les principes de réponse et de rétablissement employés ici.

Les sources ne démontrent aucune exploitation active, n’attribuent de compromission à aucun déploiement et ne fixent pas une durée universelle de conservation des journaux. Vérifiez les dernières consignes du projet. Cet article est un guide défensif, pas un constat forensique ni un remplacement pour une réponse à incident qualifiée.

Rétablir la confiance dans la supervision

LibreNMS 26.8.0 corrige le contournement d’authentification publié, mais la version n’est que le premier critère de clôture. Établissez si le prérequis et la voie d’exposition existaient. Examinez ensuite les jetons, les identifiants d’équipements, l’intégrité de la supervision et les preuves externes, dans cet ordre.

La supervision gagne sa confiance en observant les autres systèmes. Quand sa propre frontière cède, cette confiance doit être reconstruite à partir de preuves.