Heimliche Hintertüren
Seite 2: Ausgetauscht
Ausgetauscht
Auch wenn moderne Varianten meist eine Mischung aus verschiedenen Typen darstellen, lassen sich Rootkits grob betrachtet in datei- und kernelbasierte Arten unterteilen. Vereinfacht dargestellt tauschen dateibasierte Rootkits auf der Festplatte Systembefehle aus und ersetzen diese durch eigene, trojanisierte Versionen. Diese sind dann so modifiziert, dass zum Beispiel ein ssh-Dienst einen privilegierten Login mit einem bestimmten Passwort bereitstellt. Ein neues ps-Kommando beziehungsweise der Windows-Task-Manager zeigt bestimmte Prozesse und der Befehl netstat ausgewälte Netzwerkverbindungen nicht mehr an. Ähnliches gilt für ls, dir oder den Explorer, in deren Ausgabe verdächtige Dateien nicht mehr auftauchen. Das Verstecken von Prozessen und Dateien wird normalerweise so realisiert, dass der modifizierte Systembefehl keine Objekte anzeigt, die eine vorher definierte Zeichenkette enthalten.
Eine modernere und zugleich effektivere Unterart der dateibasierten Rootkits sind die Library Rootkits. Hier wird nicht jeder einzelne Systembefehl verändert, sondern direkt die Bibliothek, die eine Funktion zur Verfügung stellt und mit der die Systemprogramme dynamisch verlinkt sind. Das recht verbreitete t0rn Rootkit für Linux/Unix ist ein bekanntes Beispiel hierfür. Es tauscht unter anderem die Systembibliothek libproc.so aus, die Funktionen bereitstellt, über die Programme Prozessinformationen über das /proc-Dateisystem auslesen können. So zeigt selbst ein "sauberes" ps bestimmte Prozesse nicht mehr an, da es die Informationen erst gar nicht bekommt. Schaut man direkt im /proc-Dateisystem nach, findet man natürlich alle Angaben zu den versteckten Prozessen.
Schwachstelle Kernel
Bei den meisten Betriebssystemen kann der Systemadministrator zur Laufzeit neue Features und Gerätetreiber einbinden. Entsprechend konfiguriert erledigt das der Kernel sogar automatisch. Auf diesem Weg kann ein Einbrecher auch kernelbasierte Rootkits in den Speicher laden. Dort modifizieren sie bestimmte Systemaufrufe und können damit die Weitergabe von Informationen aus dem Betriebssystemkern an User-Programme kontrollieren. Genau genommen modifizieren sie dazu nicht die Systemfunktion selbst, sondern verbiegen die Einträge der internen Kerneltabellen so, dass anstelle der richtigen Funktion zunächst der Wrapper des Rootkits aufgerufen wird. Dieser ruft dann die Kernel-Routine auf, zensiert deren Rückgabe und liefert nur die ihm genehmen Daten an das Programm zurück.
Anders als bei dateibasierten Rootkits, die komplett im User-Modus laufen, haben Programme wie Virenscanner kaum noch eine Chance, Kernel-Rootkits in der Registry, im Hauptspeicher und in Dateien auf der Festplatte aufzuspüren, da diese den Scannern die notwendigen Informationen einfach vorenthalten können.
Bei einigen Betriebssystemen kann man das Laden von Modulen zur Laufzeit verhindern. Unter Linux besteht zum Beispiel die Möglichkeit, die benötigten Treiber fest in den Kernel einzucompilieren und das Nachladen von Modulen zu deaktivieren. Doch auch das bietet letztlich keinen absoluten Schutz vor Kernel-Rootkits, denn moderne Exemplare modifizieren den Kernel direkt im Hauptspeicher. SucKIT beispielsweise nutzt das Speicherabbild des Linux-Kernels in /dev/kmem, um dort den Zeiger auf die so genannte Syscall-Tabelle auf eine eigene, modifizierte Version zu verbiegen. Über diese springen Systemaufrufe zunächst eine Funktion des Rootkits an. Das funktioniert auch bei vollständig monolithischen Kernels. Die eigentliche Herausforderung dabei ist es, sich im Kernelspace Speicher zu reservieren und die Tabellen und Funktionen dort zu platzieren.
