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

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.

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.

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.

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.

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.

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 „

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.

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.

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:UsersDocumentsHyper-VVirtual 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.

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.