Die Virtualisierung gehört heute zu den am häufigsten genutzten Techniken und kommt in fast allen Rechenzentren zum Einsatz. So tauchen auch spezielle Angriffstechniken auf, die sich den hohen Grad der Komplexität solcher Lösungen zunutze machen, um sie zu kompromittieren. Wir zeigen am Beispiel des Hyper-V, welche eingebauten Sicherheitsmechanismen zur Verfügung stehen und was noch zum Schutz der virtuellen Systeme getan werden kann.

Von Frank-Michael Schlede

Da die Virtualisierung zu den anerkannten und häufig genutzten Techniken gehört, die in fast allen Rechenzentren der Welt in der einen oder anderen Ausprägung zum Einsatz kommt, werden dieses Systeme auch immer häufiger gezielt angegriffen und müssen entsprechend geschützt werden. Dabei geht es in diesem Beitrag speziell um die verschiedenen Sicherheitsaspekte, die beim Einsatz des »Hyper-V« von Microsoft relevant sind.

Wahl der Hardware ist für die Sicherheit entscheidend

Die Hardware-Voraussetzungen für den Einsatz des Hyper-V bewegen sich in ziemlich engen Grenzen, was auch aus Sicherheitsgründen geschehen ist. Eine fast selbstverständliche Voraussetzung ist dabei die Hardware-basierte Virtualisierung, die von der CPU unterstützt werden muss. Zudem kann auf der sogenannten Parent-Partition grundsätzlich nur der Windows Server 2008 in der x64-Version oder gleich das R2-Release des Servers zum Einsatz kommen, das nur in einer 64-Bit-Version zur Verfügung steht. Nach Aussagen von Microsoft werden ausschließlich 64-Bit-Systeme zugelassen, weil diese ein erweitertes und besseres Management sowohl für den Hauptspeicher als auch für die Verwaltung der Prozesse aufweisen können.

Zudem bringt der Einsatz eines 64-Bit-Windows noch einen zusätzlichen Gewinn bei der Sicherheit: All diese 64-Bit-Versionen von Windows beinhalten keinen Legacy-Code mehr. Sie wurden von Grund auf neu entwickelt, wobei dabei die sogenannte Security Development Lifecycle-Methode (SDL) zum Einsatz kam. Nähere Information dazu stellt Microsoft auf seiner Webseite zur Verfügung.

Eine ganze Reihe von Sicherheitsvorrichtungen, die bei modernen Prozessoren standardmäßig zur Verfügung stehen, wird vom Hyper-V direkt eingesetzt. Sie sind deshalb ebenfalls Bedingung für den Einsatz der Virtualisierungs-Lösung. Dazu zählen die Data Execution Prevention (DEP) und die Adress Space Layout Randomization (ASLR). DEP ist eine Technik, die sogenannte Buffer Overruns verhindern kann. Bei solchen Überläufen von Pufferbereichenwird ausführbarer und in der Regel bösartiger Programmcode direkt in Datenpufferbereiche des Hauptspeichers geschrieben. Die Technik zur Verhinderung dieser Angriffe wird bei den AMD-Prozessoren als »No Execute« (NX) und bei den Pendants von Intel als »eXecute Disable« (XD) bezeichnet.

ASLR ist ein weiterer Schutzmechanismus, der besonders vor der sogenannter Malware schützen soll. Standardmäßig legt ein Betriebssystem systemkritische Dateien nach einem Neustart immer an der gleichen Speicheradresse oder aber an einer Adresse innerhalb eines bestimmten Bereichs ab, was es bösartigen Programmen erleichtert diese Bereiche zu kompromittieren. Die ASLR-Technik verändert zwischen den Neustarts des Systems per Zufall die Speicheradressen, an denen solche systemkritische Dateien zur Laufzeit im Hauptspeicher abgelegt werden. Auf diese Weise können zum Beispiel Programme wie Trojaner und Würmer, die immer wieder versuchen die gleichen Speicheradressen auf verschiedenen Systemen anzusprechen, relativ wirkungsvoll am Ausführen ihrer Schadroutinen gehindert werden.

