De plus en plus d’entreprises se lancent dans la virtualisation de leurs informatiques internes et de leurs informatiques orientées Internet (sites web, serveurs de mail, serveurs de DNS, etc.). Le gain en ressources et l’optimisation de celles-ci est évident, mais la plupart du temps, les infrastructures virtualisées omettent l’aspect de la sécurité. Il n’est pas rare de retrouver sur un hôte virtuel des “guests” privés (qui ne sont pas censés être en contact direct avec Internet) et des “guests” publics (qui sont autorisés d’être exposés à Internet), ou encore l’on peut retrouver des serveurs hôtes qui sont rarement mis à jour, car cela demanderai des migrer ou d’arrêter tous les serveurs “guests” localisés sur ces hôtes.

De plus, le marketing de la virtualisation, pousse a faire croire à leurs clients que la sécurité de ces solutions est éprouvées, le “mythe de la sécurité par la virtualisation”. Ce mythe est de plus en plus mis à mal par les différentes découvertes effectuées par des chercheurs en sécurité informatique.

SecuraBit, un podcast que je vous conseille, a présenté dans son épisode 33, une interview de Kostya Kortchinsky qui a développé un exploit se nommant CLOUDBurst permettant de prendre la main sur l’hôte VMWare et sur tous les “guests” VMWare en passant par un des “guest” VMWare.

La vulnérabilité, permettant que l’exploit CLOUDBurst fonctionne, affecte VMWare WorkStation, VMWare Server, VMWare ESX et VMWare Fusion (CVE-2009-1244).

Il faut tous de même avoir accès à un guest afin de lancer CLOUDBurst, mais pour cela quoi de plus simple que de louer un serveur virtuel 

Lien vers la vidéo de démonstration de CLOUDBurst sur Immunity.

Dans le même ordre d’idée, Rob VandenBrink a présenté sur le podcast PaulDotCom, une présentation et démonstration d’une attaque du type SSL MITM lors de la migration VMotion d’un “guest” virtuel, tournant sur VMWare ESX. Cette technique d’attaque SSL MITM va permettre de récupérer tous les contenus affichés actuellement à l’écran (par exemple, les mots de passe que vous êtes en train de saisir, etc.), malgré que les flux entre les deux serveurs VMWare ESX soient chiffrés par défaut.

[vimeo 5219962]