SubVirt

SubVirt
Stefan Kempf
11. Oktober 2007
Kurzzusammenfassung
SubVirt bezeichnet zwei Referenzimplementierungen eines Virtual-Machine Based
Rootkits (VMBR) von Forschern der Uni Michigan und Microsoft-Research. Ihrer Meinung nach könnten VMBRs bald genutzt werden, die Kontrolle über einen Rechner zu
übernehmen und dabei unerkannt zu bleiben. Diese Ausarbeitung betrachtet Implementierung und Betrieb der SubVirt-Rootkits, sowie Erkennungsmöglichkeiten.
1
1.1
Einführung und Motivation
Beispielszenario
Gehen wir von der Situation aus, dass ein Angreifer in ein System einbricht. Er wird sehr
wahrscheinlich versuchen, seine Aktivitäten vor dem Systemadministrator zu verbergen, um
den Zugang zum System möglichst lange zu behalten.
Als erste Maßnahme werden dazu Programme, die die Anwesenheit (who(1)) oder Aktivitäten (ps(1)) des Angreifers verraten können, manipuliert bzw. ausgetauscht, so dass sie
falsche Informationen anzeigen. Der Administrator kann versuchen, sich gegen ein solches
Vorgehen mit Hilfe eines Intrusion-Detection-Systems zu schützen. Dieses wird so konfiguriert, dass Veränderungen an Systemdateien oder -programmen protokolliert und gemeldet
werden. Nun kann es der Angreifer anstreben, auch das IDS zu umgehen. Dazu installiert er
ein Rootkit, das sich aufgrund von Schwachstellen im Kern des Betriebssystems in diesen einnistet. Mit der Kontrolle über den Kernel wird es möglich, allen Prozessen im Benutzermodus
falsche Informationen über das System zu liefern oder komplett vorzuenthalten. Das Rootkit
verhindert, dass Prozesse des Angreifers von ps(1) angezeigt werden können, wobei für diese
unter Linux z.B. kein Eintrag im /proc Dateisystem angelegt wird. Außerdem werden dem
IDS Falschangaben über Dateien geliefert, damit es Manipulationen daran nicht feststellen
kann.
Administrator und Angreifer versuchen sich also gegenseitig in Schach zu halten, indem jeder
von ihnen die Kontrolle über eine möglichst tief liegende Ebene des Systems anstrebt, da dies
die Kontrolle über das Gesamtsystem bedeutet.
1.2
Idee eines VMBR
Rootkits laufen im Kernel und haben Einfluss auf den Benutzermodus. Der nächste Schritt
ist ein Virtual-Machine Based Rootkit, das direkt auf der Hardware läuft und das Betriebssystem kontrolliert, indem es dieses in einer virtuellen Maschine ausführt. Parallel dazu, und
damit vom eigentlichen Betriebssystem isoliert, läuft ein Angriffssystem. Dort lassen sich alle
Aktivitäten ausführen, die unentdeckt bleiben sollen. Folgendes Schaubild soll dies darstellen.
1
Anwendung
Malware
Malware
Anwendung
Gastsystem
Angriffssystem
VMM
Hardware
Das Angriffssystem kann dabei ein beliebiges Betriebssystem wie z.B. Linux sein. Ist die
Virtualisierung perfekt, so wird das Betriebssystem die Existenz der virtuellen Maschine, des
Angriffssystems und die darin ablaufenden Aktivitäten nicht feststellen können. Zu klären
ist hierbei noch, wie ein VMBR installiert wird und wie das Betriebssystem in die virtuelle
Maschine befördert wird.
1.3
SubVirt
Forscher der Universität Michigan und Microsoft-Research haben sich mit dem Thema VMBR
befasst, da nach ihrer Auffassung diese Art von Rootkit in Zukunft eine neue Bedrohung für
die Sicherheit und Integrität eines Systems darstellen wird. Um frühzeitig Verteidigungsstrategien gegen VMBRs entwickeln zu können, haben sie mit SubVirt zwei Referenzimplementierungen eben solcher Rootkits geschaffen. Die erste Variante basiert auf VMWare
als virtueller Maschine und einem modifizierten Linux-Kernel als Angriffssystem. Die zweite
Variante verwendet angepasste Versionen von Virtual PC und Windows XP. Linuxrechner
wurden mit dem ersten Rootkit infiziert, auf Computern mit Windows als Betriebssystem
wurde das zweite VMBR verwendet. Das Angriffssystem stimmt also in beiden Varianten mit
dem Zielbetriebssystem überein, was aber keine zwingende Voraussetzung ist.
2
Installation eines VMBR
Um ihr VMBR auf dem Zielrechner zu installieren, gingen die Autoren von SubVirt folgendermaßen vor: Zuerst muss der Angreifer einen Weg finden, wie er sich Zugriff auf das System
verschaffen kann um Administratorrechte zu erlangen. (Ausnutzen von Sicherheitslücken,
Social Engineering, etc). Dann wird das Rootkit installiert. Nach der Installation muss der
Rechner heruntergefahren werden. Kurz vor dem Shutdown wird die Bootsequenz jedoch
manipuliert, so dass beim nächsten Neustart das VMBR statt des eigentlichen Betriebssystems geladen wird. Das Rootkit startet dann das Betriebssystem in einer virtuellen Maschine. Das Betriebssystem ist jetzt zum Gastsystem im VMBR geworden und greift nur noch
auf virtuelle Hardware zu. Auf Linuxsystemen wird SubVirt in der Swappartition installiert, weswegen Swapping im Zielsystem vor der Installation deaktiviert werden muss. In der
Windows-Variante wird das Rootkit am Anfang des Dateisystems platziert. Dort eventuell
vorhandene Dateiblöcke müssen vorher in freie Bereiche der Platte umkopiert werden, was
auch eine Aktualisierung der Verwaltungsstrukturen des Dateisystems erfordert.
Die Manipulation des Bootvorgangs wird bei Linux über eine Änderung der Shutdownskripte
bewirkt. Nachdem init(8) alle Prozesse beendet hat, wird der neue Bootcode installiert.
2
Unter Windows wird im Zielsystem ein Kernelmodul verwendet. Der Bootcode, der beim
nächsten Start das VMBR lädt, wird von diesem Modul kurz bevor der Rechner heruntergefahren wurde installiert. Zu diesem Zeitpunkt laufen fast keine Prozesse mehr im System.
Weiterhin wird der Code nicht über das Dateisystem geschrieben, sondern direkt über den
Festplattentreiber. Programme, die die Integrität des Dateisystems überwachen (falls diese
kurz vor dem Shutdown überhaupt noch laufen) , werden die Installation des Bootcodes nicht
bemerken, da dieser im Dateisystem selbst keine Veränderung hervorruft.
3
Anwendungen
Die Autoren teilen die Anwendungen, die sich mit einem VMBR realisieren lassen, in drei
Kategorien ein:
• Interaktionslos
• Observierend
• Manipulierend
Interaktionslose Malware ist an Geschehnissen oder Informationen im Gastsystem nicht interessiert. Beispiele dafür sind Phishing-Webserver, Spam-Relays und Bots für DDoS-Attacken.
Zu observierenden Programmen zählen Keylogger oder Paketsniffer, die im Gastsystem verarbeitete Informationen zwar auslesen, aber nicht verändern.
Werden die Informationen von der eingesetzten Software im Angriffssystem jedoch geändert,
gelöscht oder wird der Programmablauf von Anwendungen im Gastsystem beeinflusst, so
spricht man von manipulierender Malware.
3.1
Phishing-Webserver
Phishing-Webseiten ahmen die Internetauftritte von Banken oder Webshops nach und fordern
arglose Benutzer auf, ihre Kontodaten preiszugeben. Um Phishing mittels eines VMBR zu
betreiben, wird im Angriffssystem der Webserver thttpd installiert, der dort auf Port 8080 auf
ankommende Verbindungen wartet. Das VMBR leitet fast den gesamten ankommenden Netzwerkverkehr in das Gastsystem weiter. TCP-Pakete, die allerdings für Port 8080 bestimmt
sind, werden an das Angriffssystem geschickt und damit von thttpd empfangen, der dann
mit dem Client kommuniziert. Es muss also kein eigener Code geschrieben werden, sondern
man kann auf bereits vorhandene Software zurückgreifen. Lediglich das virtuelle Netzwerk
muss richtig konfiguriert werden. Diese Anwendung wurde mit dem Linux-VMBR realisiert.
3.2
Keylogger
Für den Keylogger, der im auf Windows basierenden Rootkit implementiert wurde, waren
jedoch geringfügige Änderungen notwendig. Die Emulation des Tastaturcontrollers in Virtual PC wurde so angepasst, dass alle Tastendrücke zuerst an das Angriffssystem, dann ans
Gastsystem geliefert werden. Eine Anwendung im Angriffssystem wertet die Tastendrücke
aus und versucht, eingegebene zu Passwörter zu extrahieren. Die Modifikation von Virtual
PC beträgt dabei 60 Zeilen, der Keylogger selbst besteht aus 254 Zeilen.
3
3.3
Virtual-Machine Introspection
Um manipulierende Malware realisieren zu können, sind Techniken notwendig, die unter
dem Begriff Virtual-Machine Introspection (VMI) zusammengefasst werden. Darunter fallen
bereits relativ einfache Dinge, wie das Auslesen oder Setzen von Registerwerten eines Prozesses, wie es auch bei Debuggern genutzt wird. Darüber hinaus können die Symboltabelle
bzw. Debuginformationen einer Anwendung analysiert werden, um zu manipulierende Anweisungen im Programm zu finden. Diese können dann verändert werden bzw. man kann einen
Breakpoint an jene Stellen setzen und darauf warten, dass der Code ausgeführt wird. Ist
das dann der Fall, so lassen sich z.B. die Daten, auf denen der Code arbeitet, auslesen oder
verändern. Ebenso kann im Gastsystem vorhandener Code als Bibliothek“ für das VMBR
”
dienen. Möchte das Angriffssystem Zugriff auf Dateien im Gastsystem haben, so muss der
Dateisystemtreiber im Angriffssystem nicht neu implementiert werden. Man muss nur die relevanten Codestellen im Gastsystem anspringen. Dies ist für das Rootkit von Vorteil, da sich
damit seine Codegröße reduzieren lässt und somit schwerer aufzuspüren wird. Will man diese
Techniken einsetzen, muss der Angreifer aber genaue Kenntnisse über den Aufbau der zu beeinflussenden Anwendungen haben. Möchte er z.B. verschlüsselte Kommunikation abhören,
so muss bekannt sein, an welchen Stellen in der Anwendung die Daten ver- oder entschlüsselt
werden, um sie vorher im Klartext abfangen zu können.
3.4
Stehlen sensitiver Dateien
Mit Hilfe von VMI wurde im Angriffssystem des Linux-VMBR ein Perlskript von 24 Zeilen geschrieben. Es läuft im Angriffssystem und durchsucht das Dateisystem des Gastsystems. Dabei kopiert es /etc/shadow, die Passwortdatei eines Linuxsystems sowie private SSH-Schlüssel
der Benutzer, soweit vorhanden.
3.5
Programmausführung manipulieren
Wie bereits angesprochen, kann die Ausführung eines Programms mit VMI manipuliert werden. Dies kann nötig sein, um das VMBR vor Entdeckung zu schützen. Bekanntlich ist die
i386-Architektur nicht voll virtualisierbar und es gibt Programme, die erkennen, ob sie in
einer virtuellen Maschine laufen oder nicht. Dazu zählt auch redpill [3]. Dieses Programm
führt die Instruktion sidt aus, welche die Adresse der Interruptdeskriptortabelle im Speicher
liefert. Läuft das Betriebssystem in einer virtuellen Maschine, so erhält man stattdessen die
Adresse der Interrupttabelle des VMBR. Da diese Instruktion im Usermode keinen Trap
auslöst, muss sie vom Rootkit emuliert werden, um nicht entdeckt zu werden. Dazu kann
per VMI ein Breakpoint an eine passende Stelle im exec-Systemaufruf des Kernels gesetzt
werden. Wird der Breakpoint erreicht prüft das VMBR ob redpill ausgeführt werden soll.
Dies kann z.B. geschehen, indem man im Textsegment nach der Instruktion sidt sucht. Wird
sie gefunden, überschreibt der VMBR die Instruktion mit einem Breakpoint und emuliert die
Instruktion sobald dieser erreicht wird. Für den Schutzmechanismus gegen redpill waren 104
zusätzliche Zeilen Code in Virtual PC nötig. Die Gegenmaßnahme des Rootkits hat jedoch
ihre Grenzen bei sich selbst modifizierenden Programmen, die die sidt-Instruktion erst zur
Laufzeit erzeugen und dann ausführen.
4
Kontrolle behalten
Die Gefahr entdeckt zu werden, ist für das Rootkit am größten, wenn es nicht läuft, da es dann
keinerlei Kontrolle über das System besitzt. Startet man den Rechner von einem alternativen
4
Bootmedium, z.B. einer Live-CD, so kann mit der darauf befindlichen Software gezielt nach
dem Rootkit auf der Festplatte gesucht werden. Damit das VMBR möglichst lange ohne
Unterbrechung läuft, ist die Anzahl an Rechnerneustarts zu minimieren. Startet der Benutzer
das Betriebssystem neu, so führt das Rootkit einfach nur einen Reset der virtuellen Hardware
durch und simuliert einen Neustart. Soll der Rechner aber heruntergefahren werden, dann
versetzt das VMBR das System in den Energiesparmodus. Dadurch schalten Lüfter, Monitor
sowie die Festplatten ab und für den unaufmerksamen Nutzer sieht es so aus, als ob das
System tatsächlich nicht mehr läuft. Dies setzt allerdings voraus, dass der Computer mit
ACPI ausgestattet ist.
5
Ressourcenverbrauch
Der Ressourcenverbrauch wurde mit zwei verschiedenen Systemen ermittelt. Linux-SubVirt
wurde auf einen 2.8 GHz Pentium 4 mit 1 GB RAM und RedHat Enterprise Linux 4 getestet.
Das Rootkit benötigt komprimiert 95 MB auf der Festplatte, unkomprimiert 228 MB. Mit
speziell angepassten Linuxdistributionen wären aber noch kleinere Plattenimages möglich.
SubVirt für Windows kam auf einem 1 GHz Pentium 4 mit 256 MB RAM und Windows XP
zum Einsatz. Hier sind 106 MB komprimierter bzw. 251 MB unkomprimierter Plattenplatz
nötig. Beide Rootkits beanspruchen in etwa 3% des Arbeitsspeichers. Sowohl der Start als
auch der Betrieb der VMM und der Malware verbrauchen zusätzliche CPU-Zeit. Die Zeiten
werden in folgender Tabelle illustriert. Die angegebenen Werte sind der Durchschnitt von
jeweils drei Läufen.
Installation
Hochfahren ohne VMBR
Neustart im VMBR
Hochfahren im VMBR
Start des Hosts
Start von Host und Gast
VMWare VMBR
24s
53s
74s
96s
52s
145s
Virtual PC VMBR
262s
23s
54s
nicht implementiert
45s
101s
Wie sind die Zeiten zu interpretieren? Zunächst lässt sich feststellen, dass die Installation des
Virtual PC VMBR sehr viel länger dauert als die der VMWare-Version. Der Grund ist die
langsamere Hardware und die geringere Speicherausstattung des Windows-PCs. Zusätzlich
wird das VMBR an den Anfang der Windows-Partition installiert, so dass dort vorhandene
Dateiblöcke zuerst umkopiert werden müssen. In der Linux-Variante wird das Rootkit einfach
in die Swappartition geschrieben. Die nächste Zeile gibt an, wie lange es vom Zeitpunkt des
Einschaltens dauert, bis man sich auf dem System einloggen kann, wenn der Rechner noch
nicht mit dem VMBR infiziert ist. Neustart im VMBR“ und Hochfahren im VMBR“ gibt
”
”
die Dauer des simulierten Neustarts bzw. des kompletten Hochfahrens an. Letzteres wurde
nur in der Linux-Version von SubVirt implementiert. Die längere Zeitdauer für das simulierte
Hochfahren gegenüber des Neustarts lässt sich dadurch erklären, dass die Hardware nach dem
Verlassen des Energiesparmodus neu initialisiert werden muss. Sollte der Rechner komplett
abgeschaltet werden, so dass ein simuliertes Hochfahren nicht möglich ist, dann dauert es in
der Linux-Variante 52 Sekunden, das VMBR zu starten und weitere 93 Sekunden und damit
insgesamt 145 Sekunden das Betriebssystem zu starten. Dass der Start von Host und Gast
in der Windows-Version dagegen nur 101 Sekunden beansprucht, führen die Autoren darauf
zurück, dass gewisse Performanceoptimierungen in VMWare erst nach einiger Zeit zu wirken
5
beginnen.
6
VMBRs erkennen
Es gibt zwei grundsätzliche Möglichkeiten, ein VMBR zu erkennen. Man kann versuchen,
Kontrolle über eine Schicht des Systems zu erlangen, die unterhalb der vom Rootkits gesteuerten Ebene liegt. Damit liegt die Kontrolle über das Gesamtsystem nicht mehr beim
Rootkit. Aber auch eine Erkennung vom Gast heraus ist durchaus realisierbar.
6.1
Erkennung durch Software unterhalb des VMBR
Wie bereits angesprochen, lässt sich der Start des VMBR durch Booten von einem alternativen Medium verhindern und dann das Rootkit auf der Platte suchen. Allerdings sollte vor
dem Hochfahren der Netzstecker gezogen werden, um sicherzustellen, dass sich der Rechner
nicht im Energiesparmodus befunden hat und der Bootvorgang vom VMBR nur simuliert
wird. Zusätzlich setzt diese Vorgehensweise einen sicheren Bootvorgang voraus, das BIOS
darf also nicht vom VMBR manipuliert worden sein.
Eine weitere denkbare Alternative ist, das Betriebssystem bereits in einer virtuellen Maschine
laufen zu lassen. Will sich dann ein Rootkit unterhalb des Betriebssystems einnisten, so wird
dies die virtuelle Maschine spätestens dann feststellen, wenn der auf der virtuellen Festplatte
befindliche Bootcode verändert wird. Allerdings werden dann alle Erkennungsstrategien, die
feststellen, ob ein Betriebssystem in einer virtuellen Maschine läuft, hinfällig.
6.2
Erkennung durch Software oberhalb des VMBR
Viele Ansätze, mit denen sich ein VMBR vom laufenden Betriebssystem heraus erkennen
lässt, basieren auf der Beobachtung, dass das Rootkit selbst Ressourcen verbraucht. Dazu
zählen CPU-Zeit, Arbeitsspeicher und Festplattenplatz. Eine einfache Erkennungsmethode
besteht darin, ein Programm zu schreiben, das z.B. die sidt-Instruktion sehr oft aufruft. Dann
startet man das Programm auf dem Rechner, auf dem man das VMBR vermutet und auf
einem identischen aber garantiert uninfizierten System. Weil das VMBR die sidt-Instruktion
emulieren muss, um nicht entdeckt zu werden, wird man einen Unterschied in den Laufzeiten
der Programme feststellen. Da das VMBR die Systemuhr zur Tarnung langsamer laufen
lassen könnte, ist es empfehlenswert, die Laufzeiten mit einer Stoppuhr zu messen.
Es ist ebenfalls vorstellbar, ein Programm den auf dem uninfizierten Rechner kompletten zur
Verfügung stehenden Arbeitsspeicher reservieren zu lassen. Bei gleichen Anfangsbedingungen
wird die Speicheranforderung auf dem System mit Rootkit fehlschlagen, da dieses natürlich
auch RAM benötigt. Allerdings kann das VMBR hier Gegenmaßnahmen treffen, indem es
den Mangel an RAM durch Paging auszugleichen versucht. Natürlich wird sich dies negativ
auf die Laufzeit derjenigen Programme auswirken, deren Daten erst von der Platte gelesen
werden müssen. Jedoch belegt SubVirt nur etwa 3% des Arbeitsspeichers, so dass Paging
relativ selten stattfinden wird. Damit werden Laufzeitunterschiede kaum messbar sein, vor
allem, wenn diese mit der Stoppuhr ermittelt werden sollen.
Nun ließe sich das Paging bzw. das installierte Rootkit selbst analog zur Methode der dynamischen Speicherallokation entdecken, indem man die Festplatte mit Daten voll schreibt und
so testet, wie viel Platz auf der Platte frei war. Es wird sich wieder herausstellen, dass sich
auf das uninfizierte System mehr Daten schreiben lassen. Um auch hier das Entdeckungsrisiko zu minimieren, komprimiert die Windows-Version von SubVirt Plattenblöcke, um mehr
6
Speicher vorzutäuschen als eigentlich vorhanden ist. Weiterhin kann das Rootkit Teile der virtuellen Festplatte für das Gastsystem als beschädigt markieren, womit sich für den Benutzer
der fehlende Plattenplatz erklärt. Hierzu werden Schreibvorgänge an bestimmte Blöcke der
(virtuellen) Festplatte einfach verworfen, Leseanforderungen liefern zufällige Daten zurück.
Ferner kann auch der nur schwer zu virtualisierende I/O dazu dienen, ein VMBR aufzudecken. SubVirt lässt das Gastsystem aus Effizienzgründen auf virtueller Hardware mit speziellen Treibern laufen und emuliert nicht die richtige im Rechner vorhandene Peripherie. Man
würde das Rootkit also schon entdecken, wenn man sich die installierten Geräte anzeigen
lässt, die dann nicht mit der Ausstattung des Rechners übereinstimmen. Zusätzlich werden
3D-Spiele langsamer als vorher laufen, wenn sie nur Zugriff auf eine virtuelle Grafikkarte
haben. Um nicht aufzufallen, muss also die vorhandene Hardware perfekt und mit so wenig
Leistungsverlusten wie möglich virtualisiert werden. Dies ist praktisch unmöglich zu realisieren, da dies für sämtliche Geräte geschehen müsste. Dazu sollten auch Bugs in der Hardware
oder von der Spezifikation abweichendes Verhalten exakt nachgebildet werden, da man ansonsten anhand dieser Fehler überprüfen könnte, ob das Betriebssystem in einer virtuellen
Maschine läuft oder nicht. Deshalb schlagen die Autoren von SubVirt vor, nur Hardware
zu virtualisieren, die zur Informationsgewinnung gebraucht wird (z.B. die Tastatur, wenn
ein Keylogger zum Einsatz kommen soll) und ansonsten dem Gast direkten Zugriff auf die
restlichen Geräte zu erlauben, solange diese nicht DMA-fähig sind. Denn dann ließen sich
wiederum beliebige Speicherbereiche auslesen und damit das Rootkit ausfindig machen. Davor kann sich das VMBR erst schützen, wenn eine IOMMU zur Verfügung steht, um Geräten
den Zugriff auf die physikalischen Seiten, in denen das Rootkit liegt, zu verweigern, bzw. bei
einem Zugriffsfehler falsche oder zufällige Daten zurückliefern zu können.
7
Zusammenfassung
Mit SubVirt wurden zwei VMBRs entwickelt, die die Gefahren zukünftiger Rootkits aufzeigen
sollen, und um rechtzeitig Verteidigungsstrategien zu ergründen. Diese sind vielfältig, können
aber mit genügend hohen Aufwand wiederum umgangen werden. Tatsächlich arbeitete einer
der Autoren versehentlich an einer der infizierten Testmaschinen ohne Notiz vom VMBR zu
nehmen. Es ist zu erwarten, dass mit der zunehmenden Effizienzsteigerung virtueller Maschinen VMBRs immer unauffälliger werden.
Literatur
[1] Tal Garfinkel and Mendel Rosenblum. A Virtual Machine Introspection Based Architecture for Intrusion Dectection. 10th ISOC Symposium on Network and Distributed Systems
Security (SNDSS), Februar 2003.
[2] Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Varbowski, Helen J. Wang, and
Jacob R. Lorch. SubVirt: Implementing malware with virtual machines. 2006.
[3] Joanna Rutkowska. Red Pill... or how to detect VMM using (almost) one CPU instruction.
http://invisiblethings.org/papers/redpill.html, 2004.
7