1996967

Virtuelle PCs im Viren-Check: So sicher sind sie wirklich

15.03.2015 | 09:17 Uhr |

Abgeschottete virtuelle Maschinen gelten als perfekt, um gefahrlos unbekannte Software auszuprobieren. Doch wie wahr ist das?

Immer ein sauberes System, egal, was man damit anstellt – das ist eines der Versprechen von Virtualisierung auf dem Desktop. Denn Ihr Host-System, also das primäre System für die tägliche Arbeit, bleibt bei Havarien und Infektionen in der virtuellen Maschine im Idealfall völlig unangetastet. Dies lädt dazu ein, riskante Aktionen, etwa das Ausführen verdächtiger Programme und Besuche auf potenziell bösartigen Webseiten, in einem virtuellen System auszuführen. Damit eine virtuelle Maschine für diesen Zweck wirklich eine sichere Quarantänestation mit Reset-Möglichkeit ist, braucht ihre Einrichtung und Pflege etwas mehr Aufmerksamkeit. Virtualisierungsumgebungen wie Vmware Workstation / Player , Virtualbox und Microsoft Hyper-V sind nicht speziell als abgeschottete Systeme entworfen, sondern sollen sich möglichst komfortabel in eine bestehende Arbeitsumgebung und in ein Netzwerk einfügen. Ein unkontrollierter Datenaustausch mit dem lokalen Netzwerk und eine unbemerkte Infektion, die eine VM zum Bot-Netz-Zombie oder zur Virenschleuder im lokalen Netzwerk macht, ist ein Gefahrenpotenzial, das es zu bändigen gilt. Der Beitrag zeigt ganz praktisch die Einrichtung von abgeschotteten VMs und Sicherungspunkten und wirft zunächst einen Blick auf das typische Verhalten von Malware unter Virtualisierern.

Im Virenlabor Real statt virtuell

Virtualisierungsumgebungen spielen in professionellen Virenlaboren nur eine untergeordnete Rolle. Zwar lassen sich mithilfe virtueller Maschinen mit wenig Aufwand große Netzwerke simulieren, um etwa eine Verbreitungstaktik über Windows-Freigaben oder laufende Server-Dienste zu beobachten. Zur Analyse von Malware und deren Schadcode sind aber reale Computer gefragt, denn bei jeder unbekannten Malware-Klasse muss man heute davon ausgehen, dass sie Gastsysteme erkennt und genau weiß, ob sie innerhalb einer virtuellen Maschine läuft.

Andreas Marx, Geschäftsführer der renommierten AV-Test GmbH, geht davon aus, dass rund 25 Prozent aller neuen Schadprogramme Virtualisierungsumgebungen identifizieren können. Für eine Analyse im professionellen Rahmen ist diese Rate zu hoch, um für aussagekräftige Ergebnisse virtuelle Systeme einzusetzen. „Nur echte Hardware ist im Einsatz, keine VMs“, so Marx. Das Virenlabor setzt deshalb bei der dynamischen Analyse, also beim tatsächlichen Ausführen einer Malware und bei der Beobachtung des Schadverhaltens nur tatsächliche, physikalische Systeme ein.

Allerdings können VMs dabei helfen, verdächtiges Verhalten von potenziellen Schädlingen einzugrenzen: Verhält sich ein Programm in einer VM anders als in einem physikalisch installierten Wirtssystem, so gehen die Virenforscher bereits davon aus, dass mit einem Probanden etwas nicht stimmt und es sich potenziell um Malware handelt. Ist diese Eigenschaft einmal nachgewiesen, dann kommen Virtualisierungsumgebungen lediglich zum Einsatz, um zu testen, welche Virtualisierer eine Schad-Software erkennt und welche schädlichen Eigenschaften („Payload“) dann inaktiv bleiben. Das Gleiche gilt auch für unsere Virenscannertests von AV-Test: Nur reale Hardware ist im Einsatz, da sonst eine Beurteilung von Virenscannern nicht eindeutig ausfällt, falls Malware-Samples aus Testreihen ihre Aktivität gezielt zurückfahren oder völlig inaktiv bleiben.

