Les failles BMC continuent de faire peser un risque réel sur des milliers de datacenters. Même si la vulnérabilité a plus de vingt ans, elle cible un élément central du plan de gestion : le Baseboard Management Controller, présent sur la majorité des plateformes serveurs. Résultat : des interfaces de contrôle peuvent rester accessibles, et des secrets d’authentification peuvent être récupérés de façon à faciliter des attaques offline.
Dans cet article, nous expliquons ce que recouvre cette exposition, pourquoi elle est particulièrement dangereuse dans les environnements de production, et quelles mesures pragmatiques peuvent réduire l’impact.
Pourquoi les BMC sont un point d’entrée stratégique
Le BMC permet d’administrer un serveur même lorsque le système d’exploitation ne fonctionne pas. C’est précisément ce rôle qui en fait un atout opérationnel… mais aussi un point de contrôle extrêmement sensible. Via le BMC, on peut par exemple redémarrer le serveur, mettre à jour le firmware, effectuer des changements de configuration bas niveau ou lire des capteurs matériels.
Selon les implémentations, l’administration peut passer par plusieurs surfaces de gestion. Parmi elles : le protocole IPMI en hors bande, l’API de gestion Redfish basée sur HTTPS, ainsi qu’une interface web d’administration.
Ce que révèle CVE-2013-4786
Au cœur du problème figure la vulnérabilité CVE-2013-4786, introduite en 2004 dans le protocole d’authentification IPMI 2.0. Le mécanisme en cause permet à un attaquant d’obtenir des empreintes liées au mot de passe, puis de tenter le déchiffrement hors connexion.
Concrètement, pendant l’authentification, le contrôleur BMC peut renvoyer un code d’authentification calculé à partir du mot de passe du compte et de valeurs de session. Une partie distante non authentifiée qui parvient à atteindre le port UDP 623 peut demander cette réponse, puis tester des hypothèses de mots de passe à l’aide de ces éléments.
L’enjeu est majeur : l’attaquant n’a pas besoin d’émettre une nouvelle requête pour chaque tentative comme lors d’un simple “bruteforce” en ligne. Cela rend la récupération d’identifiants plus efficace, surtout lorsque des mots de passe faibles existent.
Des interfaces exposées à grande échelle
Le constat rapporté indique qu’environ 37 000 interfaces de gestion de serveurs exposées sur Internet utilisent le protocole IPMI. Plus inquiétant encore, plus de 24 000 d’entre elles divulguent avant même la connexion des éléments qui permettent d’aboutir à des empreintes de mots de passe dérivées.
Autrement dit, le risque ne se limite pas à une vulnérabilité théorique. Dans la pratique, des services accessibles peuvent donner aux attaquants un avantage : ils peuvent préparer des attaques de récupération d’identifiants tout en évitant une grande quantité de tentatives en ligne.
Le rôle des interfaces et la “portabilité” des identifiants
Un autre point critique concerne la façon dont les interfaces de gestion partagent les données. Dans de nombreuses configurations, les surfaces d’administration (IPMI, interface web ou API Redfish) utilisent la même base d’utilisateurs. Par conséquent, un mot de passe ou un identifiant valide sur une interface peut souvent fonctionner ailleurs.
La logique est la suivante : si l’authentification IPMI peut exposer des informations exploitables pour récupérer un mot de passe, puis que cet identifiant est identique ou réutilisé sur d’autres interfaces, alors la compromission peut s’étendre. Cela augmente la probabilité d’obtenir un accès significatif au “cœur” de l’administration.
Quels types de mots de passe posent problème
Les analyses mettent également en évidence des comportements de sécurisation insuffisants. Parmi les résultats mentionnés, certains hôtes acceptaient un nom d’utilisateur vide associé à un mot de passe faible. D’autres contenaient des comptes nommés de type Admin ou root, utilisant des mots de passe retrouvables dans des listes de mots couramment disponibles publiquement.
La même source indique aussi que certains BMC utilisent des formats de mots de passe contraints et prévisibles issus de paramètres “usine”. Dans un tel contexte, même une attaque offline peut devenir rapidement rentable, car l’espace de recherche n’est pas réellement “aléatoire”.
Un risque qui dépasse la vulnérabilité elle-même
Les failles BMC ne posent pas seulement un problème de patching. Elles révèlent un écart de sécurité plus large dans le plan de gestion des datacenters. Les contrôleurs BMC pilotent des fonctions critiques, mais ils reçoivent souvent moins de surveillance, moins de protection et moins d’exigences opérationnelles que les systèmes qu’ils supervisent.
En combinant cette exposition avec des méthodes de rupture modernes (par exemple l’accélération du cracking par GPU) et des mots de passe prévisibles ou réutilisés, une seule interface BMC exposée peut devenir un point d’appui. Une fois l’authentification compromise, l’accès peut se transformer en accès privilégié difficile à détecter, car il cible un environnement conçu pour rester disponible.
Comment réduire l’exposition : plan d’action concret
1) Inventorier les interfaces de gestion
Commencez par identifier où vos BMC sont joignables. Évaluez notamment les protocoles et ports utilisés pour l’administration, y compris les cas où le service IPMI est accessible. L’objectif est clair : réduire les angles morts et savoir exactement quelles interfaces peuvent être atteintes depuis des réseaux externes ou internes.
2) Vérifier les comptes et la politique de mots de passe
Contrôlez les comptes d’administration existants : présence de mots de passe par défaut, utilisation de chaînes faibles, comptes “standard” nommés (comme admin/root) et configurations autorisant un nom d’utilisateur vide. Là où c’est possible, imposez une politique stricte de mots de passe et supprimez les comptes inutiles.
3) Limiter la surface réseau
Si des interfaces BMC ne doivent être accessibles que depuis un réseau d’administration, appliquez une restriction par réseau (listes d’accès, segmentation, pare-feu). L’idée est d’empêcher qu’une requête non autorisée atteigne un service exposé depuis des zones non prévues.
4) Renforcer la supervision du plan de gestion
La vulnérabilité concerne le plan de gestion. Il est donc logique de surveiller ce plan avec la même rigueur que les systèmes critiques : journalisation d’authentification, alertes sur comportements anormaux, contrôles d’accès et validation régulière des configurations.
5) Appliquer les correctifs et procédures constructeur
Enfin, assurez-vous que vos équipements suivent les recommandations de correctifs et de durcissement publiées par les fabricants. Même lorsqu’une faille date de plusieurs années, des correctifs et des mises à jour peuvent exister selon les générations matérielles et les firmwares.
En pratique : les signes d’une configuration à risque
Sans faire d’hypothèses hasardeuses, certains éléments doivent déclencher une vérification rapide :
- Interface IPMI joignable depuis des réseaux non strictement nécessaires.
- Existence de comptes par défaut ou de mots de passe faibles/particulièrement faciles à deviner.
- Comportements d’authentification inhabituels (par exemple acceptation d’identifiants vides ou formats “usine” prévisibles).
- Partage probable des bases d’utilisateurs entre IPMI, Redfish et l’interface web.
En combinant ces signaux avec l’inventaire de vos BMC, vous pouvez prioriser les systèmes à traiter en premier.
Conclusion : ne laissez pas les failles BMC devenir un accès furtif
Les failles BMC illustrent un risque souvent sous-estimé : le plan de gestion. Avec CVE-2013-4786, une exposition sur des interfaces IPMI peut faciliter la récupération de données d’authentification et accélérer des attaques hors connexion. Dans un datacenter, où les BMC contrôlent des fonctions critiques et restent disponibles même en cas de panne du système, cette combinaison peut transformer une faille ancienne en levier d’intrusion discret.
La bonne nouvelle : en renforçant l’inventaire, la segmentation réseau, la politique d’identifiants et la supervision du plan de gestion, vous réduisez fortement le potentiel d’impact. Traitez les BMC comme des systèmes “cœur”, pas comme de simples accessoires d’administration.