Es sind also insgesamt drei wichtige Voraussetzungen, die eine Server-Hardware erfüllen muss, damit der Hyper-V direkt oder indirekt von den daraus entstehenden Sicherheitsvorteilen profitieren kann: Hardware-basierte Virtualisierung, Hardware-basiertes DEP und ASLR, sowie natürlich die 64-Bit-Unterstützung. Wer direkt feststellen will, ob seine Hardware diese Features auch sicher zur Verfügung stellt, kann dazu das freie Tool Securable verwenden.

Aber auch die CPU-Hersteller bieten entsprechende Werkzeuge an: Intel stellt ein Erkennungsprogramm für seine Prozessoren zur Verfügung und auch wer die CPUs von AMD verwendet, kann auf die eigene Software des Herstellers zurückgreifen. Diese Lösungen zeigen dann in der Regel alle von der CPU unterstützten Techniken an, so dass schon in der Planung klar ist, ob die benötigten Sicherheitsmerkmale auf der Plattform der Wahl zur Verfügung stehen.

Die wichtige Rolle des Hypervisors für die Sicherheit

Hat der Administrator die Hyper-V-Rolle auf einem Windows Server 2008 installiert, so laufen auf diesem System danach alle Instanzen von Betriebssystemen auf virtuellen Maschinen. Gerade für den Blick auf die Sicherheit ist es wichtig zu wissen, dass dies in diesem Fall auch für die Instanz des Windows Servers 2008 gilt, aus der heraus der Administrator die anderen virtuellen Maschinen installiert und verwaltet. Hyper-V verwendet einen sogenannten Microkernel.

Dabei handelt es sich um eine spezielle Abstraktionsschicht, die laut Aussagen der Microsoft-Entwickler kleiner als 1 MByte ist. Sie arbeitet und vermittelt zwischen der Hardware und dem Host-Betriebssystem und wird als Hypervisor (Bild 2) bezeichnet. Er besitzt direkte Schnittstellen zur Hardware und startet immer vor dem eigentlichen Betriebssystemstart. Bereits beim Design des Hypervisors sind die Microsoft-Ingenieure nach eigenen Aussagen so vorgegangen, dass Programmcode eines Drittherstellers dort grundsätzlich nicht ausgeführt werden kann.

Geht es nun zum Beispiel um wichtige Aufgaben wie die Verwaltung der Hauptspeicherbereiche, so werden solche systemkritische Arbeiten bei dieser Art des Designs direkt vom Hypervisor ausgeführt. Dadurch wird gewährleistet, dass eine Abschottung zwischen dem Host-Betriebssystem und denen der virtualisierten Systeme in Bezug auf die Sicherheit gewährleistet ist. Wer mit dem Hyper-V arbeitet, wird immer wieder auf den Begriff der Partition treffen: Microsoft bezeichnet damit in diesem Zusammenhang den jeweiligen Bereich, in dem das Host-System oder eines die virtualisierten Betriebssysteme aktiv ist. Einem Systemverwalter steht dabei die Möglichkeit zur Verfügung, eine dieser Partitionen als Basiseinheit zu definieren.

Diese ausgewählte Partition, in der dann das Host-Betriebssystem aktiv ist, wird von Microsoft als Parent-Partition bezeichnet. Die anderen Bereiche, in denen dann jeweils die virtualisierten Systeme laufen, tragen den Namen »Child-Partitions« (Bild 2). Die sogenannte Parent-Partition besitzt ganz besondere Eigenschaften und Möglichkeiten. Nur von diesem Bereich aus ist es möglich, die Child-Partitionen anzulegen und auch zu verwalten. Alle Ressourcen des Systems, die nicht direkt dem Hypervisor unterstehen, werden ebenfalls von diesem Bereich aus organisiert. Die Parent-Partition ist im Sinne des Systems immer auch der Besitzer dieser Ressourcen. So kann sie unter anderem auch das Power Management (beinhaltet die Optionen zur Energieverwaltung) verwalten.

Treten bestimmte Ereignisse auf, die auf Hardwarefehler beruhen und damit die Integrität der gesamten Virtualisierungslösung gefährden können, werden diese auch durch die »Eltern-Partition« direkt verwaltet. Aber ebenso wenig wie alle anderen Child-Partitionen kann diese ansonsten mit so hohen Privilegien ausgestattet Partition in irgendeiner Weise in den Bereich des Hypervisors hineinschreiben – ein weiteres sehr wichtiges Sicherheitsfeature, das direkt in das Design hinein implementiert wurde.

