VMware a émis des bulletins de sécurité pour deux de ses produits, vSphere Data Protection (ci-dessus) et vSphere Hypervisor.
Deux mises à jour de sécurité viennent d'être livrées par VMware. La première est jugée critique par l'éditeur de solutions de virtualisation. Elle concerne vSphere Data Protection qui pourrait être attaquée à distance. La 2ème, importante, porte sur EXSi.
VMware a livré un correctif pour vSphere Data Protection (VDP) pour modifier une clé SSH codée en dur qui pourrait fournir à des attaquants distants un accès racine à l'appliance virtuelle. VDP est une solution de back-up et de restauration sur disque qui s'utilise dans une appliance virtuelle ouverte. Elle s'intègre avec vCenter Server et permet de gérer de façon centralisée les opérations de sauvegarde des machines virtuelles (jusqu'à 100 VM). Selon un message du support de VMware, l'appliance VDP contient une clé privée SSH statique associée à un mot de passe connu. Cette clé permet l'interopérabilité avec la solution de sauvegarde et restauration Avamar d'EMC qui intègre une technologie de déduplication et qui est préconfigurée sur VDP comme une clé autorisée.
« Un attaquant ayant un accès au réseau interne pourrait s'en servir pour accéder à l'appliance avec des privilèges racines pour compromettre l'ensemble », explique VMware. L'éditeur qualifie cette vulnérabilité de critique et a donc développé un correctif qui peut être copié et exécuté sur l'appliance pour modifier les clés SSH par défaut et installer un nouveau mot de passe.
Une faille XSS stockée dans vSphere Hypervisor
Développer des systèmes avec des accès codés en dur que les utilisateurs ne peuvent pas changer peut déboucher sur des sérieuses défaillances de sécurité. Malheureusement, cela a été une pratique courante pendant un temps et les fournisseurs ont essayé ces dernières années de rectifier ce type d'erreurs. Hier, VMware a également corrigé une faille XSS (cross-site scripting) stockée dans vSphere Hypervisor (reposant sur ESXi). Cette faille est jugée importante.
Le problème peut venir d'un attaquant qui aurait la permission de gérer des machines virtuelles à travers ESXi Host Client ou bien d'un administrateur vSphere abusé qui aurait importé une VM malveillante, explique l'éditeur dans un bulletin d'alerte. « Il peut être déclenché sur le système depuis l'endroit où ESXi Host Client est utilisé pour gérer la VM spécifiquement développée ». Les correctifs sont livrés pour ESXi 5.5 et 6.0 pour combler cette faille. L'éditeur rappelle aux utilisateurs qu'ils ne doivent pas importer de VM venant de sources non fiables.
Suivez-nous