8 questions pour comprendre la dernière vulnérabilité affectant VMware ESXi et vCenter Server (CVE-2021-21972)

Mikhail Klyuchnikov, expert en sécurité chez Positive Technologies à récemment découvert une vulnérabilité au sein de Vcenter Server.
La vulnérabilité a été découverte en automne 2020 et remontée à VMware en octobre 2020. Un correctif est disponible depuis le 23 février 2021.

Que sont VMware ESXi et vCenter Server ?

VMware ESXi est une plate-forme de virtualisation majoritairement utilisée par des entreprises. Elle permet de déployer plusieurs systèmes d’exploitation différents (Windows, Linux, etc.) sur une même machine physique. Les différents systèmes déployés sont totalement indépendants et sont appelés machine virtuelle.
L’utilisation de la virtualisation par les entreprises permet de faciliter le déploiement et la gestion de leurs serveurs. L’installation n’étant plus effectuée sur des machines physiques, elle peut être plus facilement automatisée et permet de gagner en flexibilité.

VCenter Server est un composant permettant de gérer plusieurs ESXi, ainsi que les machines virtuelles déployées.

src : https://www.onlinecomputertips.com/support-categories/hardware/463-server-virtualization-explained

Les deux solutions sont vendues par VMware et affichaient en 2017 une part de marché de 80 %.

VMware ESXi est un composant critique au sein des systèmes d’information de nombreuses entreprises.

D’où provient la vulnérabilité ?