Diese kurzen Ausführungen verdeutlichen schon sehr schön, dass der Hypervisor eine extrem wichtige Funktion übernimmt, indem er zur Isolation der einzelnen Partitionen voneinander beiträgt. Diesen Weg haben die Entwickler auch bei anderen Aspekten weiter verfolgt. So ging es unter anderem immer wieder darum, die grundsätzliche bestehende Angriffsfläche all dieser Komponente weiter zu verringern. Aus diesem Grund wurden sowohl der Programmcode als auch die Dienste, die innerhalb dieser Schicht laufen können, stark eingeschränkt: Als Ergebnis davon beinhaltet dieser Teil der Virtualisierungslösung Hyper-V keine I/O-Stacks und auch keine Gerätetreiber.

Innerhalb der Parent-Partitionen sind Gerätetreiber aktiv, mit deren Hilfe die Child-Partitionen mit der darunterliegenden Hardware kommunizierten. Für eine Hypervisor-Architektur, die auf einen Microkernel aufsetzt, ist dies die übliche und typische Art, um mit Gerätetreibern umzugehen. Allerdings ist dies häufig auch ein Kritikpunkt, denn dieses Vorgehen birgt durchaus Nachteile. Eine Parent-Partition ist durch den Aufbau in dieser Art und Weise grundsätzlich auch größeren Risiken ausgesetzt: Gelangen fehlerhafte oder bösartige Treiber hier hinein, so könnten sie diesen Bereich sehr leicht entsprechend stark gefährden.

Extrem wichtig: Der Schutz der Parent-Partition

 Der vorherige Abschnitt hat bereits gezeigt, wie wichtig der Schutz der Parent-Partion und damit des Bereichs ist, in dem sich das 64-Bit-Server Host-Betriebssystem auf dem Hyper-V-Server befindet. Es kann also immer nur darum gehen, die Angriffsfläche dieser Partition möglichst weit zu verkleinern. Auf diese Weise kann ein Systemverwalter dann auch eine höhere Sicherheit für den gesamten Hyper-V-Server und die virtuellen Maschinen (VMs) in den Gast-Partitionen erreichen. Eine bewährte Möglichkeit dieses Ziel zu erreichen besteht darin, bei der Installation des Servers die Server-Core-Option auswählen.

Allerdings sollte der Systemadministrator dabei nie vergessen, dass er diese Variante des Windows Server 2008 nur dann als Grundlage eines Virtualisierungssystems verwenden kann, wenn es sich bereits bei der Installation des Windows-Servers zu diesem Schritt entscheidet. Eine spätere Umwandlung des kompletten Windows-Servers in den Core-Server ist nicht möglich, hier kann dann nur eine komplette Neuinstallation zu einem Core-System verhelfen. Nach dieser Installation steht dann grundsätzlich ein Server ohne die übliche Windows-Oberfläche zur Verfügung. Auf diesem System kann aber eine Untermenge der Server-Rollen wie etwa ein Domänen-Controller, Datei-Server und eben auch ein Hyper-V-Server zu Einsatz kommen.

Es ist ohne Frage so, dass dadurch die generelle Angriffsfläche des Server-Systems, dass schließlich nur noch über die Kommandozeile oder Remote mittels einer Terminal-Server-Verbindung verwaltet werden kann, entscheidend verringert werden kann. Das wiederum erhöht auch die Sicherheit eines darauf aktiven Hyper-V-Systems. Auch die Standalone-Version der Hyper-V-Software bietet sich unter diesem Aspekt zum Einsatz an: Wer diese Software von der Microsoft-Seite herunterlädt und auf seiner Hardware installiert, der betreibt darauf keinen Windows Server 2008 Standard, Enterprise oder Datacenter mit installierter Hyper-V-Rolle mehr, sondern besitzt direkt eine sehr schlanke Virtualisierungsplattform ohne grafische Benutzerschnittstelle (GUI) mit einer ebenfalls deutlich verringerten Angriffsfläche. Braucht man in seiner IT-Umgebung jedoch die Optionen zur Hochverfügbarkeit wie etwa das Windows Failover Clustering (WFC), so ist dies mit dieser Hyper-V-Variante nicht möglich.

