Frage:
Wie sicher sind virtuelle Maschinen wirklich? Falsches Sicherheitsgefühl?
T. Webster
2011-04-13 04:48:32 UTC
view on stackexchange narkive permalink

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

Unabhängig von der ausgewählten VM kann die VM die Software nicht überqueren Grenzen gesetzt. Beispielsweise kann ein Virus einen Computer infizieren, wenn er ausgeführt und auf andere Dateien im Betriebssystem übertragen wird. Ein in einer VM ausgeführter Virus verbreitet sich jedoch über die 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, Ich muss mir keine Sorgen machen, dass mein Hostsystem überhaupt kompromittiert wird.

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

Kann sich ein Wurm nicht immer noch auf diese Weise auf den Host-Computer kopieren? 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?

Wenn ich der Herausgeber wäre, würde ich an einigen ausgewählten Stellen in diesem Zitat ein "hoffentlich" und "theoretisch" einfügen. Wie es ist, ist es definitiv eine falsche Aussage.
Ein Beispiel für einen realen Angriff von Gast-Betriebssystem zu Host-Betriebssystem. http://venom.crowdstrike.com
Eine sehr allgemeine Aussage ist, dass die Sicherheit des Hosts und des Netzwerks von der Sicherheit der Schnittstellen zwischen dem Host / Netzwerk und der Client-VM abhängt. Sie sollten in Betracht ziehen, das absolute Minimum an Tools zu installieren, den minimalen Netzwerkzugriff und das Minimum an Hardwaregeräten zu konfigurieren, um das Risiko zu minimieren. Wenn Sie nur eine VM in einer Speichersandbox ausführen, sind Sie wahrscheinlich sicher. Die einzigen Schnittstellen, die angegriffen werden könnten, wären die CPU und das Speichersubsystem des Visiers. Sie hätten auch eine ziemlich nutzlose VM. Z.B. Benötigen Sie eine [Diskette] (http://blog.crowdstrike.com/venom-vulnerability-details/)?
Neun antworten:
#1
+94
Marcin
2011-04-13 05:38:58 UTC
view on stackexchange narkive permalink

VMs können definitiv überkreuzen. Normalerweise haben Sie sie vernetzt, sodass sich Malware mit einer Netzwerkkomponente (d. H. Würmer) überall dort ausbreitet, wo ihre Adressierung / Weiterleitung dies zulässt. Normale Viren arbeiten normalerweise nur im Benutzermodus. Obwohl sie nicht offen kommunizieren konnten, konnten sie dennoch einen verdeckten Kanal einrichten. Wenn Sie CPUs gemeinsam nutzen, kann ein ausgelasteter Prozess auf einer VM den Status effektiv an eine andere VM kommunizieren (dies ist Ihr prototypischer verdeckter Timing-Kanal). Der verdeckte Speicherkanal wäre etwas schwieriger, da die virtuellen Festplatten in der Regel stark eingeschränkt sind. Wenn Sie also kein System haben, das übermäßig viel Speicherplatz beanspruchen kann, sollte dies kein Problem darstellen.

Die Der interessanteste Ansatz zum Sichern von VMs ist der Separation Kernel. Es ist ein Ergebnis von John Rushbys 1981er Papier, in dem es im Wesentlichen heißt, 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 gestaltet werden muss, dass dies auf nicht umgehbare Weise möglich ist.

30 Jahre nach diesem Dokument haben wir endlich nur wenige Produkte, die dies tun behaupten, es 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. Für gängige Systeme ist dies auch 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.

Update 2020: Alle aktuellen hardwarebasierten Schwachstellen (Meltdown, Spectre, Foreshadow, ZombieLoad, CacheOut, SPOILER usw.) sind ein gutes Beispiel dafür, wie VMs immer kommunizieren können, einfach weil sie Hardware gemeinsam nutzen (Caches, TLB, Verzweigungsvorhersage, TSX, SGX), die niemals für die Partitionierung und Isolierung vorgesehen oder vorbereitet waren.

Was wäre der Vorteil dieser Art von verdeckter Kommunikation für den Virenautor? Es hört sich so an, als könnte es nicht verwendet werden, bis beide Computer infiziert waren, aber warum sollten Sie es nach diesem Zeitpunkt brauchen?
@JackO'Connor: Um zwischen ihnen zu * kommunizieren *. Stellen Sie sich beispielsweise vor, ob auf einer der VMs eine Netzwerkkarte mit dem Internet verbunden ist, jedoch nicht mit dem internen Rechenzentrum, und auf der anderen eine Netzwerkkarte, die mit dem internen Rechenzentrum, jedoch nicht mit dem Internet verbunden ist. Über diesen verdeckten Kanal hat der Angreifer nun eine Möglichkeit, den DC aus dem Internet anzugreifen und Daten zu exfil. Darüber hinaus könnte eine VM mit dieser Methode möglicherweise eine andere VM über einen Seitenkanal angreifen, z. B. eine kompromittierte VM (unter Azure / EC2 möglicherweise), die eine andere VM angreift, um beispielsweise die privaten SSL-Schlüssel der anderen VM abzurufen.
Wenn eine VM den Maschinencode nicht direkt ausführt, sondern interpretiert, sollte es grundsätzlich schwierig sein, die Maschine 100% sicher zu machen, wenn die einzigen Möglichkeiten, wie sie mit der Außenwelt interagieren kann, von außen (z. B. von außen) initiiert werden Dienstprogramm, das Daten auf die "Festplatte" der virtuellen Maschine kopiert?)
"_Um vier VMs zu haben, müssten vier Festplatten an vier Festplattencontrollern hängen, vier [etc ...] _" Das klingt so, als würde der Sinn von * virtuellen * Maschinen fehlen.
@Marcin - Wenn die virtuellen Maschinen zu Testzwecken nicht vernetzt sind, jedoch freigegebene Ordner und Zwischenablagen zwischen Gast und Host aktiviert sind, wie hoch ist die Wahrscheinlichkeit einer Infektion vom Gast zum Host?
@Motivated, bei dem die gleiche Wahrscheinlichkeit einer Infektion eines Drive-by-Downloads oder eines E-Mail-Anhangs besteht: Die Malware in der VM kann Dateien in den freigegebenen Ordnern ablegen, aber ein Benutzer muss Maßnahmen ergreifen, damit er etwas unternimmt.
Es gibt kein "No Sharing" -System.Selbst wenn Sie für jede VM dedizierte Netzwerkkarten, Festplatten usw. haben, teilen Sie das Motherboard weiterhin.Und wenn Ihre VMs tatsächlich über eigene Motherboards verfügen, können Sie Ihre System-VM dann nicht mehr wirklich aufrufen.
Marcin, die Antwort ist 8 Jahre her.kannst du es aktualisieren?Das Thema ist sehr wichtig ... danke
#2
+66
sysadmin1138
2011-04-13 06:22:58 UTC
view on stackexchange narkive permalink

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 von den VM-Anbietern als Sicherheitslücken angesehen und als solche behandelt. Seit ich diese Artikel zum ersten Mal gesehen habe, hat Intel einige wesentliche Verbesserungen an den Prozessoranweisungen vorgenommen, um die Trennung von VM und Hypervisor zu ermöglichen.

