SubVirt. Stefan Kempf. 11. Oktober 2007

Transkript

1 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 Einführung und Motivation 1.1 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

2 Anwendung Anwendung Malware Malware 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

3 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

4 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

5 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. VMWare VMBR Virtual PC VMBR Installation 24s 262s Hochfahren ohne VMBR 53s 23s Neustart im VMBR 74s 54s Hochfahren im VMBR 96s nicht implementiert Start des Hosts 52s 45s Start von Host und Gast 145s 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

6 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

7 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 [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 [3] Joanna Rutkowska. Red Pill... or how to detect VMM using (almost) one CPU instruction