Isoler complètement une machine VirtualBox

17

Je voudrais utiliser VirtualBox pour installer un logiciel qui ne devrait pas avoir accès à mon ordinateur hôte (et vice-versa). Cependant, j'envisage également la possibilité de tenter des choses plus "dangereuses", comme essayer d'exécuter des exploits zero-day et voir ce qu'ils peuvent faire.

Dans quelle mesure une machine virtuelle peut-elle être isolée de l'hôte? Dois-je (ou puis- je?) Mettre en place un pare-feu entre l'invité et l'hôte? Les modules complémentaires invités constituent-ils un risque pour la sécurité? Qu'en est-il des répertoires partagés?

À l'heure actuelle, la machine invitée exécute les tests Debian GNU / Linux.

giusti
la source
7
Stack Exchange dispose d'un groupe de sécurité de l'information si vous souhaitez poser des questions de sécurité détaillées.
cybernard
Appuyant @cybernard ici. Après un peu de développement, ce serait une question extrêmement appropriée pour Security.SE, en supposant que ce n'est pas un doublon (ce qui, je le crains, pourrait bien être, compte tenu de la croissance de leur communauté).
0xdd
1
Vous ne devez pas utiliser VirtualBox, car il interagit avec votre système via un module de noyau, ce qui représente un risque beaucoup plus élevé que les implémentations en espace utilisateur pur. Et surtout le module de noyau de boîte virtuelle est considéré comme de la merde par les développeurs du noyau. Un meilleur choix est un émulateur comme qemu fonctionnant en tant qu'utilisateur non privilégié qui n'a accès à rien d'intéressant et des règles de pare-feu qui empêchent l'accès au réseau pour cet utilisateur. (Poster en tant que commentaire car il ne répond pas directement à la question concernant VirtualBox)
allo

Réponses:

36

Je commencerai par dire que cette question est très large et montre très peu de recherches originales, et que cette réponse ne doit pas être considérée comme un encouragement à ce type de question. Au lieu de cela, cette réponse espère fournir des conseils de sécurité extrêmement basiques aux personnes qui commencent tout juste par l'analyse de logiciels malveillants.

En supposant que vous exécutez des logiciels malveillants connus et précédemment recherchés, la façon dont vous isolez votre environnement dépend fortement de la capacité de ce logiciel malveillant. Certaines règles générales qui s'appliquent à la plupart des logiciels malveillants modernes peuvent être les suivantes:

  • Isolez votre machine virtuelle d'Internet. Cela peut être aussi simple que de ne pas configurer le transfert d'interface vers la machine invitée, et empêche le malware de communiquer avec les nœuds de commande et de contrôle potentiels qui pourraient l'obliger à agir de manière imprévisible.

  • Utilisez un hyperviseur approprié. Il y en a quelques-uns sur le marché, notamment VirtualBox, HyperV, QEMU et macOS Hypervisor.framework, pour n'en nommer que quelques-uns; certains d'entre eux sont activement ciblés par des logiciels malveillants et, selon la version, peuvent être vulnérables à la propagation de logiciels malveillants sur la machine invitée.

  • N'installez certainement pas les ajouts d'invités ou les analogues d'une autre plate-forme. L'objectif littéral de ce type de logiciel est d'établir une intégration entre l'invité et l'hôte, en affaiblissant efficacement la séparation entre eux. Je ne suis pas un chercheur de malware, mais je serais surpris s'il n'y avait pas de malware ciblant spécifiquement ce type de surface.

Pour traiter directement certains de vos points:

Dans quelle mesure une machine virtuelle peut-elle être isolée de l'hôte?

À ce stade, une machine virtuelle peut être assez complètement isolée, mais certaines fonctions doivent encore passer par l'hôte plus ou moins directement, avec peu de protection contre l'hyperviseur. Dès le départ, la plupart des machines virtuelles non KVM (comme VirtualBox) ne partageront pas de noyau avec le système d'exploitation hôte. À lui seul, cela sert de bloqueur contre de nombreuses classes d'exploit, bloquant notamment la possibilité d'exécuter des appels système arbitraires contre votre noyau hôte (avec l'astérisque notable qu'une implémentation de la couche VM cassée peut permettre aux logiciels malveillants de contourner cela de manière moins évidente).