Horrorszenario: Ausbruch aus der virtuellen Maschine

Können Schadprogramme aus dem Gastsystem heraus das Host-System befallen? Diese Frage stellt sich beim Einsatz von virtuellen Maschinen als Testplattform für verdächtige Programme immer wieder. Für die Macher hinter einer Malware wäre es der Jackpot, die Grenze zwischen virtuellem und physischem System zu überwinden.
Die Entwarnung gleich vorweg: Dieser Fall ist extrem unwahrscheinlich, wenn immer die aktuelle Version des verwendeten Virtualisierers zum Einsatz kommt. Wie jedes andere Programm auch, wird eine Virtualisierungs-Software unter dem Betriebssystem installiert und hat damit allein durch die Prozessorarchitektur keine Chance auf einen direkten Hardware-Zugriff. Alles muss über den Hypervisor geschehen. Zudem darf eine virtuelle Maschine keine privilegierten CPU-Befehle und Speicherzugriffe ausführen, da sie nicht im Kernel-Mode läuft. Dies ist ein Merkmal von x86-Prozessoren, und es gibt keinen Weg daran vorbei.

Malware eingefangen: Zum Glück wurde dieser vermeintliche Key-Generator nur in einer VM ausgeführt, denn es handelt sich um ein Trojanisches Pferd, das Windows-Systeme infizieren kann.
Vergrößern Malware eingefangen: Zum Glück wurde dieser vermeintliche Key-Generator nur in einer VM ausgeführt, denn es handelt sich um ein Trojanisches Pferd, das Windows-Systeme infizieren kann.

Was aber, wenn der Hypervisor selbst Sicherheitslücken hat? Also jene Komponente des Virtualisierers, die die Speicher- und CPU-Zugriffe der VM regelt und übersetzt. Dies gab es in der Vergangenheit tatsächlich, zumindest unter Laborbedingungen und mit bestimmten, anfälligen Versionen von Virtualisierungslösungen. Im Jahr 2005 veröffentlichte Vmware ein Sicherheits-Update für die Netzwerkkomponente „VMnat“, die über manipulierte Netzwerkpakete aus einer VM für Pufferüberläufe anfällig war. 2008 gab es eine weitere Lücke in Vmware-Produkten, diesmal in der virtuellen Grafikkarte und erstmals auch mit funktionierendem Beispielcode. Dem Exploit namens „Cloudburst“ der Sicherheitsexperten von Immunity gelang es, in den Videospeicher zu schreiben und Befehle auf dem Host-Betriebssystem auszuführen. 2012 zeigte sich der Para-virtualisierer Xen verwundbar. Eine Demonstration der Sicherheitsfirma Vupen zeigte unter Citrix Xenserver eine Möglichkeit, über manipuliertes Speicher-Mapping Root-Zugang auf dem Host zu bekommen. Alle diese Beispiele betrafen aber Bugs im Virtualisierer, die von den Software-Entwicklern schnell behoben wurden. Aktuell sind keine funktionierenden Exploits für irgendeine aktuelle Virtualisierungslösung bekannt. Allerdings müssen Nutzer darauf achten, dass der verwendete Virtualisierer immer auf dem neuesten Stand bleibt.

Bekannter Malware geht es nicht darum, aus einer VM auszubrechen, sondern sich zu verstecken oder gleich selbst zu löschen. In einigen Ausnahmefällen versuchen Schadprogramme auch, die VM zum Absturz zu bringen. Dies soll insbesondere die Arbeit von Virenlaboren erschweren und die Entdeckung einer Malware-Klasse verzögern.

Exkurs: So funktionieren virtuelle PCs im Detail

Versteckspiel: Malware mit VM-Erkennung

