Les machines virtuelles sont-elles vraiment sécurisées? Faux sentiment de sécurité?
Je lisais ceci Livre CompTIA Security + SYO-201 , et l'auteur David Prowse affirme que:
Quel que soit VM que vous sélectionnez, le VM ne peut pas franchir les limites logicielles définies. Par exemple, un virus peut infecter un ordinateur lorsqu'il est exécuté et se propager à d'autres fichiers) dans le système d'exploitation. Cependant, un virus exécuté dans un VM se propagera à travers le VM mais n'affectera pas le système d'exploitation réel sous-jacent).
Donc, si j'exécute VMWare Player et que j'exécute des logiciels malveillants sur le système d'exploitation de ma machine virtuelle, je n'ai pas à me soucier de la compromission de mon système hôte, ( du tout ?
Que faire si la machine virtuelle partage le réseau avec la machine hôte et que les dossiers partagés sont activés?
N'est-il pas encore possible pour un ver de se copier sur la machine hôte de cette façon? L'utilisateur n'est-il pas toujours vulnérable à l'exécution automatique si le système d'exploitation est Windows et qu'il insère un périphérique de stockage USB?
Les machines virtuelles sont-elles vraiment sécurisées? Dans quelle mesure protègent-ils la machine hôte contre les logiciels malveillants et les attaques?
Les VM peuvent définitivement traverser. Habituellement, vous les avez en réseau, donc tout malware avec un composant réseau (c'est-à-dire des vers) se propagera partout où leur adressage/routage le permettra. Les virus ordinaires ont tendance à fonctionner uniquement en mode utilisateur, donc même s'ils ne pouvaient pas communiquer ouvertement, ils pouvaient tout de même établir un canal secret. Si vous partagez des processeurs, un processus occupé sur un VM peut communiquer efficacement l'état à un autre VM (c'est votre canal secret de synchronisation prototypique). Le canal secret de stockage serait être un peu plus difficile car les disques virtuels ont tendance à avoir une limite stricte, donc à moins que vous n'ayez un système qui peut surcharger l'espace disque, cela ne devrait pas être un problème.
L'approche la plus intéressante pour sécuriser les VM s'appelle Separation Kernel . C'est le résultat de John Rushby's 1981 paper qui stipule essentiellement que pour que les VM soient isolées d'une manière qui pourrait être équivalente à une séparation physique, l'ordinateur doit exporter ses ressources vers des VM spécifiques de manière à aucun point aucune ressource qui peut stocker l'état est partagée entre les machines virtuelles. Cela a des conséquences profondes, car il nécessite que l'architecture informatique sous-jacente soit conçue de manière à ce que cela puisse être effectué de manière non contournable.
30 ans après ce papier, nous avons enfin peu de produits qui prétendent le faire. x86 n'est pas la meilleure plate-forme pour cela, car il existe de nombreuses instructions qui ne peuvent pas être virtualisées, pour prendre pleinement en charge l'idée "sans partage". Ce n'est pas non plus très pratique pour les systèmes courants, car pour avoir quatre machines virtuelles, vous auriez besoin de quatre disques durs suspendus à quatre contrôleurs de disque, quatre cartes vidéo, quatre contrôleurs USB avec quatre souris, etc.
Il y a eu quelques livres blancs publiés au fil des ans décrivant comment les chercheurs ont réussi à infester un OS hôte à partir d'une machine virtuelle. Celles-ci sont généralement considérées, à juste titre, comme des vulnérabilités de sécurité par les fournisseurs VM et traitées comme telles. Depuis que j'ai vu ces documents pour la première fois, Intel a apporté d'importantes améliorations au jeu d'instructions du processeur pour permettre la séparation des VM et hyperviseur.
Les quelques vulnérabilités que je vois ces jours-ci sont basées davantage dans la partie "vmtools". Il s'agit du logiciel que vous installez pour rendre le système d'exploitation invité plus efficace (pour VMWare, c'est ce qui permet la capture du curseur à la volée et le partage entre l'invité et l'hôte sans réseau). Il s'agit d'une voie logicielle spéciale pour l'infection; n'installez pas les outils, ne disposez pas de la vulnérabilité.
Certains logiciels malveillants ont montré la capacité de détecter qu'ils sont exécutés dans un VM et donc de changer leur comportement, au grand dam des chercheurs de logiciels malveillants qui tentent d'utiliser des machines virtuelles comme moyen de tester les logiciels malveillants. Je ne sais pas à quel point c'est répandu de nos jours, cependant.
Un exemple d'exécution de code invité-à-hôte peut être trouvé dans l'exploit Cloudburst. Il y a une vidéo démontrant et un article d'Immunity détaillant leur succès sur VMware Workstation 6.5.0 build118166 sur Windows Vista SP1, VMware Workstation 6.5.1 build126130 sur Windows Vista SP1 et (encore plus effrayant) VMware ESX Server 4.0.0 build133495.
Cela fournit probablement peu de réconfort, mais je n'ai jamais entendu parler de son utilisation dans la nature et l'exploit date de 2009. Ce livre a été publié en 2010, donc l'auteur devrait nettoyer cette déclaration.
Une machine virtuelle est exactement cela, une machine logiquement séparée, donc elle doit avoir les mêmes couches de sécurité placées dessus comme vous le feriez pour un système bare-metal. L'utilisation d'une machine virtuelle n'arrête pas une machine virtuelle si elle utilise des canaux normaux pour se rendre à la machine hôte.
La vraie beauté de la virtualisation est la possibilité de restaurer les machines virtuelles dans un état où elles n'ont pas été affectées, ainsi que la possibilité de mieux gérer les ressources disponibles.
Si les mesures appropriées sont prises pour protéger la machine hôte, la virtualisation peut être extrêmement sécurisée. Des pratiques telles que le maintien de la gestion du serveur ESX/VM sur un réseau logique différent et l'absence d'utilisation des outils d'interface VM-Host garderont les attaquants la plupart du temps inconscients du fait qu'une machine est virtuelle, et encore moins comment se rendre à l'hôte.
En outre, il existe des exploits connus qui affectent VM hôtes (j'ai joué avec eux dans VMWare et Hyper-V). Je ne connais actuellement que les exploits Host DoS en matière d'hyper- v (voir this ), mais je suis sûr qu'il y a d'autres découvertes à l'horizon. VMWare en a aussi dans son histoire (ie this , il est basé sur les outils VMWare, mais cela s'applique toujours).
Selon ce que vous faites, il existe des outils en ligne qui peuvent supprimer votre besoin de faire l'analyse sur votre propre machine. Voici quelques sites à visiter:
- Threatexpert.com
- anubis.iseclab.org
- virustotal.com
Ce que signifie le matériel Security + est que, jusqu'à présent, les logiciels malveillants n'ont pas pu échapper au bac à sable du VM en exploitant le fait qu'il s'agit d'un VM et en quelque sorte frapper l'hyperviseur. D'autres mécanismes, tels que la propagation sur un réseau partagé, sont les mêmes que s'il s'agissait de boîtes physiques différentes.
Ils ne sont pas parfaitement sécurisés, comme le démontre cet exploit:
VENOM, CVE-2015-3456, est une vulnérabilité de sécurité qui affecte certaines plates-formes de virtualisation informatique courantes, notamment Xen, KVM, VirtualBox et le client QEMU natif.
Cette vulnérabilité peut permettre à un attaquant de s'échapper des confins d'un invité de machine virtuelle (VM) affecté et potentiellement obtenir un accès d'exécution de code à l'hôte. Plus de détails concernant la vulnérabilité peut être trouvé ici.
Je pense que l'affirmation de l'auteur n'est pas complètement vraie. En fait, il existe deux types d'hyperviseur dans la zone de virtualisation. Hyperviseur est un logiciel, micrologiciel ou matériel informatique qui crée et exécute machine virtuelle s. Ces types sont:
- Hyperviseurs de type 1
- Hyperviseurs de type 2
L'hyperviseur de type 1 s'exécute directement sur le matériel de l'hôte pour contrôler le matériel et gérer les systèmes d'exploitation invités. Pour cette raison, ils sont parfois appelés hyperviseurs en métal nu alors que L'hyperviseur de type 2 fonctionne sur un système d'exploitation conventionnel tout comme les autres programmes informatiques. VMWare ou VirtualBox sont des exemples d'hyperviseur de type 2 car ils sont exécutés en tant que programmes dans l'hôte [~ # ~] os [~ # ~ ] s.
Pour les hyperviseurs de type 2, il existe RoboLinux projet qui possède une fonctionnalité unique appelée VM furtive . Stealth VM qui vous permet de créer un clone Windows 7 fonctionnant dans une partition Linux sécurisée . Le système est protégé contre les logiciels malveillants, tout ce que vous téléchargez sera contenu avec dans la machine virtuelle et il est destiné aux personnes qui doivent avoir un programme Windows spécifique avec la commodité de pouvoir restaurer le système d'exploitation comme nouveau en seulement deux clics.
Il y a OS Qubes qui est développé sur Linux et Xen comme exemple pour les hyperviseurs de type 1. Qubes OS adopte une approche appelée sécurité par isolation , ce qui signifie dans ce contexte de garder les choses que vous faites sur votre ordinateur bien isolées dans différentes machines virtuelles de sorte qu'une VM mise en danger n'affectera pas les autres. Contrairement aux hyperviseurs de type 2, elle dispose d'un système sécurisé système de transfert de fichiers inter-VM pour gérer le risque de partage de dossiers. En théorie, cette organisation est plus sécurisée que la virtualisation de type 2 selon les développeurs.
En bref, l'auteur doit indiquer quel hyperviseur ou système virtuel.
Références :
D'intérêt et de pertinence, le concours de sécurité "Pwn2Own" pour 2016 a comme l'une de ses compétitions, de s'échapper d'une machine virtuelle VMWare Workstation. (D'autres incluent la fuite des bacs à sable du navigateur ou la reprise de machines physiques). Cela devrait donner une idée que 1) c'est au moins plausible et 2) si c'est facile, alors nous avons un moyen de l'entendre - il suffit de vérifier le résultat :)
Plus généralement VM la sécurité pourrait en théorie être échappée de plusieurs manières. Par exemple -
Commandes et API invité à hôte (par exemple, outils VMware)
Faiblesses exploitables dans le système d'exploitation hôte lui-même qui ne sont pas atténuées en exécutant un processus VM (si certains appels du système d'exploitation invité sont jugés à tort "sûrs" et transmis directement par un pilote invité au système d'exploitation hôte ou pilote de périphérique pour la vitesse, mais un exploit existe)
Bogues dans les pilotes ou le code fournisseur (par exemple, un pilote hôte permet le pontage réseau pour le système d'exploitation invité; peut-être qu'un bogue dans celui-ci pourrait permettre que des appels ou du code soient effectués sur l'hôte au niveau du noyau).
Vulnérabilités résultant d'autres logiciels sur l'hôte (exemple artificiel - si un antivirus local intercepte tout le trafic réseau de l'hôte à analyser, et le trafic invité est analysé dans le cadre de cela (par opposition à être ignoré en raison de virtuel NIC périphérique), une vulnérabilité du moteur a/v à un trafic ou un paquet spécialement conçu pourrait permettre au trafic provenant de VM de s'échapper vers l'hôte)
Mauvaise configuration par l'utilisateur (fichiers hôtes mappés ou insuffisamment sécurisés/séparés pour que l'invité puisse les atteindre)
La portée existe, et compte tenu de la prévalence, elle est sûrement examinée activement pour les exploits. Il est certain que des vulnérabilités sinon des exploits seront régulièrement trouvés et devront être corrigés.