Cependant, votre machine virtuelle dispose toujours d'un espace de processus dans le matériel de votre machine hôte - et bien que cela ne soit généralement pas un risque car les systèmes d'exploitation modernes fournissent une isolation de l'espace de processus décent, il peut toujours être utilisé pour exploiter des attaques de très bas niveau comme un marteau , où un processus écrit séquentiellement dans la mémoire d'une manière spécifique jusqu'à ce qu'il puisse lire les blocs de mémoire adjacents qui ne lui appartiennent pas - permettant effectivement une fuite de mémoire entre les processus.

Il convient également de noter que l'isolement a tendance à disparaître quelque peu lorsque vous souhaitez effectuer essentiellement tout type d'E / S: l'entrée et la sortie signifient nécessairement un passage, ce qui expose une surface d'attaque qui peut être exploitée pour effectuer des actions d'hôte. Cela inclut le passage HID comme une souris et un clavier, ainsi que des choses comme le passage réseau - bien que cela dépend généralement de la façon dont le passage d'E / S est implémenté dans votre machine virtuelle.

Dois-je (ou puis-je?) Mettre en place un pare-feu entre l'invité et l'hôte?

Cela dépend, mais ce n'est généralement pas une mauvaise idée . La plupart des principales plates-formes prennent en charge les pare-feu de niveau hyperviseur. Ceux-ci sont tout au plus aussi permissifs que le pare-feu sur votre machine hôte, qui est à son tour tout aussi permissif que le pare-feu sur votre LAN ou VLAN. Si vous souhaitez tirer parti de cela au lieu de couper complètement l'accès au réseau en déconnectant les interfaces réseau virtuelles, je vous recommande de faire une recherche sur les ports et les hôtes de vos cibles de logiciels malveillants sélectionnés et de partir de là.

Les modules complémentaires invités constituent-ils un risque pour la sécurité?

Oui . Ils permettent toutes sortes d'intégrations entre votre machine hôte et votre machine invitée, et ne comportent pas toujours de spécifications ouvertes où vous pouvez voir ce qui est ouvert; voir au dessus.

Qu'en est-il des répertoires partagés?

Cela dépend de la façon dont vous le faites, mais c'est souvent une mauvaise idée . De nombreux hyperviseurs le font en créant un lecteur virtuel monté sur la machine invitée dont la racine se trouve dans ce répertoire. En fonction de la mise en œuvre de ce mécanisme, qui peut varier légèrement entre les frameworks, vous pouvez être en sécurité ou non, selon le malware que vous essayez de tester.


Ma préoccupation est que vous avez effectué très peu de recherches à ce sujet et que vous pourriez finir par endommager votre machine ou vos données. Avant de continuer, je vous conseille de vous pencher sur les différents mécanismes d'isolement sur les systèmes d'exploitation courants (KVM, comment ils s'intègrent avec les cadres de virtualisation de plus haut niveau ( ), les conteneurs ( ) et le chrootmécanisme ( ) pour nommer quelques-uns), lorsque chacun est approprié, et ce qu'ils peuvent et ne peuvent pas faire. À ce stade, vous pourrez mieux juger si vous pouvez jouer en toute sécurité avec des logiciels malveillants dans un environnement correctement isolé.

Enfin, vous ne devriez pas essayer de travailler avec des logiciels malveillants nouveaux ou peu connus (sauf si vous êtes un chercheur chevronné en sécurité, mais cette réponse ne s'adresse pas aux chercheurs chevronnés en sécurité). Les acteurs malveillants sont extrêmement créatifs en ce qui concerne ce qu'ils exploitent et comment ils l'exploitent. Pour vous en faire une idée, jetez un œil à toutes les discussions récentes de DEFCON qui ne sont pas centrées sur l'ingénierie sociale ou l'accès physique par des moyens mécaniques.

0xdd
la source
3
Je ne pense pas qu'il y ait beaucoup de différence en termes d'isolation, en principe, entre KVM et VirtualBox / VMWare / ... car tous nécessitent un support de module de noyau et utilisent la virtualisation assistée par matériel. Peut-être que vous vouliez dire des conteneurs / dockers? Cela dit, les exploits de qemu purement purs ne se produiraient que dans l'espace utilisateur, mais de nos jours, il est probablement beaucoup moins minutieux que kvm (voir aussi exploit de lecteur de disquette), mais ni kvm ni qemu n'autorisent les appels sys directs dans le noyau mais les deux permettent indirect (via la virtualisation ou la para-virtualisation) .
Maciej Piechotka
@MaciejPiechotka mon erreur, qui a été mal formulée. J'ai mis à jour la réponse, mais merci d'avoir soulevé cette question!
0xdd