Nur die minimale Berechtigung verwenden

 IT-Fachleute, die eine Windows-Domäne und eine gewisse Anzahl von Windows- und Anwendungsserver zu betreuen haben, kennen ein wichtiges Sicherheitsprinzip, das in diesen Umgebungen so häufig wie möglich zum Einsatz kommen sollte: die »Least Priviliges«. Dabei werden Systembetreuer und Administratoren grundsätzlich nur mit den Zugriffsrechten und  -privilegien ausgestattet, die sie zur Erledigung ihrer Aufgaben unbedingt benötigen.

Gerade für die virtualisierten Server-Systeme sollte dieses Prinzip aus Sicherheitsgründen ebenfalls möglichst stringent durchgesetzt werden. Das bedeutet, dass für bestimmte virtuelle Maschinen die jeweils verantwortlichen Administratoren auch ausschließlich nur diese ihnen zugeordneten VMs verwalten können. Fast selbstverständlich ist in diesem Zusammenhang dann der Hinweis, dass sie zudem auf keinem Fall die Möglichkeit besitzen sollten, in irgendeiner Weise auf die Parent-Partition zuzugreifen. Wie können solch strenge Vorgaben in der Praxis funktionieren?

Für die IT-Leitung bedeutet dieser Anspruch, dass die Zugriffsrechte dieses Personenkreises auch dementsprechend eingeschränkt und kontrolliert werden müssen. Auf dem Hyper V Server kann dazu der Authorisierungs-Manager (Authorization Manager – »AzMan«) des Betriebssystems zum Einsatz kommen. Diese Software wurde von Microsoft erstmals mit dem Windows Server 2003 zur Verfügung stellte. In unserem Bild 3 ist dieses Werkzeug innerhalb der MMC (Microsoft Management Console) auf einem Windows Server 2008 R2 zu sehen.

Mit Hilfe der Software können ganz spezifische Rollen für die VM-Administratoren festgelegt und durchgesetzt werden. Ein Beispiel für eine derartige Einstellung ist ebenfalls in Bild 3 zu sehen: An dieser Stelle kann dann beispielsweise sichergestellt werden, dass nur ganz bestimmte Personen oder auch Personenkreise dazu in der Lage sind, auf die ihnen jeweils zugewiesenen virtuellen Maschinen zuzugreifen.

Wer über Sicherheitsmaßnahmen spricht, sollte in diesem Zusammenhang auch die Möglichkeiten der Laufwerksverschlüsselung BDE (»Bitlocker Drive Encryption«) nicht vergessen. Microsoft liefert diese Möglichkeit der transparenten Verschlüsselung standardmäßig mit dem Windows Server 2008 und einigen Version von Windows 7 (Ultimate und Enterprise) aus. Dabei stellt BDE unter anderem auch einen Offline-Datenschutz zur Verfügung. Dadurch sind die Daten auch geschützt und verschlüsselt, wenn der Windows-Rechner nicht eingeschaltet und das Betriebssystem nicht aktiv ist. Eine Multifaktor-Authentifizierungs-Möglichkeit, die diese Software ebenfalls zur Verfügung stellt, schützt ein derart gesichertes System während des Startvorgangs ebenfalls vor unberechtigten Zugriffen:

So wird sichergestellt, dass Angreifer eine derartige Verschlüsselung nicht umgehen, indem sie das System von einem anderen Betriebssystem aus oder mittels spezieller Angriffswerkzeuge hochfahren. Wer seine Hyper-V-Installation unter Einsatz des Bitlockers zusätzlich abzusichern möchte, kann die physikalischen Festplatten, auf denen sich beispielsweise die Dateien für die virtuellen Festplatten (VHDs –Virtual Hard Disks) sowie die Konfigurationsdateien befinden, mittels BDE wirkungsvoll und vor allen Dingen für das System transparent verschlüsseln. Microsoft stellt auf seine Seiten ein ausführliches White Paper zu diesem Thema unter dem Titel: »Windows Server 2008 Hyper-V and BitLocker Drive Encryption« zur Verfügung.