Die wenigen Sicherheitslücken, die ich heutzutage sehe, basieren mehr 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 und weisen Sie keine Sicherheitsanfälligkeit auf.

Einige Malware-Programme können erkennen , dass sie in einer VM ausgeführt werden, und ändern daher ihr Verhalten , sehr zur Erschwerung von Malware-Forschern, die versuchen, VMs zum Testen von Malware zu verwenden. Ich weiß allerdings nicht, wie weit verbreitet es heutzutage ist.

Ich habe gehört, dass sie normalerweise die Malware im Debugger ausführen, einen Haltepunkt für den Zweig festlegen, der VM-spezifisches Verhalten verursacht, und das Ergebnis dieser Bedingung nach der Auswertung ändern. Aber es ist heutzutage weniger verbreitet, weil viele interessante Ziele virtualisiert werden.
"Dies ist ein spezieller Softwarepfad für Infektionen. Installieren Sie die Tools nicht und haben Sie keine Sicherheitslücke."Selbst wenn die Tools nicht installiert sind, kann der Angreifer sie einfach installieren.Um den Angriffsvektor ordnungsgemäß zu schließen, müssen Sie die APIs schließen, mit denen die Tools kommunizieren.
#3
+26
harley
2011-04-21 21:55:01 UTC
view on stackexchange narkive permalink

Ein Beispiel für die Ausführung von Gast-zu-Host-Code finden Sie im Cloudburst-Exploit. Es gibt ein Video , das es demonstriert, und ein Dokument von Immunity , in dem der Erfolg von VMware Workstation 6.5.0 build118166 unter Windows Vista SP1 und VMware Workstation 6.5.1 build126130 unter Windows beschrieben wird 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.