• La vulnérabilité provient d’un plug-in de vCenter dédié à l’automatisation (vRealize Orchestrator) installé par défaut. Celui-ci exposait plusieurs API à l’adresse `/ui/vropspluginui/rest/services/*` qui ne demandait pas d’authentification.
• Une des API exposées à l’adresse `/ui/vropspluginui/rest/services/uploadova` permettait de téléverser des archives ova. Les ova sont des archives `tar` (un format d’archive courant dans le monde UNIX) contenant les informations nécessaires à la création de machines virtuelles.
• Lors du traitement de la requête API, l’archive était décompressée dans le dossier`/tmp/unicorn_ova_dir`. Chaque fichier de l’archive était extrait un par un et son chemin d’extraction était obtenu en concaténant `/tmp/unicorn_ova_dir` avec le chemin du fichier au sein de l’archive.
• La plupart des utilitaires d’archive interdisent la possibilité d’avoir des chemins remontant l’arborescence du système de fichier (ex :`../../mon_fichier.txt`). Cependant, un utilitaire open source (https://github.com/ptoomey3/evilarc) permet de créer des archives malicieuses implémentant cette fonctionnalité. Cette méthode de compromission d’un système est connue sous le nom de`directory traversal`.
• Grâce à cela, l’attaquant pouvait disposer d’une primitive d’écriture sur tous les dossiers où l’utilisateur exécutant le processus avait le droit d’écriture. Dans ce cas précis, il s’agit de vsphere-ui.
• Une fois la primitive d’écriture obtenue, il était possible d’obtenir une exécution de code à distance. La méthode et le résultat étant différents sous Windows et sous Linux

Sous Windows

• Il était possible d’écrire dans le dossier `C:ProgramDataVMwarevCenterServerdataperfchartstc-instancewebappsstatsreport`
• Ce répertoire est dédié au stockage des fichiers de template Java (JSP – Java Server Pages). Ces fichiers sont accessibles sans authentification. Un attaquant peut donc profiter de ce répertoire pour y insérer son propre fichier et ainsi exécuter du code sur le système lorsqu’il y accède.
• Une fois les fichiers implantés sur la machine, ils étaient exécutés avec les privilèges`NT AUTHORITYSYSTEM`.
• Afin d’exploiter la vulnérabilité, l’attaquant pouvait téléverser une Webshell (page Web permettant d’exécuter des commandes sur le serveur distribuant le fichier) afin d’obtenir un accès sur la machine.

Sous Linux

• Aucun dossier contenant des fichiers `JSP` n’était accessible en écriture pour l’utilisateur`vsphere-ui`. Néanmoins, cet utilisateur disposait des droits d’écriture dans le répertoire/home/vsphere-ui/. ssh. Cela rendait donc possible l’écrasement du fichier ~/. ssh/authorized_keys.
• L’attaquant pouvait ainsi remplacer le fichier`authorized_keys`, par un fichier contenant sa propre clef SSH.
• Une fois sa clef téléversée, l’attaquant pouvait se connecter en `SSH` (service permettant d’administrer des serveurs à distance) pour pouvoir exécuter des commandes en tant que`vspehre-ui`.

Qu’est-ce un directory traversal et comment s’en prémunir?

Une vulnérabilité de type `directory traversal` est une vulnérabilité ou l’attaquant va utiliser des chaines de caractères tel que ‘../’ ‘..’ afin de remonter l’arborescence de fichier et écrire, lire ou exécuter un fichier en dehors du dossier d’origine.
La vulnérabilité vient de la manière dont les systèmes d’opération traitent les chemins de fichier.
Par exemple le chemin `/var/www/http/pages/../../../../etc/shadow` est équivalent au chemin `/etc/shadow`
Lorsqu’un chemin est créé à partir de la concaténation d’une entrée utilisateur avec un nom de dossier, l’attaquant peut ainsi créer un chemin vers l’intégralité du système de fichier.
Par exemple l’instruction :
`new File(« /mon/dossier/donnee/utilisateur »,user_input)` peut laisser penser que le fichier désigné sera forcément dans un dossier fils de `/mon/dossier/donnee/utilisateur`, alors qu’avec une valeur comme `user_input = « ../../../../bad.txt« ` le fichier sera situé à la racine du système de fichier.

Afin de prévenir cette vulnérabilité, deux méthodes sont conseillées ( à appliquer ensemble ):
— Réaliser une validation sur l’entrée utilisateur (certain caractère tel que /,) peuvent être interdit. Le mieux étant de définir une liste de caractère utilisée.
— Une fois le chemin du fichier généré, vérifier que celui-ci est un descendant du dossier voulu. Le chemin le plus court d’un fichier s’appelle le `canonical path` et de nombreux langages proposent des fonctions telles que `getCanonicalPath` afin de l’obtenir depuis un pointeur de fichier ou un chemin relatif.

Quel est l’impact de la vulnérabilité ?

L’exploitation de la vulnérabilité référencée CVE-2021-21972 permet à un utilisateur non authentifié de créer un fichier sur le serveur vCenter (avec les privilèges de l’utilisateur vsphere-ui). L’attaquant peut ensuite prendre le contrôle du système avec les privilèges `NT AUTHORITYSYSTEM` pour les serveurs installés sous Windows, et vsphere-ui pour les serveurs installés sous Linux.

La vulnérabilité est-elle facilement exploitable ? Des codes d’exploitation sont-ils disponibles ?

Quatre codes d’exploitation étaient disponibles la journée suivant la révélation de la vulnérabilité par VMWare :

• NS-Sp4ce/CVE-2021-21972
• QmF0c3UK/CVE-2021-21972-vCenter-6.5-7.0-RCE-POC
• horizon3ai/CVE-2021-21972
• yaunsky/CVE-2021-21972

L’exploitation de cette vulnérabilité reste relativement simple à réaliser. En effet, il suffit à l’attaquant d’exécuter les codes d’exploitation disponibles publiquement en respectant les indications fournies par les auteurs. Cette opération ne requiert aucun outil particulier.

De plus, la détection de serveurs VMware vCenters connectés à Internet est facilitée par l’utilisation de services comme Shodan. Une simple requête sur le moteur de recherche indique que plus de 6700 serveurs sont potentiellement vulnérables.

La vulnérabilité fait-elle l’objet d’une campagne d’exploitation ?

Selon les chercheurs de la société`Bad Packets`, des attaquants ont lancé des scans d’Internet à grande échelle afin de détecter des instances à compromettre. Cette opération est survenue seulement quelques heures après la publication du code d’exploitation.

Comment savoir si je suis affecté par la vulnérabilité ?

Vous êtes affectés par la vulnérabilité si vous possédez une version de vCenter Server suivante :

[highlight2]vCenter Server 7.x < 7.0 U1c[/highlight2]

vCenter Server 6.7.x < 6.7 U3l  vCenter Server 6.5.x < 6.5 U3n

[highlight2]Cloud Foundation (vCenter Server) 4.x < 4.2
Cloud Foundation (vCenter Server) 3.x < 3.10.1.2[/highlight2]

Pour déterminer votre version de vCenter Server depuis vSphere Web Client depuis l’onglet Version Information de la page `Summary` de votre sevré vCenter Server.

Comment se protéger contre l’exploitation de cette faille ?

Afin de se protéger de cette vulnérabilité, le CERT-XMCO recommande l’installation de l’une des versions suivantes de vCenter Server et VMWARE ESXi :

[highlight2]vCenter Server 7.0 U1c: https://my.vmware.com/web/vmware/downloads/details?downloadGroup=VC70U1C&amp;productId=974[/highlight2]

vCenter Server 6.7 U3l: https://my.vmware.com/web/vmware/downloads/details?downloadGroup=VC67U3L&amp;productId=742&amp;rPId=57171
vCenter Server 6.5 U3n: https://my.vmware.com/web/vmware/downloads/details?downloadGroup=VC65U3N&amp;productId=614&amp;rPId=60942

VMware propose aussi une solution de contournement afin de protéger un système pouvant être impacté.
La procédure de désactivation du plug-in concerné peut être trouvée à l’adresse suivante : https://kb.vmware.com/s/article/82374.

De plus, il est important de ne pas exposer une instance de vCenter Server directement sur Internet.

Dois-je appliquer les correctifs en urgence ?

Oui. Cette vulnérabilité est critique, et pourrait impacter directement l’image de votre entreprise et l’intégrité du système d’information. De plus, son exploitation ouvre potentiellement une porte sur votre système d’information.

Liens utiles :

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-BCBA66C3-AECA-48A0-B139-3FC59EB42880.html