Vulnérabilités critiques dans IPMI/BMC

Date : 16 Octobre 2013

Cet article du Cert-IST propose de revenir sur les failles de sécurité dans Intelligent Platform Management Interface (IPMI) et Baseboard Management Controller (BMCs).

Ces failles ont été initialement révélées début 2013 par Dan Farmer. Elles ont ensuite été mises en avant au cours de l’été 2013 par HD Moore (qui a publié début juillet un article baptisé A Penetration Tester's Guide to IPMI and BMCs), puis par des chercheurs de l’Université du Michigan qui ont présenté début aôut (à l’occasion de la conférence Usenix WOOT’13) une démonstration pratique de ces vulnérabilités IPMI sur les serveurs du constructeur « SuperMicro ».

Ces vulnérabilités exploitées par un attaquant peuvent aboutir à une prise de contrôle totale de l’IPMI. Après une brève description d’IPMI et BMC, cet article décrit les principales failles de sécurité découvertes, puis les scénarios d’attaque pouvant être mis en place par un attaquant. Pour finir, des solutions de contournements et des préconisations sont proposées.

 

1-      Présentation d’IPMI et BMC

IPMI (Intelligent Platform Management Interface) est un protocole d’administration distant qui permet de gérer à distance des serveurs au niveau hardware, indépendamment de l’OS installé :

  • Surveiller et visualiser certains composants (performance du disque et de la mémoire, sondes de température,..),
  • Obtenir des informations sur l’état du matériel d’un serveur,
  • Gérer des senseurs système,
  • Rebooter la machine,
  • etc.

IPMI est très répandu, et il est connu sous différents noms commerciaux : HP iLo, Dell iDrac, Oracle/SUN iLOM, Lenovo/IBM IMM, etc…

IPMI s’appuie sur un composant hardware (un circuit intégré) présent sur la carte mère de l’ordinateur : le BMC (Baseboard Management Controller).

 

2-      Les failles de sécurité

Les vulnérabilités révélées par Dan Farmer début 2013 sont issues d’une étude qu’il a réalisée en 2012. Elles montrent que de nombreux problèmes de sécurité existent avec IPMI et BMC :

  • Une grande majorité des fabricants active par défaut des fonctionnalités dangereuses d’IPMI.
  • Les utilisateurs n’ont aucune visibilité sur le fonctionnement du BMC.
  • Il n’existe aucun outil d’audit ou de forensics dédiés à ce type d’environnement.
  • La sauvegarde du firmware n’est pas toujours possible, ne permettant pas ainsi de restaurer le BMC dans un état antérieur.
  • Des backdoors semi-secrètes cachées sont installées par les fabricants afin de pouvoir accéder à leur serveur en cas d’opération de support.

Voici une description de certaines failles de sécurité découvertes :

  • Dans plusieurs implémentations d’IPMI version 2.0, si un client demande à activer le mode de chiffrement « Cipher 0 », alors l’authentification est désactivée. Dans ce cas, il suffit de connaitre le nom d’un compte BMC valide pour lancer à distance des commandes IPMI (par exemple avec l’outil linux « ipmitool ») sans fournir le mot de passe de ce compte !
  • Le processus d’authentification à distance RAKP (Remote Authenticated Key-Exchange Protocol) permet à un client non authentifié de demander au serveur IPMI le hash (SHA1 ou MD5) des mots de passe utilisateurs. Si les mots de passe ne sont pas robustes, ils pourront alors être retrouvés par le client, en utilisant des attaques par force brute ou par dictionnaire sur les hash. Ce problème est difficile à régler car il est dû à la spécification même d’IPMI. Cependant, on peut y pallier en isolant tous les BMC dans un réseau séparé.
  • De nombreux BMC sont configurés par défaut pour accepter une authentification anonyme, sans que cela soit forcement documenté. Dans ce cas, le premier compte utilisateur est défini par une chaine vide et un mot de passe vide.
  • Certaines implémentations d’IPMI activent par défaut le protocole UPnP (Universal Plug and Play), et il n’existe pas toujours de moyen pour le désactiver. Comme des vulnérabilités existent dans UPnP, Il est très probable qu’un attaquant pourra par ce moyen prendre le contrôle du BMC.

Nota : Dans le bulletin sécurité du mois de février 2013, le Cert-IST a abordé le thème des vulnérabilités dans UPnP dans l’article bulletin nommé « Etude Rapid7 sur les vulnérabilités du protocole UPnP »

  • Le respect des spécifications IPMI version 2.0 nécessite de stocker les mots de passe en clair dans un espace mémoire non volatile du BMC. Dans certaines implémentations (comme celle de Supermicro), un simple dump de cet espace mémoire permet de voler ces mots de passe.

Le BMC est un système embarqué, le plus souvent basé sur Linux, qui fonctionne de manière totalement autonome du système d’exploitation installé sur le serveur. Il est accessible depuis le réseau même si l’OS principal est éteint. Si le BMC est compromis (au moyen d’une des vulnérabilités listées ci-dessous), il est alors envisageable d’attaquer le système d’exploitation.

 

3-      Les scénarios d’attaque IPMI

HD Moore et les chercheurs de l’université du Michigan ont décrit de nombreux scénarios d’attaque possibles. Ainsi un attaquant peut deviner des mots de passe par défaut, exploiter des vulnérabilités ou flasher des firmwares malicieux. Voici les scénarios d’attaques les plus dangereux qui pourraient survenir une fois que le composant IPMI a été corrompu :

  • Prise de contrôle du système hôte : De base, les IPMI fournissent une fonction de déport écran/clavier sous forme d’un serveur KVM (Keyboard, Video and Mouse). De même, des fonctions de disques USB virtuels permettent d’importer ou exporter via IPMI des fichiers ou de fournir de nouveaux média de démarrage. En combinant ces fonctionnalités, un attaquant qui a obtenu un accès IPMI sur une machine distante pourra très probablement prendre le contrôle du système d’exploitation du serveur attaqué.
  • Spyware dans BMC : Si un attaquant peut installer un malware sur le BMC, il peut avoir une vue stratégique pour espionner le système et l’administrer. Il peut voler de cette façon les mots de passe utilisés lors des sessions d’administration à distance, ceux utilisés pour accéder à d’autres systèmes réseaux environnants, ou même ceux tapés sur la console physique du serveur.
  • Rootkits BMC persistants : L’installation de rootkits BMC persistants permet à des attaquants d’avoir accès au BMC à travers une porte dérobée, celle-ci restant cachée dans les journaux IPMI.
  • Attaque du BMC depuis un système hôte : Un attaquant qui compromet le système hôte peut l’utiliser pour tenter de compromettre le BMC. Par exemple, des tests de faisabilité ont été effectués sur les équipements Supermicro : ils ont montré que le logiciel fonctionnant sur le système hôte a pu « reflasher » le logiciel des BMC via l’interface KCS (Keyboard-Controller Style), sans aucune authentification ou sans signature de code.
  • Botnets sur les IPMI : un attaquant peut aussi décider d’installer un « bot » au niveau BMC, et créer un large réseau de botnets IPMI afin de profiter de la grande quantité de bande passante réseau mis à sa disposition.

 

4-      Les solutions de contournement / préconisations

Une liste non-exhaustive des bonnes pratiques et des mesures de défense est proposée ci-dessous :

  • Mettre à jour les firmware IPMI. Ces mises à jour sont cependant difficiles car elles doivent être faites manuellement.

Nota : Le Cert-IST a publié récemment deux avis relatifs à IPMI :

- CERT-IST/AV-2013.704 : Multiples vulnérabilités dans Cisco Unified Computing System (UCS)

- CERT-IST/AV-2013.568 : Vulnérabilité dans HP Integrated Lights-Out (iLO)

  • Ne pas mettre l’équipement IPMI directement sur Internet.
  • Utiliser un réseau de management isolé ou un vLAN.
  • Changer le mot de passe par défaut et les certificats.
  • Ne pas utiliser le même mot de passe pour toutes les machines IPMI, car en cas de compromission d’une machine cela évitera de compromettre toutes les autres (même s’il est tentant pour un administrateur d’avoir un même mot de passe lorsque celui–ci gère un grand parc de machines).
  • Superviser le trafic circulant sur le réseau de management.
  • Créer un inventaire contenant la liste des machines hébergeant un BMC.
  • Désactiver IPMI si cela n’est pas utilisé ou si cela n’est pas strictement nécessaire.
Au-delà du fait que l’opérateur de serveurs doit mettre en place des mesures de sécurité permettant d’améliorer le niveau de sécurité de son système, les développeurs de solutions ne sont pas en reste. La sécurisation des IPMI nécessite une expertise sécurité de la part des développeurs et un examen minutieux pendant les différentes phases du projet (phases de design, d’ingénierie et des tests). Les méthodes standards de défense doivent être utilisées comme :
  • Le « salting and hashing » des mots de passe.
  • La mise à jour automatique des firmwares en la protégeant avec une signature numérique.
  • L’utilisation de DEP (Data Execution Prevention) qui est un dispositif de sécurité intégré à de nombreux systèmes d’exploitation (Linux, Microsoft Windows,…). Il permet de prévenir l’exploitation de vulnérabilités informatiques (débordement de mémoire,..) lors de l’exécution de programmes. Cette technologie empêche des programmes d’attaques, d’insérer et d’exécuter des codes malveillants depuis certaines zones mémoires normalement réservées à des codes non exécutables.
  • L’ASLR (Address Space Layout Randomization ou distribution aléatoire de l'espace d'adressage) qui est une technique permettant de placer de façon aléatoire les zones de données dans la mémoire virtuelle. Ce procédé permet de limiter les effets des attaques de type dépassement de tampon par exemple. Elle consiste à rendre la configuration des processus « aléatoire », en plaçant différents éléments de base à des endroits variables.
  • Le « stack canarie » qui est une méthode permettant de détecter un débordement de la pile avant que ne se produise l’exécution d’un code malveillant. Le principe est de stocker une valeur, qui est générée de manière aléatoire au démarrage du programme, dans la mémoire juste avant le pointeur de la pile de retour. Si cette valeur est modifiée, l’exécution est avortée.
  • Des tests d’intrusion doivent aussi être utilisés afin de garantir la sécurité du système.

 

5-      Conclusions

IPMI joue un rôle important pour l’administration des serveurs. Pour autant la sécurisation de ces serveurs ne doit pas être négligée. L’étude réalisée par Dan Farmer montre que la sécurisation d’IPMI doit être considérée comme une préoccupation sérieuse. Et les démonstrations d’attaques faites par les chercheurs du Michigan montrent que le problème n’est pas que théorique.

Il est indispensable que ces vulnérabilités soient mieux connues et que des mesures de sécurité solides soient mises en place pour protéger les installations opérationnelles de ces attaques.

 

Vous trouverez des informations complémentaires sur les sites ci-dessous :

http://www.darkreading.com/management/new-gaping-security-holes-found-exposing/240157724

http://magazine.qualys.fr/menaces-alertes/vulnerabilite-ipmi-bmc/#sthash.j3aOOGmU.dpuf

http://arstechnica.com/security/2013/08/remote-admin-tool-imperils-servers/

http://www.securityweek.com/security-vulnerabilities-baseboard-management-controllers-rampant-research-finds

http://www.wired.com/threatlevel/2013/07/ipmi/

https://community.rapid7.com/community/infosec/blog/2013/01/29/security-flaws-in-universal-plug-and-play-unplug-dont-play

https://community.rapid7.com/community/metasploit/blog/2013/07/02/a-penetration-testers-guide-to-ipmi

Précedent Précedent Suivant Suivant Imprimer Imprimer