#4
+21
Ormis
2011-04-13 23:32:18 UTC
view on stackexchange narkive permalink

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.

Die wahre Schönheit der Virtualisierung besteht in der 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 das Beibehalten der ESX / VM-Serververwaltung in einem anderen logischen Netzwerk und das Nichtverwenden 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 auswirken (ich habe mit ihnen in VMWare und Hyper-V gespielt). Derzeit sind mir nur Host-DoS-Exploits bekannt, wenn es um Hyper-V geht (siehe dies), aber ich bin mir sicher, dass weitere Funde am Horizont stehen. VMWare hat auch einige in seiner Geschichte (dh dies, es basiert auf VMWare-Tools, aber es gilt immer noch).

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

P.S. Besuchen Sie malwaredomainlist.com, wenn Sie Ihre Sandbox-Umgebung testen möchten. Seien Sie jedoch gewarnt. Verwenden Sie diese Option nur, wenn Sie mit neuer, lustiger Malware infiziert werden möchten :-)
+1, aber die anerkannte Führungskraft auf diesem Gebiet, Joanna Rutkowska, finden Sie unter http://theinvisiblethings.blogspot.com/
Eine VM auf x86 ist KEINE exakte logisch separate Maschine. Lesen Sie http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements und http://www.usenix.org/events/sec2000/robin.html und Sie werden feststellen, dass es 17 Anweisungen gibt, die nicht virtualisiert werden können.
Logisch getrennt bedeutet nicht technisch getrennt. Auch wenn nicht alle Anweisungen virtualisiert werden können, ist die Anwendung der Maschine immer noch eine andere logische Einheit. Diejenigen, die sie bereitstellen, müssen diese Denkweise beibehalten und nehmen aufgrund der Abstraktion keine Sicherheit an. Denken Sie auch daran, die Grundlagen zu befolgen. Versuchen Sie für VMWare, ein anderes Host-Betriebssystem als das von Ihnen getestete Gast-Betriebssystem zu verwenden, überprüfen Sie die Isolationsoptionen und stellen Sie sicher, dass die Netzwerke ordnungsgemäß aufgebaut sind. Also, @Marcin, ich verstehe, was Sie sagen wollen, aber ich glaube, meine Kommentare sind immer noch gültig (einfach diese Virtualisierung! = Sicherheit).
#5
+7
K. Brian Kelley
2011-04-13 05:40:36 UTC
view on stackexchange narkive permalink

Mit dem Security + -Material ist gemeint, dass Malware bisher nicht in der Lage war, der Sandbox der VM zu entkommen, indem sie die Tatsache ausnutzte, dass es sich um eine VM handelt und irgendwie auf den Hypervisor traf. Andere Mechanismen, z. B. die Verteilung über ein gemeinsam genutztes Netzwerk, sind dieselben, als wären dies unterschiedliche physische Boxen.

Leider ist Ihre Antwort sachlich falsch. Ich bin nicht sicher, ob es 2011 bekannt war, aber es ist definitiv jetzt. http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.phpvia http://www.insinuator.net/2013/05/analysis-of-hypervisor-breakouts/
#6
+5
goodguys_activate
2015-06-06 04:31:13 UTC
view on stackexchange narkive permalink

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 der native QEMU-Client.

Diese Sicherheitsanfälligkeit kann es einem Angreifer ermöglichen, aus den Grenzen eines betroffenen VM-Gasts (Virtual Machine) zu entkommen und möglicherweise Code-Ausführungszugriff auf den Host zu erhalten. Weitere Details zur Sicherheitsanfälligkeit finden Sie hier.

Beachten Sie, dass CVE-2015-3456 durch die Verwendung der Option chroot von QEMU verringert wird, vorausgesetzt, es wird nicht als root ausgeführt.Diese Sicherheitsanfälligkeit beeinträchtigt lediglich das QEMU-Frontend des Userspace und nicht das Xen / KVM-Backend des Kernelspace.Ich glaube auch nicht, dass es VirtualBox betrifft, wie überhaupt.Es ist speziell eine Sicherheitslücke im fdc-Treiber von QEMU.VirtualBox teilt diesen Code nicht.Der einzige Grund, warum KVM und Xen davon betroffen sein sollen, ist, dass diese beiden nur selten alleine verwendet werden und stattdessen als Backends für QEMU fungieren.So etwas wie kvmtool anstelle von QEMU wäre trotz der Verwendung von KVM nicht betroffen.
#7
+4
JackSparrow
2015-09-11 16:37:48 UTC
view on stackexchange narkive permalink

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 virtuelle Maschinen ausführt. Diese Typen sind:

  • Typ-1-Hypervisoren