In den Anfangszeiten der Virtualisierungstechnik waren sogar Experten der Meinung, ein virtuelles System habe keine Möglichkeit, auf einem allgemein gültigen Weg herauszufinden, dass es in einer VM läuft. Diese Behauptung fand sich beispielsweise in der offiziellen Dokumentation von Intels Virtualisierungserweiterung für CPUs. Heute wissen wir natürlich, dass das ein Irrtum war. Ganz unabhängig vom verwendeten Hypervisor kann ein Programm in der VM die Existenz eines Hypervisors erkennen. Das erste bekannte Konzept, das sich in Anlehnung an den Film „Die Matrix“ „Red Pill“ nennt, überprüft die Struktur des Interrupt Descriptor Table (IDT) nach typischen Mustern, die auf einen Hypervisor hinweisen. Noch universeller sind Timing-Vergleiche, die den Zeitstempel von CPU-Befehlen analysieren. Wenn es zu bestimmten Verzögerungen kommt, die bei einer physikalischen CPU nicht auftreten, dann befindet sich das Programm höchstwahrscheinlich in einer VM.

Einfache Erkennung einer virtuellen Maschine über Geräte: Jede Virtualisierungsumgebung hat durch typische Gerätenamen ihren eigenen Fingerabdruck in einer virtuellen Maschine.
Vergrößern Einfache Erkennung einer virtuellen Maschine über Geräte: Jede Virtualisierungsumgebung hat durch typische Gerätenamen ihren eigenen Fingerabdruck in einer virtuellen Maschine.

Simpel gestrickte Malware geht aber gar nicht so weit, sondern sucht einfach nach typischen Namen virtueller Geräte oder nach Registry-Keys. Diese Art von Erkennung lässt sich mit einigem Aufwand sogar austricksen (siehe Kasten „Malwr“). Bekannte Malware-Klassen mit VM-Erkennung sind die Trojaner „Rebhip“ und der Conficker-Wurm. In Virtualisierungsumgebungen bleiben diese Schädlinge inaktiv, um einer Analyse zu entgehen. Dies ist ein Problem für Virenlabore. Für Anwender, die virtuelle Maschinen als abgeschottete Wegwerfsysteme betreiben, spielen diese Malware-Fähigkeiten allerdings keine Rolle.

Steckbrief Malwr Analyse mit Qemu im Web

