Schon in den 1960er Jahren entwickelte die IBM mit ihrem Forschungssystem CP/CMS auf der Basis des System/360 eine Architektur für virtuelle Systeme. Heute sind bereits über 80 Prozent der Server virtualisiert. Doch Neil MacDonald vom Marktforschungsinstitut Gartner geht davon aus, dass immer noch 30 Prozent der virtuellen Server weniger sicher sind als die physischen Server, die sie ersetzen. Deshalb soll in dieser Seminararbeit untersucht werden, welche Sicherheitsprobleme virtuelle Systeme aufweisen, welche Angriffe es gibt und wie diese Angriffe erkannt und verhindert werden können.
Inhaltsverzeichnis
1 Was ist Virtualisierung?
1.1 Typ-1- und Typ-2-Hypervisor
1.2 Gründe für den Einsatz von Virtualisierung
2 Sicherheitsprobleme virtualisierter Systeme
2.1 Schadsoftware in virtuellen Systemen
2.2 Virtuelle Netzwerkswitche
2.3 Administration
2.4 Diebstahl eines kompletten virtuellen Systems
3 Angriffe auf virtuelle Systeme
3.1 Race Condition beim symmetrischen Multiprocessing in KVM
3.2 Ausführung beliebigen Python-Codes in Xen
3.3 Virtualisierungs-Rootkit Blue Pill
4 Erkennung und Verhinderung von Angriffen
4.1 Host-based Intrusion Prevention Systeme (HIPS)
4.2 Network-based Intrusion Prevention Systeme (NIPS)
4.3 Virtual Machine Introspection (VMI)
5 Fazit
6 Literaturverzeichnis
1 Was ist Virtualisierung?
Schon in den 1960er Jahren entwickelte die IBM mit ihrem Forschungssystem CP/CMS auf der Basis des System/360 eine Architektur für virtuelle Systeme.1 Heute sind bereits über 80 Prozent der Server virtualisiert.2 Doch Neil MacDonald vom Marktforschungsinstitut Gartner geht davon aus, dass immer noch 30 Prozent der virtuellen Server weniger sicher sind als die physischen Server, die sie ersetzen.3 Deshalb soll in dieser Seminararbeit untersucht werden, welche Sicherheitsprobleme virtuelle Systeme aufweisen, welche Angriffe es gibt und wie diese Angriffe erkannt und verhindert werden können.
1.1 Typ-1- und Typ-2-Hypervisor
Herzstück der Virtualisierung ist der Hypervisor, der auch Virtual Machine Monitor (VMM) genannt wird. Der Hypervisor ist eine Software, die auf dem Host-Betriebssystem bzw. direkt auf der Hardware läuft und es ermöglicht, (theoretisch) beliebig viele virtuelle Gast-Systeme zu betreiben. Dazu ordnet er jedem Gast-System Ressourcen wie z.B. Festplattenspeicherplatz, Arbeitsspeicher, Prozessorzeit oder Peripherie zu. Der Hypervisor isoliert die virtuellen Gast-Systeme voneinander, sodass diese den Eindruck haben, auf einem physischen System zu laufen.4
Man unterscheidet grundsätzlich zwischen Typ-1-Hypervisor und Typ-2-Hypervisor.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Architektur eines Typ-1-Hypervisors[5]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Architektur eines Typ-2-Hypervisors[6]
Der Typ-1-Hypervisor läuft ohne ein zusätzliches Betriebssystem direkt auf der Hardware (siehe Abbildung 1). Ein Beispiel für einen Typ-1-Hypervisor ist Xen, das zusätzlich noch ein privilegiertes virtuelles System (Dom0) bereitstellt, das die anderen virtuellen Systeme steuert und verwaltet.7
Der Typ-2-Hypervisor läuft als Anwendung auf einem Host-Betriebssystem, auf dem auch noch andere Prozesse laufen können (siehe Abbildung 2). Ein Beispiel für einen Typ-2-Hypervisor ist KVM (Kernel-based Virtual Machine), das inzwischen Teil des Linux-Kernels ist.8
1.2 Gründe für den Einsatz von Virtualisierung
Der Hauptgrund für Unternehmen, physische Systeme zu virtualisieren, ist die Möglichkeit Kosten einzusparen. Durch die Virtualisierung wird nur noch ein physisches Host-System benötigt, auf dem mehrere virtuelle Gast-Systeme laufen können. Dadurch kann sowohl Strom, als auch Platz eingespart werden.9
Ein weiterer Grund ist die Möglichkeit, das virtuelle System an einen Drittanbieter auszulagern. Da ein Drittanbieter virtuelle Systeme von vielen Kunden betreibt, können Auslastungsschwankungen der virtuellen Systeme auf einem Host untereinander ausgeglichen werden, wodurch die Ressourcenausnutzung insgesamt erhöht wird. Dadurch ist es möglich, dass der Anbieter nur die tatsächlich genutzten Ressourcen in Rechnung stellt, wodurch für den Kunden eine Kostenersparnis im Vergleich zu nicht-virtualisierten Systemen erreicht wird, bei denen auch Leerlaufzeiten Geld kosten.10
Zudem kann der Kunde ohne großen Aufwand ein virtuelles System für Test- und Entwicklungszwecke einrichten, um z.B. neu entwickelte Software unter verschiedenen Bedingungen testen zu können.11 Diese Testsysteme können nach Abschluss des Tests wieder in ihren Ursprungszustand zurückgesetzt werden, wodurch einheitliche Testbedingungen gewährleistet werden.
2 Sicherheitsprobleme virtualisierter Systeme
Grundsätzlich sind virtuelle Systeme den gleichen Sicherheitsrisiken ausgesetzt wie traditionelle (nicht virtualisierte) Systeme. Durch die Virtualisierung kommen jedoch weitere Risiken hinzu, die bei traditionellen Systemen nicht existieren.12 Deshalb reichen die Sicherheitsmechanismen, mit denen traditionelle Systeme geschützt werden, bei virtuellen Systemen nicht aus.
2.1 Schadsoftware in virtuellen Systemen
Besonders hochentwickelte Schadsoftware kann erkennen, dass es sich bei dem befallenen System um ein virtuelles System handelt und versuchen, den Hypervisor anzugreifen und so aus dem virtuellen System auszubrechen.13 Auf diese Weise kann die Schadsoftware auch das Host-System und die anderen auf dem Host-System laufenden Gast-Systeme angreifen. Der erfolgreiche Angriff auf ein weniger sicherheitskritisches System (z.B. ein Testsystem für neue Software) kann so schon ausreichen, um in ein sicherheitskritisches System (z.B. eine Online-Banking-Anwendung) einzudringen.14
2.2 Virtuelle Netzwerkswitche
Traditionelle Netzwerkswitche werden zunehmend durch virtuelle Switche ersetzt. Durch die Tatsache, dass diese Switche für Netzwerkadministratoren weniger sichtbar sind, werden Angriffe auf diese Switche nicht so schnell erkannt oder können komplett unerkannt bleiben. Außerdem erhöht sich durch den Einsatz von virtuellen Switchen die Komplexität des Netzwerks, was die Wahrscheinlichkeit von Konfigurationsfehlern und somit von Sicherheitslücken erhöht.15
2.3 Administration
Für die Sicherheit des Gesamtsystems ist die Administration und Überwachung der virtuellen Systeme besonders wichtig. So sollte z.B. durch die restriktive Vergabe von Benutzerrechten verhindert werden, dass sich einzelne Benutzer ohne Wissen des Administrators eigene virtuelle Systeme einrichten. Da der Administrator von diesen virtuellen Systemen nichts weiß, werden Sicherheitslücken in diesen Systemen auch nicht zentral gepatcht, was das Risiko eines erfolgreichen Angriffs auf dieses System erhöht. Gelingt es dem Angreifer anschließend aus dem virtuellen System auszubrechen, kann er auch in sicherheitskritische virtuelle Systeme eindringen.16
2.4 Diebstahl eines kompletten virtuellen Systems
Virtuelle Systeme werden im Host-System in Form von wenigen Dateien gespeichert. Dadurch kann ein Angreifer, nachdem er ins Host-System eingedrungen ist, einfach ein komplettes virtuelles System mit allen darin befindlichen Daten stehlen, indem er die Datei, in der die virtuelle Festplatte des virtuellen Systems gespeichert ist, stiehl. Durch die Wiederherstellungspunkte ist es dem Angreifer außerdem möglich, jeden beliebigen Zustand der virtuellen Maschine wiederherzustellen.17
3 Angriffe auf virtuelle Systeme
Die größte Schwachstelle von virtualisierten Systemen stellt der Hypervisor dar. Falls die Schadsoftware es schafft, den Hypervisor zu überwinden und so aus dem Gast-System auszubrechen, hat sie die Kontrolle über das Host-System und alle darauf laufenden virtuellen Systeme. In den folgenden Abschnitten sollen einige ausgewählte Angriffe auf virtuelle Systeme dargestellt werden.
3.1 Race Condition beim symmetrischen Multiprocessing in KVM
Beim symmetrischen Multiprocessing (SMP) besitzen mehrere Prozessoren einen gemeinsamen Adressraum. Dadurch können Prozesse dynamisch auf die Prozessoren verteilt werden und müssen nicht fest einem Prozessor zugewiesen werden.
Der x86-Emulator in KVM enthält eine Lücke, die es einem Angreifer mithilfe von SMP ermöglicht, höherer Rechte im Gast-System zu erhalten oder das Gast-System zum Absturz zu bringen. Dazu startet der Angreifer einen Thread mit einem legitimen I/O-Befehl und einen Thread mit einem beliebigen anderen Befehl. Nachdem der KVM-Hypervisor die Gültigkeit des I/O-Befehls überprüft hat, aber noch bevor der Befehl ausgeführt wird, ersetzt der Angreifer den I/O-Befehl durch einen anderen Befehl, der dann mit den Rechten des I/O-Befehls ausgeführt wird.18
3.2 Ausführung beliebigen Python-Codes in Xen
Joris van Rantwijk fand eine Lücke in Xen, die es erlaubt, beliebigen Python-Code in der in Xen privilegierten virtuellen Maschine Dom0 auszuführen. Dadurch kann ein Angreifer aus dem virtuellen System ausbrechen und die Kontrolle über alle virtuellen Systeme auf dem physischen System erlangen.
Der Bootloader, den Xen den virtuellen Systemen zur Verfügung stellt, erlaubt es den virtuellen Systemen, die Bootparameter in der Datei grub.conf selbst festzulegen. Beim Starten eines Gast-Systems führt Xen die in der grub.conf enthaltenen Befehle ohne weitere Überprüfung aus. Dadurch erlaubt es Xen, jeden beliebigen Befehl in Dom0 auszuführen, wodurch ein Angreifer aus dem virtuellen System ausbrechen kann.19
3.3 Virtualisierungs-Rootkit Blue Pill
Joanna Rutkowska stellte 2008 auf der RSA Conference das Virtualisierungs-Rootkit Blue Pill vor, das ein laufendes Betriebssystem, ohne dass es der Anwender bemerkt, in ein virtuelles System verschieben kann. Das Rootkit installiert dazu einen dünnen Hypervisor, der das eigentliche Betriebssystem virtualisiert. Zwischen dem so virtualisierten Betriebssystem und der Hardware installiert sich dann die Schad-software, die somit die Kontrolle über das virtuelle System erhält.
Weder der Anwender noch die installierte Schutzsoftware kann das Rootkit erkennen, da es sich außerhalb des Betriebssystems befindet und alle Funktionen wie gewohnt funktionieren. Die einzige Möglichkeit Blue Pill zu erkennen wäre eine Fehlfunktion des Hypervisors.20
4 Erkennung und Verhinderung von Angriffen
Als Virtualization Management Software bezeichnet man Software, die virtuelle Systeme verwaltet und deren Ausführung überwacht. Diese Software bietet bereits Möglichkeiten der Überwachung des Netzwerkverkehrs und der Leistung und liefert so Indikatoren, an denen ein potenzieller Angriff erkannt werden kann.21 Für eine umfassende Erkennung und Verhinderung von Angriffen auf virtuelle Systeme reicht dies jedoch nicht aus. Deshalb werden Intrusion Detection Systeme (IDS) und Intrusion Prevention Systeme (IPS) benötigt.
[...]
1 vgl. [IBM2012], Seite 1.
2 vgl. [TecChannel2015].
3 vgl. [Gartner2010].
4 vgl. [Tsifountidis2011], Seite 3.
5 angelehnt an [Perez2013], Seite 2.
6 angelehnt an [Perez2013], Seite 2.
7 vgl. [Perez2013], Seite 2.
8 vgl. [Perez2013], Seite 2.
9 vgl. [Tsifountidis2011], Seite 4.
10 vgl. [Tsifountidis2011], Seite 4.
11 vgl. [Tsifountidis2011], Seite 5.
12 vgl. [Tsifountidis2011], Seite 4.
13 vgl. [Tsifountidis2011], Seite 4.
14 vgl. [Tsifountidis2011], Seite 5.
15 vgl. [Tsifountidis2011], Seite 4-5.
16 vgl. [Tsifountidis2011], Seite 5.
17 vgl. [Tsifountidis2011], Seite 5.
18 vgl. [NIST2010].
19 vgl. [NIST2007].
20 vgl. [Rutkovska2008].
21 vgl. [Tsifountidis2011], Seite 6.
- Quote paper
- Anonymous,, 2016, Analyse der Sicherheit von Cloud Computing, Munich, GRIN Verlag, https://www.hausarbeiten.de/document/1313310