Typ-2-Hypervisoren

Typ-1-Hypervisor 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 bezeichnet, während Typ-2-Hypervisor auf einem herkömmlichen Betriebssystem ausgeführt wird genau wie andere Computerprogramme. VMWare oder VirtualBox sind Beispiele für Typ-2-Hypervisor, da sie als Programme in Host-Betriebssystemen ausgeführt werden.

Für Typ-2-Hypervisoren gibt es ein RoboLinux Projekt 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, befindet sich in der virtuellen Maschine und ist für Personen gedacht, die über ein bestimmtes Windows-Programm verfügen müssen, um das Betriebssystem als wiederherstellen zu können Neu in nur zwei Klicks.

Es gibt Qubes OS , das unter Linux und Xen as entwickelt wurde Ein Beispiel für Typ-1-Hypervisoren. Qubes OS verfolgt einen Ansatz namens Sicherheit durch Isolation . In diesem Zusammenhang bedeutet dies, dass die auf Ihrem Computer ausgeführten Aktionen in verschiedenen VMs sicher isoliert bleiben, sodass eine kompromittierte VM gewinnt. t beeinflussen die anderen. Im Gegensatz zu Typ-2-Hypervisoren verfügt es über ein sicheres Dateiübertragungssystem zwischen VMs , um das Risiko der Freigabe von Ordnern zu bewältigen. Theoretisch ist diese Organisation laut Entwicklern sicherer als die Typ-2-Virtualisierung.

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

Referenzen :

Sie meinen, Qubes ist sicherlich ein Beispiel für Typ-1-Hypervisoren?
Ja (ich hätte Schreibfehler haben sollen; jetzt habe ich den Beitrag bearbeitet), auch diese Informationen finden Sie auf ihrer Website."Im Gegensatz dazu verwendet Qubes einen" Typ 1 "- oder" Bare-Metal "-Hypervisor namens Xen. Anstatt in einem Betriebssystem ausgeführt zu werden, werden Typ-1-Hypervisoren direkt auf dem" Bare-Metal "-Hyper der Hardware ausgeführt. Dies bedeutet, dass ein Angreifer fähig sein mussden Hypervisor selbst zu untergraben, um das gesamte System zu gefährden, was weitaus schwieriger ist. "von https://www.qubes-os.org/tour/#what-is-qubes-os
#8
+4
Stilez
2016-03-25 02:47:58 UTC
view on stackexchange narkive permalink

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

Im Allgemeinen könnte die VM-Sicherheit theoretisch entgangen werden viele Möglichkeiten. Beispiel:

  • Gastbefehle und APIs (z. B. VMware-Tools)

  • Ausnutzbare Schwachstellen im Host-Betriebssystem Nicht durch Ausführen in einem VM-Prozess gemildert (wenn einige Gastbetriebssystemaufrufe fälschlicherweise als "sicher" eingestuft und von einem Gasttreiber aus Geschwindigkeitsgründen direkt an das Hostbetriebssystem oder den Gerätetreiber weitergeleitet werden, aber ein Exploit vorhanden ist)

  • 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 (im Gegensatz dazu) Wenn eine Anfälligkeit der A / V-Engine für einen böswillig gestalteten Datenverkehr oder ein Paket aufgrund eines virtuellen NIC-Geräts ignoriert wird, kann der von der VM stammende Datenverkehr möglicherweise auf den Host übertragen werden.

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

  • Der Gültigkeitsbereich ist vorhanden und wird aufgrund seiner Verbreitung sicherlich geprüft aktiv für Exploits. Sicherlich werden Schwachstellen, wenn nicht Exploits, regelmäßig gefunden und müssen gepatcht werden.

    #9
    -1
    ddyer
    2014-02-18 14:15:11 UTC
    view on stackexchange narkive permalink

    Exploits, die speziell für die Ausführung in VMs und Zielfehlern im zugrunde liegenden Host-Kernel entwickelt wurden, sind unvermeidlich. Suchen Sie zuerst in den beliebten Cloud-Plattformen nach ihnen.



    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...