Automatisierte Analyse von Malware in einer VM: Der kostenlose Webdienst Malwr (https://malwr.com) nutzt Cuckoo, eine angepasste Version von Qemu, als Sandbox.
Vergrößern Automatisierte Analyse von Malware in einer VM: Der kostenlose Webdienst Malwr (https://malwr.com) nutzt Cuckoo, eine angepasste Version von Qemu, als Sandbox.

Auch wenn virtuelle Umgebungen keine optimalen Laborbedingungen bieten, um Malware unter die Lupe zu nehmen, arbeiten Entwickler an Hypervisoren, die speziell auf die Analyse von Schadcode zugeschnitten sind. Denn bei der automatisierten Analyse versprechen Sandboxen, die unter einem Hypervisor laufen, eine hohe Effizienz. Ein vielversprechendes Open-Source-Projekt ist „Cuckoo“, das unter Linux eine Sandbox mithilfe von Qemu aufbaut. In dieser virtuellen Maschine zeichnet dann „Cuckoomon“ die Aktionen des verdächtigen Programms auf. Eine Installation von Cuckoo ist aber für eigene Experimente nicht erforderlich, denn der webbasierende Dienst Malwr nutzt diese Sandbox. Sie können eine Datei zum Untersuchen über ein Webformular hochladen. Die Präsentation der Ergebnisse kann einige Minuten dauern und erfolgt unter einer festgelegten URL.

Gefahrenquelle: Infizierte VMs

Auch wenn die Urheber der üblichen Schadprogramme auf unbedarfte Windows-Anwender abzielen, die keine virtuellen Gastsysteme betreiben, kommt mit zunehmender Virtualisierung eine andere Gefahrenquelle ins Spiel. Vernachlässigte und schlecht gewartete Systeme in VMs, die keine regelmäßigen Sicherheits-Updates bekommen, bedeuten ein oft unterschätztes Risiko. Besonders, wenn es sich um virtualisierte Server handelt, die eine Rolle im lokalen Netzwerk oder im Internet erfüllen. Diese Systeme brauchen die gleiche Pflege und zeitnahe Sicherheits-Updates wie physische Server. Das bedeutet auch, dass die erste Aktion bei virtuellen Maschinen, die auf einen früheren Zustand zurückgesetzt werden, ein umfassendes System-Update sein muss.

Quarantäne: Abgeschottete VMs erstellen

Virtuelle Maschinen zum Testen verdächtiger Programme, die keine Berührungspunkte zum Host-System und zum lokalen Netzwerk haben, lassen sich mit allen Virtualisierern erstellen. Es empfiehlt sich, virtuelle Maschinen zum Testen von verdächtigen Programmen grundsätzlich ohne Netzwerkverbindung zu starten. Nur wenn eine Verbindung benötigt wird und die virtuelle Maschine in einem vertrauenswürdigen Zustand ist, sollten Sie das Netzwerk manuell aktivieren.

Ohne Netzwerk starten: Da virtuelle Maschinen für Testzwecke erst mal keine Netzwerkverbindung haben sollen, können Sie das virtuelle Netzwerkkabel in Vmware Workstation/Player abziehen.
Vergrößern Ohne Netzwerk starten: Da virtuelle Maschinen für Testzwecke erst mal keine Netzwerkverbindung haben sollen, können Sie das virtuelle Netzwerkkabel in Vmware Workstation/Player abziehen.

Eine Funktion zum Erstellen von Momentaufnahmen, die eine VM mit wenigen Klicks auf einen früheren Zustand zurücksetzen, gibt es bei Vmware Workstation, Virtualbox und Microsoft Hyper-V. Generell empfehlen wir allerdings, zur Rückversicherung das Festplatten-Image einer virtuellen Maschine im sauberen Originalzustand als Sicherungskopie aufzuheben. Im Falle eines Versehens können Sie auf diese Weise immer zu einem garantiert vertrauenswürdigen Zustand zurückkehren und brauchen das Gastsystem nicht neu zu installieren. Dies funktioniert auch mit dem Vmware Player. Grundsätzlich muss die virtuelle Maschine vor einer Sicherungskopie ihres Festplatten-Images ausgeschaltet sein.

Vmware Workstation und Player: Das Netzwerk ist standardmäßig so konfiguriert, dass eine Internetverbindung und ein Zugriff auf das lokale Netzwerk mittels NAT (Network Address Translation) möglich sind. Die Aufgabe als NAT-Router übernimmt hierbei die virtuelle Netzwerkschnittstelle von Vmware. Um zu verhindern, dass ein Netzwerk ab dem Start der VM aktiv ist, gehen Sie nach einem Rechtsklick auf den Namen der VM in der Liste verfügbarer Maschinen auf „Settings > Hardware > Network Adapter“ und entfernen das Häkchen vor „Connect at power on“. Sie sehen dann nach dem Start der VM, dass das Netzwerksymbol am Rand des VM-Fensters ausgegraut ist. Im Player müssen die Symbole erst noch mithilfe eines Klicks auf „<<“ eingeblendet werden. Ein Klick auf das Netzwerksymbol – und Sie können das Netzwerk später gezielt ganz nach Bedarf mit „Connect“ und „Disconnect“ ein- und ausschalten.

Snapshots als Sicherungspunkte lassen sich in der Workstation bei laufender oder ausgeschalteter VM über deren Kontextmenü mit dem gleichnamigen Punkt „Snapshot“ erstellen. Im gleichen Menü können Sie später mit „Revert to Snapshot“ zu einem Sicherungspunkt zurückkehren und alle zwischenzeitlichen Änderungen an der VM verwerfen.

Im Vmware Player fehlt die Snapshot-Funktion. Bei Bedarf können Sie jedoch das Festplatten-Image des PCs sichern und den vorherigen Zustand durch Zurückkopieren wiederherstellen. Das Unterverzeichnis mit den Dateien einer virtuellen Maschine findet sich bei Vmware standardmäßig im Ordner „C:\Users\[Benutzername]\Documents\Virtual Machines\“.

Virtualisierungs-Tools für Windows im Überblick

Virtualbox: Auch Virtualbox stattet neu erstellte VMs zunächst mit einer IP-Adresse aus einem eigenen Subnetz aus und vermittelt den Netzwerkverkehr über einen virtuellen NAT-Router in das lokale Netzwerk und ins Internet weiter. Da dies für Testzwecke nicht erwünscht ist, lassen Sie die VM erst ohne Netzwerkverbindung starten. Diese Einstellungen nehmen Sie für eine virtuelle Maschine über „Ändern > Netzwerk > Erweitert“ vor, indem Sie die Option „Kabel verbunden“ abschalten. Wenn die VM läuft, können Sie mithilfe eines Rechtsklicks auf das Netzwerksymbol unten rechts mit „Netzwerkadapter verbinden“ das virtuelle Kabel anstecken.

Lediglich bei Bedarf ins Netz: Sowohl Vmware als auch Virtualbox erlauben die Verbindung des virtuellen Netzwerkadapters mittels Klick. Hier das Netzwerksymbol im Vmware Player.
Vergrößern Lediglich bei Bedarf ins Netz: Sowohl Vmware als auch Virtualbox erlauben die Verbindung des virtuellen Netzwerkadapters mittels Klick. Hier das Netzwerksymbol im Vmware Player.

Sicherungspunkte erstellen Sie in Virtualbox über „Maschine > Sicherungspunkt erstellen“, was vergleichsweise lange dauert. Um dann später zu diesem Punkt zurückzukehren, schalten Sie die VM aus und gehen oben rechts im Programmfenster auf „Sicherungspunkte (1)“, wählen den Punkt aus und klicken als Nächstes auf das Symbol „Sicherungspunkt wieder herstellen“. Die virtuellen Festplatten von VMs sind bei Virtualbox per Standard im Ordner „C:\Users\[Benutzername]\VirtualBox VMs“ in ihren jeweiligen Unterordnern zu finden, die den Namen des Gastsystems haben.

Sicherungspunkte in Virtualbox erstellen: Aus dem laufenden System heraus sichert der Virtualisierer per Klick ein Abbild, das den Zustand des Gastsystems sichert.
Vergrößern Sicherungspunkte in Virtualbox erstellen: Aus dem laufenden System heraus sichert der Virtualisierer per Klick ein Abbild, das den Zustand des Gastsystems sichert.

Microsoft Hyper-V: Hier haben Gastsysteme erst einmal gar keinen Netzwerkzugriff. Da ist also zunächst nichts zu tun. Wenn Sie ein Netzwerk im Gastsystem nutzen möchten, müssen Sie zuerst einen virtuellen Switch erstellen. Klicken Sie hierzu ganz rechts in der Menüliste auf „Manager für virtuelle Switches“. Wählen Sie „Externes Netzwerk“, wenn Sie die Verbindung zum Internet und zum lokalen Netzwerk über die Netzwerkschnittstelle des Host-PCs erlauben wollen. „Internes Netzwerk“ ermöglicht die Kommunikation von virtuellen Computern untereinander und mit dem Host-PC. „Privates Netzwerk“ bietet lediglich eine Netzwerkverbindung zwischen einzelnen virtuellen Maschinen. Klicken Sie jetzt auf „Virtuellen Switch erstellen“. Tragen Sie einen Namen ein, beispielsweise „Virtueller Switch 1“. Die virtuelle Maschine starten Sie ohne verbundenes Netzwerk. Während die Maschine läuft, können Sie das Netzwerk dann bei Bedarf über „Datei > Einstellungen > Netzwerkkarte > Virtueller Switch“ zuschalten.

Momentaufnahmen vor Änderungen am Gastsystem oder riskanten Aktionen erstellen Sie in Hyper-V über den Menüpunkt „Aktion > Snapshots“. Sie können der Momentaufnahme anschließend einen aussagekräftigen Namen geben, mit dem sie danach in der Liste der Snapshots auftaucht. Um später zum Zustand eines Snapshots zurückzukehren, klicken Sie den Snapshot rechts an und wählen „Anwenden“. Die Festplatten-Images von VMs für Sicherheitskopien finden Sie im Verzeichnis „C:\Users\Documents\Hyper-V\Virtual Hard Disks“.

Gründlicher Check: Live-System ist Pflicht

Zum Handwerkszeug für virtuelle Systeme, die auch Malware ausführen sollen, gehören natürlich ebenfalls die üblichen Virenscanner und Wächter. Virenwächter sind Systembremsen und können die Performance eines ansonsten rund laufenden Windows-Systems gehörig reduzieren. Einer virtuellen Maschine ist dies allerdings völlig egal, da sie ja kein produktiv eingesetztes System ist. Wir empfehlen Ihnen hier Avira Free Antivirus . Es ist zudem möglich, mehrere Virenscanner mit Wächterfunktion zu installieren, um gleich eine zweite Meinung einzuholen.

Bitdefender Live-System: Sie können den Virenscanner von Bitdefender in einem eigenständigen Live-System starten und eine VM gründlich prüfen.
Vergrößern Bitdefender Live-System: Sie können den Virenscanner von Bitdefender in einem eigenständigen Live-System starten und eine VM gründlich prüfen.

Wie bei einem physischen Rechner reicht es auch in einer möglicherweise infizierten, virtuellen Maschine nicht aus, einfach einen Virenscanner im laufenden System anzuwerfen. Denn fortgeschrittene Rootkits werden oft nicht erkannt, da sich diese über manipulierte Prozesslisten tarnen können. Einem genauen Check unterziehen Sie die VM mit bootfähigen Live-Systemen, die in der virtuellen Maschine anstatt des installierten Gastsystems gestartet werden. Es gibt zwei empfehlenswerte startfähige, bewährte Live-Systeme mit Virenscanner. Die Kaspersky Rescue Disk 10 sowie die Bitdefender Rescue CD starten im Gastsystem und überprüfen die Dateien auf den virtuellen Festplatten. Beachten Sie bitte, dass Sie für diese Live-Systeme wieder eine Internetverbindung in der VM brauchen, da nach dem Start zuerst eine Aktualisierung der Virendefinitionsdateien erforderlich ist.

Überblick Tools für Virtualisierung

Programm

Beschreibung

Internet

Sprache

Avira Free Antivirus 14.0.4

Virenscanner und Wächter

www.pcwelt.de/303785

Deutsch

Bitdefender Rescue CD

Live-System mit Virenscanner

http://download.bitdefender.com/rescue_cd/

Deutsch

Kaspersky Rescue Disk 10

Live-System mit Virenscanner

http://support.kaspersky.com/4162

Deutsch

Virtualbox 4.3.14

Komplette Virtualisierungsumgebung

www.pcwelt.de/305969

Englisch/Deutsch

Vmware Workstation 10.0.3

Komplette Virtualisierungsumgebung*

www.pcwelt.de/306905

Englisch

Vmware Player 6.0.3

Eingeschränkte Virtualisierungsumgebung

www.pcwelt.de/303939

Englisch

0 Kommentare zu diesem Artikel
1996967