Encore des Vulnérabilités dans Intel Management Engine

Quand on vous disait que le composant Intel Management Engine présent sur les cartes mères de vos PC et serveurs était un vrai risque de sécurité… Ce composant souffre à nouveau de vulnérabilités critiques.

Rappel sur Management Engine

Pour rappel, c’est un composant matériel et logiciel, autonome et ayant accès aux périphériques (réseau, disque dur…) mais également au microprocesseur et à la mémoire. Il peut donc interagir avec le système (Windows, Linux…), par contre, votre système n’a aucune possibilité de savoir ce que Management Engine fait, ni d’y avoir accès. Il est parfois appelé « Ring -3 » par opposition au niveau de privilèges « Ring 0 » (qui correspond aux droits d’administration sur votre système) et « Ring 3 » (le mode utilisateur sans privilèges spécifiques).

Pour la petite histoire, il s’agit de la version d’Intel des solutions d’administration à distance comme :

  • Les cartes additionnelles DRAC chez Dell (Dell Remote Access Controller) qui faut ajouter à un serveur ;
    alt
  • Leur version totalement intégrée nommée iDRAC ;
    alt
  • La version intégrée iLO chez HP* (Integrated Lights-Out).
    alt

Ces cartes ou interfaces permettent de gérer un serveur à distance, même si le système est planté. En général, les bonnes pratiques recommandent de les relier à des réseaux dédiés à l’administration.
Sur les postes de travail, il n’y a pas de port physiquement dédié à l’administration, d’où le fait que Management Engine soit joignable sur l’interface réseau principale (la seule en fait 😊). Il est donc joignable depuis le réseau « normal », que vous pouvez également appeler suivant les cas : réseau applicatif, LAN, prod, mon réseau à domicile…
Comme il doit permettre l’administration, même si le système est planté, s’il y’a du courant électrique et qu’un câble Ethernet est branché, alors Management Engine est joignable, oui, même si votre serveur ou PC est éteint !

De ce fait, Management Engine est considéré comme une porte dérobée car il est totalement fermé (jusqu’à récemment) et non documenté.

Désactiver Management Engine

Depuis plus de 10 ans, Management Engine était vu comme une boite noire et quelques travaux de recherche avaient tenter de le désactiver sans réel succès car sans ce composant, le matériel ne démarre pas ou coupe au bout de quelques minutes.
Certains, comme ici ou , ont tenté de supprimer tout le firmware (logiciel) à l’exception de la table de partition, mais le système coupe au bout de 30 minutes.

D’autres, comme ici ou , ont même tenté des attaques physiques mais sans résultat probant.

Minix

Intel fourni Management Engine sous forme de paquet compressé avec l’algorithme Huffman mais dont les tables ont été changées. Cela revient à une sorte de chiffrement du pauvre (ou du sournois 😉) car sans les tables, impossible de décompresser.
Heureusement, des chercheurs ont réalisé la rétroconception du logiciel de mise à jour de Management Engine et ont réussi à reconstruire ces tables, permettant enfin d'accéder au contenu de Management Engine.
Un outil a même été publié afin de simplifier la décompression de Management Engine.

Après avoir ouvert le capot, les chercheurs ont découvert que Management Engine était basé sur le système d’exploitation open source Minix 3, conçu pour être résistant (insensible) aux pannes, en les détectant et les réparant à la volée. Il est important de noter que Minix 3 a été financé par l’Europe à hauteur de 2,4 millions d’euros.

En poussant l’analyse un peu plus (voir ici et ), il a été découvert une fonctionnalité nommée HAP : High Assurance Platform, liée à la NSA, et permettant de désactiver « partiellement » Management Engine.
Les agents de la NSA utilisent des postes de travail (et serveurs), comme tout le monde, basés sur des composants classiques, et il leur fallait donc une solution pour désactiver cette porte dérobée. Intel étant américain, une fonctionnalité de désactivation partielle a donc été ajoutée, bien que difficile à utiliser hors NSA. Merci la NSA.

Vulnérabilité de mai

En mai dernier, une vulnérabilité triviale a été découverte sur Management Engine, permettant de prendre le contrôle d’un poste ou d’un serveur (physique) à distance, sans que l’utilisateur ou le système ne le détecte.
Vous trouverez ici un exemple simple pour l’exploiter, et encore un autre.

Vulnérabilités de novembre

Ceci nous amène donc à ces nouvelles vulnérabilités de novembre.
Intel a publié un bulletin présentant 8 vulnérabilités critiques, principalement des élévations locales de privilèges :

  • Intel® Management Engine (ME) 11.x: CVE-2017-5705 , CVE-2017-5708, CVE-2017-5711, CVE-2017-5712

  • Intel® Server Platform Service 4.0.x.x : CVE-2017-5706 , CVE-2017-5709

  • Intel® Trusted Execution Engine (TXE) 3.0 : CVE-2017-5707 , CVE-2017-5710

Le point important ici est le terme « locales ».
Ces vulnérabilités sont-elles exploitables uniquement si un attaquant réussit à avoir accès au système Minix de Management Engine ?
Dans ce cas, la probabilité d’exploitation me parait particulièrement faible.
Par contre, si ces vulnérabilités sont exploitables depuis le système d’exploitation installé sur le serveur, la situation commence à devenir critique.
Si, en plus, ces vulnérabilités sont exploitables depuis une machine virtuelle hébergée par un hyperviseur installé sur le serveur, alors là, la criticité est tout autre et nous avons un sérieux problème.

Que faire ?

La réponse est simple (à écrire 😉) : il faut faire un état des lieux, évaluer ses risques et mettre à jour si nécessaire.

Voici la liste des équipements affectés pour les constructeurs que j’ai pu trouver :

Intel a publié un outil permettant de vérifier si vous êtes impactés.
J’ai testé l’outil dans les conditions suivantes :

  • Mon poste NetXP Dell avec Windows 10 installé directement dessus -> l’outil fonctionne et mon poste ne semble pas vulnérable
  • Une machine virtuelle sous VMware Workstation -> l’outil ne fonctionne pas
  • Une machine virtuelle sous VMware ESXi -> l’outil ne fonctionne pas
  • Un poste Lenovo ThinkPAd chez un client -> l’outil fonctionne et le poste est vulnérable, comme indiqué dans la capture d’écran ci-dessous
    alt

Que faire 2 ?

Plus globalement, avec ce type de vulnérabilités, le niveau de sécurité d’une infrastructure sans filtrage est conditionné par l’application la moins sécurisée. Supposons un hébergement de nombreuses applications et serveurs exposés sur internet. En cas de compromission d’une application avec prise de contrôle du serveur, alors tous les autres serveurs deviendront vulnérables par l’utilisation de ces vulnérabilités ou de celles qui seront découvertes à l’avenir.
Nous en revenons alors aux bonnes pratiques de zoning : segmenter et donc définir des zones par niveau de sécurité ou de criticité. La micro-segmentation peut également être une solution avec des solutions comme NSX de VMware.

A noter que les iLo d’HP sont tout aussi vulnérables et cela sera présenté à la conférence RuxCon 2018 « Subverting your server through its BMC: the HPE iLO4 case »
La présentation sera faite par trois experts français : Alexandre Gazet, Joffrey Czarny et Fabien Perigaud.
Ici, le bulletin d’HP sur les vulnérabilités qui seront présentées.
Il ya plusieurs vulnérabilités, référencées par un seul numéro de CVE : CVE-2017-12542