Risque(s)

  • Exécution de code arbitraire à distance

Systèmes affectés

  • AMI MegaRAC SPx-12 versions 0 à SPx-12-update-6.00
  • AMI MegaRAC SPx-13 versions 0 à SPx-13-update-4.00

Résumé

Contexte

Le 05 décembre 2022, trois vulnérabilités respectivement identifiées par les numéros CVE-2022-40259, CVE-2022-40242 et CVE-2022-2827 ont été signalées dans la solution d’administration à distance MegaRAC de l’éditeur AMI.

La solution MegaRAC s’appuie sur un BMC (Baseboard Management Controller) : un microcontrôleur intégré à la carte mère d’un serveur (ou installé comme carte fille) qui possède son propre stockage, son propre système d’exploitation et peut disposer d’un port réseau dédié ou partagé avec le système principal. Ce microcontrôleur est utilisé afin de fournir des capacités de gestion à distance en mode "hors bande" et "hors tension". Il permet aux administrateurs d’effectuer à distance un certain nombre de tâches qui nécessiteraient autrement un accès physique au serveur. Le processeur BMC dispose en effet d’accès aux différents composants de la carte mère, ce qui lui permet de surveiller le matériel, mettre à jour le micrologiciel du BIOS, mettre l'hôte sous tension, et permettre un déport clavier-écran-souris via le réseau. Souvent, il est connecté au bus PCIe et bénéficie d’un accès direct plus ou moins large à la mémoire en lecture et écriture (DMA, Direct Memory Access).

Ce contrôleur peut être accédé par différentes interfaces :

  • IPMI (Intelligent Platform Management Interface) : il s’agit d’un ensemble de spécifications d’interface permettant d’accéder aux fonctions du BMC via le réseau IP ;
  • Redfish, successeur de IPMI, proposant une interface RESTful pour la gestion des serveurs, du stockage et des réseaux. Redfish est pris en charge par les principaux fournisseurs de serveurs et d'infrastructures, ainsi que par le projet de micrologiciel OpenBMC ;
  • des protocoles réseau tels que SSH.

De nombreux constructeurs de carte mère intègrent la solution AMI MegaRAC dans leurs modèles pour serveurs.

Description

Ces trois vulnérabilités, d'une gravité moyenne à critique permettent une exécution de code à distance et un accès non autorisé à des périphériques requérant normalement des privilèges administrateur.

La première vulnérabilité, désignée par l’identifiant CVE-2022-40242, concerne l’existence d’un compte administrateur disposant d’un mot de passe par défaut.

La seconde vulnérabilité, CVE-2022-2827, permet d’énumérer les comptes configurés au niveau du BMC.

Enfin, la troisième vulnérabilité, CVE-2022-40259, offre la possibilité à un attaquant distant de tirer parti d’une mauvaise gestion des paramètres fournis dans l’URL pour exploiter un appel dans l’implémentation de l’API Redfish (IPMI). Cette vulnérabilité de type exécution de code arbitraire à distance requiert un niveau de privilège minimal de type « callback » ou supérieur.

L’attaquant pourra ainsi tirer parti des deux premières vulnérabilités pour obtenir un compte permettant d’exploiter la troisième.

La plupart des serveurs ont une configuration d’usine avec les interfaces IPMI ou Redfish activées et accessibles via un port réseau dédié ou via l’interface réseau principale de la carte mère, qui est alors partagée de manière transparente avec le système d’exploitation. Cette interface du BMC et son adressage sont généralement invisibles du système d’exploitation et des outils d’inventaire installés. Par ailleurs, l’une des fonctions du BMC est de pouvoir arrêter ou démarrer un serveur à distance, il reste donc alimenté et accessible via les interfaces IPMI, Redfish ou SSH même lorsque le serveur est éteint. En l’absence de procédure spécifique de configuration à la mise en service d’un serveur (spécifiquement pour ne pas exposer cette interface ailleurs que sur un réseau dédié à la gestion hors bande), il est très probable que les interfaces d’accès au BMC soient exposées par inadvertance.

Pour l’heure, rien n’indique que ces vulnérabilités aient pu faire l’objet d’attaques ciblées. Pour autant, ces vulnérabilités présentent un risque majeur car la solution MegaRAC est intégrée par de nombreux constructeurs de serveurs. La complexité de la chaîne d’approvisionnement ralentit le déploiement des correctifs, augmentant significativement l’exposition des serveurs utilisant cette solution à des attaques.

Chaînées ensemble, ces vulnérabilités permettent de prendre le contrôle à distance des serveurs, le vol de secrets critiques (par exemple empreintes et mots de passe en mémoire d’un contrôleur de domaine), le déploiement à distance de logiciels malveillants (par exemple des rançongiciels ou des implants de micrologiciel) y compris sur des machines virtuelles hébergées sur le serveur physique vulnérable. Du fait de son ancrage au niveau matériel, l’installation d’un implant au sein de l’IPMI constituerait une porte dérobée de premier choix, car celui-ci serait persistant à une réinstallation du système hôte voire à un changement de disque dur du serveur.

 

Recommandations

Au regard des possibilités offensives induites et du nombre d’équipements vulnérables, le CERT-FR recommande de manière générale, et pour l’ensemble des systèmes de gestion hors bande, de :

  • désactiver les interfaces d’accès au BMC si celui-ci n’est pas utilisé dans le cadre de la supervision et de l’administration à distance* ;
  • appliquer les correctifs publiés par les fabricants ;
  • s’assurer que tous les accès réseau aux sous-systèmes BMC (IPMI, Redfish, SSH, etc.) sont uniquement permis depuis sur un réseau de gestion dédié ;
  • activer les fonctionnalités de pare-feu proposées par IPMI ou Redfish afin de restreindre l’accès aux interfaces aux seuls postes d’administration ;
  • mettre en place un système de journalisation distante :
    • authentification
    • autorisation (utilisateurs / services)
    • état du système (mise sous tension / hors tension, redémarrage)
    • changements système (mise à jour du micrologiciel, chargement du micrologiciel après une compromission du système hôte)
  • désactiver ou changer les identifiants des comptes installés par défaut au niveau du BMC ;
  • respecter le principe du moindre privilège pour les actions de supervision ou de gestion au travers du BMC (rôles root, administrator, operator, user et callback).

 

* Il convient de noter que cela ne désactive pas le fonctionnement du contrôleur BMC mais réduit son exposition depuis le réseau

 

Solution

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

Documentation