Microsoft Hyper-V: Une faille critique pourrait hanter les organisations pendant longtemps

0

Les détails techniques sont désormais disponibles pour une vulnérabilité qui affecte Hyper-V, l’hyperviseur natif de Microsoft pour la création de machines virtuelles sur les systèmes Windows et dans l’environnement de cloud computing Azure.

Actuellement identifié comme CVE-2021-28476, le problème de sécurité a un score de gravité critique de 9,9 sur 10. L’exploiter sur des machines non corrigées peut avoir un impact dévastateur car il permet de planter l’hôte (déni de service) ou d’exécuter du code arbitraire dessus.

Mettez fin aux machines virtuelles ou prenez le contrôle total

Le bogue se trouve dans le pilote de commutateur réseau d’Hyper-V (vmswitch.sys) et affecte Windows 10 et Windows Server 2012 à 2019. Il est apparu dans une version d’août 2019 et a reçu un correctif plus tôt cette année en Mai.

Les détails publics sur la faille sont rares pour le moment, mais dans un article de blog, les chercheurs Peleg Hadar de SafeBreach et Ophir Harpaz de Guardicore expliquent où se trouve la faille et pourquoi elle est exploitable. Les deux chercheurs ont trouvé le bogue ensemble et l’ont divulgué en privé à Microsoft.

La faille vient du fait que le commutateur virtuel d’Hyper-V (vmswitch) ne valide pas la valeur d’une requête OID (identifiant d’objet) qui est destinée à une carte réseau (externe ou connectée à vmswitch).

Une demande OID peut inclure le déchargement du matériel, la sécurité du protocole Internet (IPsec) et les demandes de virtualisation d’E/S racine unique (SR-IOV).

« Lors du traitement des requêtes OID, vmswitch trace leur contenu à des fins de journalisation et de débogage; cela s’applique également à OID_SWITCH_NIC_REQUEST. Cependant, en raison de sa structure encapsulée, vmswitch doit avoir un traitement spécial de cette requête et déréférencer OidRequest pour suivre également la requête interne. Le bogue est que vmswitch ne valide jamais la valeur de OidRequest et peut donc déréférencer un pointeur invalide », explique Harpaz.

Un attaquant qui exploite avec succès cette vulnérabilité doit avoir accès à une machine virtuelle (VM) invitée et envoyer un paquet spécialement conçu à l’hôte Hyper-V.

Le résultat peut être soit de planter l’hôte – et de mettre fin à toutes les machines virtuelles qui s’exécutent dessus, soit d’obtenir l’exécution de code à distance sur l’hôte, ce qui donne un contrôle total sur celui-ci et les machines virtuelles connectées.

Les organisations sont lentes à patcher

Bien que le service Azure soit à l’abri de ce problème, certains déploiements Hyper-V locaux sont probablement encore vulnérables, car tous les administrateurs ne mettent pas à jour les machines Windows lorsque les correctifs sont publiés.

Harpaz a déclaré que les vulnérabilités qui restent non corrigées pendant des années sur les machines des réseaux d’entreprise sont une chose courante pour Guardicore.

L’un des exemples les plus courants est EternalBlue qui est devenu connu en Avril 2017 – corrigé un mois plus tôt et mis à profit dans les cyberattaques destructrices WannaCry et NotPetya.

« Il y a tellement de serveurs Windows aujourd’hui qui sont vulnérables aux bogues bien connus, je ne serai pas surpris si ce bogue reste non corrigé pendant très longtemps dans les organisations. »

Ophir Harpaz

Harpaz et Hadar ont fait une présentation lors de la conférence sur la sécurité de Black Hat le 4 août sur leurs recherches et sur la découverte de la vulnérabilité à l’aide d’un programme de fuzzing interne appelé hAFL1.

Si cet article vous a plu, n’oubliez pas de jeter un œil à nos bons plans.

Laisser un commentaire