it-swarm-eu.dev

Wie sicher sind virtuelle Maschinen wirklich? Falsches Sicherheitsgefühl?

Ich habe dieses CompTIA Security + SYO-201-Buch gelesen, und der Autor David Prowse behauptet, dass:

Unabhängig davon, welche VM Sie auswählen), kann die VM die festgelegten Softwaregrenzen nicht überschreiten. Beispielsweise kann ein Virus einen Computer infizieren, wenn er ausgeführt und auf andere Dateien übertragen wird im Betriebssystem. Ein Virus, der in einem VM] ausgeführt wird, verbreitet sich jedoch über das VM, wirkt sich jedoch nicht auf das zugrunde liegende tatsächliche Betriebssystem aus.

Wenn ich also VMWare Player ausführe und Malware auf dem Betriebssystem meiner virtuellen Maschine ausführe, muss ich mir keine Sorgen machen, dass mein Host-System kompromittiert wird, und zwar alle ?

Was passiert, wenn die virtuelle Maschine das Netzwerk mit der Host-Maschine teilt und freigegebene Ordner aktiviert sind?

Ist es nicht immer noch möglich, dass sich ein Wurm auf diese Weise auf den Host-Computer kopiert? Ist der Benutzer nicht immer noch anfällig für AutoRun, wenn das Betriebssystem Windows ist und er ein USB-Speichergerät einsteckt?

Wie sicher sind virtuelle Maschinen wirklich? Wie sehr schützen sie den Host-Computer vor Malware und Angriffen?

163
T. Webster

VMs können definitiv überqueren. Normalerweise haben Sie sie vernetzt, sodass sich jede Malware mit einer Netzwerkkomponente (d. H. Würmer) dort ausbreitet, wo ihre Adressierung/Weiterleitung dies zulässt. Normale Viren arbeiten normalerweise nur im Usermode. Obwohl sie nicht offen kommunizieren konnten, konnten sie dennoch einen verdeckten Kanal einrichten. Wenn Sie CPUs gemeinsam nutzen, kann ein ausgelasteter Prozess auf einem VM kann den Status effektiv mit einem anderen kommunizieren VM (das ist Ihr prototypischer verdeckter Timing-Kanal). Verdeckter Speicherkanal würde dies tun Seien Sie etwas schwieriger, da die virtuellen Festplatten in der Regel eine feste Grenze haben. Wenn Sie also kein System haben, das übermäßig viel Speicherplatz beanspruchen kann, sollte dies kein Problem sein.

Der interessanteste Ansatz zum Sichern von VMs heißt Separation Kernel . Es ist ein Ergebnis von John Rushbys Papier von 1981 , das im Wesentlichen besagt, dass der Computer seine Ressourcen auf eine Weise exportieren muss, die der physischen Trennung entspricht, damit VMs auf eine Weise isoliert werden können, die einer physischen Trennung entspricht Es macht keinen Sinn, dass eine Ressource, die den Status speichern kann, von VMs gemeinsam genutzt wird. Dies hat tiefgreifende Konsequenzen, da die zugrunde liegende Computerarchitektur so entworfen werden muss, dass dies auf nicht umgehbare Weise durchgeführt werden kann.

30 Jahre nach diesem Papier haben wir endlich einige Produkte, die behaupten, dies zu tun. x86 ist nicht die beste Plattform dafür, da es viele Anweisungen gibt, die nicht virtualisiert werden können, um die Idee des "No Sharing" vollständig zu unterstützen. Es ist auch für gängige Systeme nicht sehr praktisch, da für vier VMs vier Festplatten erforderlich sind, die an vier Festplattencontrollern, vier Grafikkarten, vier USB-Controllern mit vier Mäusen usw. hängen.

91
Marcin

Im Laufe der Jahre wurden einige Whitepaper veröffentlicht, in denen beschrieben wurde, wie es Forschern gelungen ist, ein Host-Betriebssystem von einer VM aus zu befallen. Diese werden normalerweise zu Recht als Sicherheitslücken von den VM - Anbietern angesehen und als solche behandelt. Seit ich diese Dokumente zum ersten Mal gesehen habe, hat Intel einige signifikante Verbesserungen des Prozessoranweisungssatzes vorgenommen, um die Trennung von zu ermöglichen VM und Hypervisor.

Die wenigen Sicherheitslücken, die ich heutzutage sehe, basieren eher auf dem Abschnitt 'vmtools'. Dies ist die Software, die Sie installieren, damit das Gastbetriebssystem effizienter ausgeführt wird (für VMWare ermöglicht dies die sofortige Erfassung des Cursors und die gemeinsame Nutzung zwischen Gast und Host ohne Netzwerk). Dies ist ein spezieller Softwarepfad für Infektionen. Installieren Sie die Tools nicht, haben Sie nicht die Sicherheitslücke.