Guest Hopping als neue Angriffsform

Zum Abschluss stellen wir hier noch einige ausgewählte Angriffsszenarien auf Hyper-V-Installationen vor, die in der letzten Zeit bekannt geworden sind. Einer dieser Fälle ist die »Guest-Hopping«-Attacke: Dabei wird der Angreifer zunächst einmal versuchen, zwei virtuelle Maschinen zu identifizieren, die auf dem gleichen Host-System aktiv sind. Dieser doppelte Angriff bietet ihm einen entscheidenden Vorteil. Will er nämlich  Daten in der ersten der beiden VMs angreifen, kann aber auf diese nicht zugreifen, so steht ihm dadurch noch der Weg offen, die zweite VM zu infiltrieren und dann mit einem entsprechenden »Sprung« – dem Guest-Hopping – direkt in die gewünschte VM einzudringen.

Zwar wurde ein derartiges Szenario bereits einige Male beschrieben, es ist aber leider wenig darüber bekannt, ob entsprechende Angriffe schon erfolgreich durchgeführt werden konnten. Die Anbieter von Virtualisierungs-Lösungen bestreiten zumeist, dass ein solches unkontrolliertes »Wandern« zwischen den VMs möglich sei.

In einer weiteren Variante dieses Angriffs wird ein solches Szenario auch auf der Ebene der Hypervisor durchgespielt: Gelingt es einem Angreifer dem Hypervisor trotz all der zuvor erläuterten Schutzmaßnahmen einen kompromittierten Server unterzuschieben und sind zudem in einem Netzwerk bereits mehrere Host-System betroffen, so kann das Angriffsprogramm von einem Virtual-Server-Host zum nächsten wechseln. In diesem Fall dürfte es für die Administratoren extrem schwierig werden, diese Angriffe zu entdecken und abzuwehren.

Hyper Jacking kann alle Hypervisoren betreffen

 Eine weitere Methode wird als Hypervisor-Attacke oder auch als »Hyper-Jacking« bezeichnet: Der Angreifer bedient sich in diesem Fall ganz unterschiedlicher Methoden, um letztendlich die Kontrolle über den Hypervisor und damit über die komplette Virtualisierungs-Lösung zu übernehmen. So kann er beispielsweise einen zusätzlichen »Rogue Hypervisor« so auf dem System installieren, dass er unterhalb des echten Hypervisors direkt auf der Hardware aktiv wird.

Ein zweiter Weg kann durch viele der Maßnahmen, die hier in unserem Artikel bereits vorgestellt wurden, im Prinzip wirkungsvoll abgeblockt werden: Das Vorgehen besteht hier darin, die direkte Kontrolle über den Hypervisor zu erlangen. Dabei kann dann ein kompromittierter Hypervisor direkt auf dem richtigen Hypervisor installiert werden, so dass auch hier alle Ein- und Ausgaben sowie die Systemaufrufe abgefangen werden.

Die bisher bekannteste dieser Attacken ist das sogenannte »Subvirt Virtual Machine Based Root Kit« (VMBR). Es wurde bereits im Jahr 2006 als »proof of concept« entwickelt und hat damals für ziemliches Aufsehen gesorgt. Diese Software installierte sich dabei als Schicht zwischen dem Originals-Betriebssystem und der darunterliegenden Hardware. Das Original-System wurde danach dann unbemerkt als Gast-System betrieben.

Absolut und hundertprozentig sichere Rechnersysteme wird es nie geben, und das gilt selbstverständlich auch für virtualisierte Systeme und deren Hosts. So dürfen die Administratoren auch bei dieser Art der Systeme die klassischen Best Practices aus dem Sicherheitsbereich nie außer Acht lassen. So sollten sie – und diese Maßnahme ist so selbstverständlich, dass wir sie hier nur am Rande erwähnen — beispielsweise immer dafür Sorge tragen, dass die Betriebssysteme und Anwendungen innerhalb der virtuellen Maschinen zu jeder Zeit mit einer zuverlässigen Antivirus-Lösung sowie den entsprechenden  Sicherheits-Updates und -Patches ausgestattet sind.