Einige Malware hat die Fähigkeit gezeigt, zu erkennen, dass sie in einer VM] ausgeführt werden, und damit ihr Verhalten zu ändern, sehr zur Erschwerung von Malware-Forschern, die versuchen, VMs zu verwenden Ich weiß jedoch nicht, wie weit verbreitet diese Malware ist.

63
sysadmin1138

Ein Beispiel für die Ausführung von Gast-zu-Host-Code finden Sie im Cloudburst-Exploit. Es gibt ein Video demonstriert es und ein Papier von Immunity detailliert ihren Erfolg auf VMware Workstation 6.5.0 build118166 unter Windows Vista SP1, VMware Workstation 6.5.1 build126130 unter Windows Vista SP1 und (noch beängstigender) VMware ESX Server 4.0.0 build133495.

Dies bietet wahrscheinlich wenig Komfort, aber ich habe noch nie davon gehört, dass dies in freier Wildbahn verwendet wird, und der Exploit stammt aus dem Jahr 2009. Dieses Buch wurde 2010 veröffentlicht, daher sollte der Autor diese Aussage bereinigen.

24
harley

Eine virtuelle Maschine ist genau das, eine logisch getrennte Maschine, daher müssen dieselben Sicherheitsebenen darauf platziert sein wie bei einem Bare-Metal-System. Die Verwendung einer virtuellen Maschine stoppt einen Vul nicht, wenn normale Kanäle verwendet werden, um zur Host-Maschine zu gelangen.

Das Schöne an der Virtualisierung ist die Möglichkeit, VMs in einen Zustand zurückzusetzen, in dem sie nicht betroffen waren, sowie die Möglichkeit, verfügbare Ressourcen besser zu verwalten.

Wenn die richtigen Schritte zum Schutz des Host-Computers unternommen werden, kann die Virtualisierung äußerst sicher sein. Praktiken wie die Verwaltung des ESX/VM-Servers in einem anderen logischen Netzwerk und die Nichtverwendung von VM-Host-Schnittstellentools lassen Angreifer die Tatsache, dass eine Maschine virtuell ist, weitgehend außer Acht, geschweige denn, wie sie zum Host gelangen.

Es sind auch Exploits bekannt, die sich auf VM Hosts (ich habe mit ihnen in VMWare und Hyper-V gespielt) auswirken. Derzeit sind mir nur Host-DoS-Exploits bekannt, wenn es um Hyper- geht. v (siehe this ), aber ich bin sicher, es gibt noch andere Funde am Horizont. VMWare hat auch einige in seiner Geschichte (dh this , es basiert auf VMWare-Tools, aber es gilt immer noch).

Je nachdem, was Sie tun, gibt es einige Online-Tools, mit denen Sie möglicherweise die Analyse auf Ihrem eigenen Computer durchführen müssen. Hier sind einige Websites, die Sie sich ansehen sollten:
- Threatexpert.com
- anubis.iseclab.org
- virustotal.com

19
Ormis

Mit dem Security + -Material ist gemeint, dass Malware bisher nicht aus der Sandbox der VM entkommen konnte, indem sie die Tatsache ausnutzte, dass es sich um eine VM) handelt und irgendwie den Hypervisor treffen. Andere Mechanismen, wie die Ausbreitung über ein gemeinsam genutztes Netzwerk, sind die gleichen, als wären dies verschiedene physische Boxen.

7
K. Brian Kelley

Sie sind nicht perfekt sicher, wie dieser Exploit zeigt:

VENOM, CVE-2015-3456, ist eine Sicherheitslücke, die sich auf einige gängige Computervirtualisierungsplattformen auswirkt, insbesondere Xen, KVM, VirtualBox und den nativen QEMU-Client.

Diese Sicherheitsanfälligkeit kann es einem Angreifer ermöglichen, sich aus den Grenzen eines betroffenen Gastes einer virtuellen Maschine (VM) zu befreien und möglicherweise Code-Ausführungszugriff auf den Host zu erhalten. Weitere Details zur Sicherheitsanfälligkeit finden Sie hier.

5

Ich denke, dass die Behauptung des Autors nicht vollständig wahr ist. Tatsächlich gibt es im Virtualisierungsbereich zwei Arten von Hypervisor. Hypervisor ist eine Computersoftware, Firmware oder Hardware, die erstellt ​​und ausgeführt ​​ virtuelle Maschine s. Diese Typen sind:

  • Typ-1-Hypervisoren
  • Typ-2-Hypervisoren

Der Hypervisor Typ 1 wird direkt ​​auf der Hardware des Hosts ausgeführt, um die Hardware zu steuern und Gastbetriebssysteme zu verwalten. Aus diesem Grund werden sie manchmal als Bare Metal Hypervisoren , während Typ-2-Hypervisor auf einem konventionellen] ausgeführt Betriebssystem genau wie andere Computerprogramme. VMWare oder VirtualBox sind Beispiele für Typ-2-Hypervisor, da sie als Programme in Host [~ # ~] os [~ # ~] s.

Für Typ-2-Hypervisoren gibt es das Projekt RoboLinux mit einer einzigartigen Funktion namens Stealth VM. Stealth VM Software-Installationsprogramm , mit dem Sie einen Windows 7-Klon erstellen können, der in einer sicheren Linux-Partition ausgeführt wird. Das System ist vor Malware geschützt, alles, was Sie herunterladen, ist in in der virtuellen Maschine enthalten und richtet sich an Personen, die über ein bestimmtes Windows-Programm verfügen müssen, um das Betriebssystem wie neu in wiederherstellen zu können nur zwei Klicks.

Es gibt Qubes OS, das unter Linux und Xen als Beispiel für entwickelt wurde Typ-1-Hypervisoren. Qubes OS verfolgt einen Ansatz namens Sicherheit durch Isolation, was in diesem Zusammenhang bedeutet, dass die Dinge, die Sie auf Ihrem Computer tun, in verschiedenen VMs sicher isoliert bleiben, sodass eine VM wirkt sich nicht auf die anderen aus. Im Gegensatz zu Typ-2-Hypervisoren verfügt es über ein sicheres Inter-VM-Dateiübertragungssystem, um das Risiko der Freigabe von Ordnern zu bewältigen. Theoretisch ist dies die Organisation Laut Entwicklern sicherer als Typ-2-Virtualisierung.

Kurz gesagt, der Autor sollte welcher Hypervisor oder virtuelles System angeben.

Referenzen:

4
JackSparrow

Von Interesse und Relevanz ist der Sicherheitswettbewerb "Pwn2Own" für 2016 einer seiner Wettbewerbe, der einer virtuellen VMWare Workstation-Maschine entgeht. (Andere beinhalten das Entkommen von Browser-Sandboxen oder die Übernahme physischer Maschinen). Das sollte eine Idee geben, dass 1) es zumindest plausibel ist und 2) wenn es einfach ist, dann haben wir eine Möglichkeit, es zu hören - überprüfen Sie einfach das Ergebnis :)

Allgemeiner könnte VM Sicherheit theoretisch auf viele Arten entgangen werden. Beispielsweise -

  • Guest-to-Host-Befehle und APIs (z. B. VMware-Tools)

  • Ausnutzbare Schwachstellen im Host-Betriebssystem selbst, die nicht durch Ausführen in einem VM -Prozess behoben werden (wenn einige Gastbetriebssystemaufrufe fälschlicherweise als "sicher" eingestuft und von einem Gasttreiber direkt an das Host-Betriebssystem oder den Gerätetreiber für weitergeleitet werden Geschwindigkeit, aber ein Exploit existiert)

  • Fehler in Hersteller-Treibern oder Hersteller-Code (z. B. ermöglicht ein Host-Treiber die Netzwerküberbrückung für das Gastbetriebssystem; möglicherweise können durch einen Fehler darin Anrufe oder Code auf dem Host auf Kernel-Ebene getätigt werden).

  • Sicherheitslücken aufgrund anderer Software auf dem Host (erfundenes Beispiel - wenn lokales Antivirenprogramm den gesamten Netzwerkverkehr vom Host zum Scannen abfängt und der Gastverkehr als Teil davon gescannt wird (anstatt aufgrund des virtuellen NIC ignoriert zu werden) Gerät), dann könnte eine Anfälligkeit der A/V-Engine für böswillig gestalteten Datenverkehr oder Paket dazu führen, dass der vom VM stammende Datenverkehr zum Host entweicht.

  • Fehlerhafte Konfiguration durch den Benutzer (Hostdateien zugeordnet oder nicht ausreichend sicher/getrennt, damit der Gast sie erreichen kann)

Der Umfang existiert und wird angesichts der Verbreitung sicherlich aktiv auf Exploits untersucht. Sicherlich werden Schwachstellen, wenn nicht Exploits, regelmäßig gefunden und müssen gepatcht werden.

4
Stilez