Rootkits gehören zum Standard-Repertoire der Cracker. Die Tools in diesen Sammlungen verschleiern die Aktivitäten des Einbrechers und tarnen seine Hinterlassenschaften. Durch Hintertüren kann der Angreifer jederzeit wieder in Ihren Rechner eindringen. Wir zeigen, wie Sie Licht ins Dunkel bringen.

Sie sind eines der beliebtesten Hilfsmittel der Cracker und Skript-Kiddies: Rootkits, die als Sammlung einzelner Tools das Handwerk der Angreifer vereinfachen. Ihr Einsatz folgt aber erst nach einem geglückten Einbruch. Sie sorgen zum Beispiel dafür, dass der Eindringling auch später wieder Root-Status auf dem System erhält, indem sie Hintertüren (Backdoors) installieren. Sie verschleiern die Präsenz des Crackers, so dass der Admin gar nicht bemerkt, dass ein unerwünschter Gast seine Maschine steuert. Und sie verwischen auch die Spuren, die beim Knacken des Rechners angefallen sind.

Zusätzlich sammeln viele Rootkits weitere Informationen über den Rechner und seine Umgebung, beispielsweise die Passwörter des lokalen Rechners oder interessante Daten, die sie mit einem Sniffer aus dem Netzwerkverkehr filtern. Mit diesem neuen Wissen wird es für den Eindringling leichter, benachbarte Rechner zu übernehmen.

In der Regel sind Rootkits als Trojanische Pferde realisiert. Es handelt sich dabei um gepatchte Systemprogramme, die sich entsprechend den Wünschen des Crackers verhalten. Es gibt aber auch Rootkits, deren Hauptteil ein Kernelmodul ist[1]. Diese benötigen keine Trägerprogramme mehr, sie können dennoch alle Vorgänge beliebig kontrollieren.

Vertrauen ist nicht immer gut

Rootkits mit gepatchten Programmen gehen davon aus, dass der Superuser den Ausgaben der Programme vertraut. Diese Annahme trifft meist zu, in der Regel bleibt dem Admin keine andere Wahl. Wichtige Systemtools modifiziert das Rootkit so, dass sie keine Informationen mehr ausgeben, die einen Eindringling verraten könnten. Beispielsweise zeigt das »ps«-Kommando aus einem Rootkit einige Prozesse nicht an oder »ls« verschweigt in seinen Ausgaben einige Verzeichnisse und Dateien.

Normalerweise würde eine solche Manipulation kaum auffallen – außer durch eine Überprüfung mit anderen Tools. Die Auflistung von »ls« könnte man zum Beispiel mit der Ausgabe eines »find«-Aufrufs vergleichen. Das führt aber nur dann zum Erfolg, wenn der Angreifer nicht auch Find durch eine gepatchte Version ersetzt hat.

Bei einem Rootkit mit eigenem Kernelmodul stellt sich die Sache etwas anders dar. Im Normalfall besteht ein solches Kit nur aus dem entsprechenden Modul und aus Werkzeugen, die Einbruchsspuren beseitigen sollen. Aufgaben wie das Verstecken von Dateien und Benutzern oder das Einfügen von Hintertüren erledigen diese Module in den meisten Fällen bereits im Kernel und treffen damit alle Programme.

Einbruch ins System

Bevor der Angreifer sein Lieblings-Rootkit installieren kann, muss er sich Root-Rechte verschaffen. Der dazu nötige Einbruch läuft meist nach einem festen Schema ab. Wenn er ein System gezielt angreift, versucht der Cracker in der Regel zuerst, möglichst viele Informationen über sein Ziel zu sammeln. Er sucht nach offenen Schwachstellen und nutzt sie dann aus. Auch die wahllose Suche nach einem beliebigen Opfer ist weit verbreitet, unterstützt durch Network Scanner, die teilweise auch den Einbruch automatisieren.

Im Zielrechner angekommen beseitigt der Eindringling die Spuren, die er beim Einbruch hinterlassen hat. Dazu entfernt er Log-Einträge und andere Spuren, die auf ihn hinweisen könnten. Den Großteil dieser Prozedur erledigen Programme wie etwa Zap, die alle Einträge in den Log-Files »utmp«, »wtmp«, »lastlog« und »messages« entfernen. Andere Tools säubern weitere Dateien in »/var/adm« und »/var/log«.

Im Normalfall beschränken sich die Säuberungsaktionen auf die Standarddateien, da ein manuelles Beseitigen der Spuren sehr viel Zeit kostet. Das kann dazu führen, dass der Cracker einige Log-Files übersieht und der Admin den Einbruch doch entdecken kann. Ein besonderer Fall ist das Remote Logging, bei dem Syslog seine Einträge laufend an einen anderen Rechner weitergibt. So lange der Angreifer den Log-Host noch nicht geknackt hat, kann er dessen Files auch nicht säubern.

Einmal im Zielsystem angekommen, installiert der Cracker die vom Rootkit mitgelieferten Hintertüren und sonstigen Programme. Das Rootkit überträgt er meist schon, bevor er seine Spuren verwischt, da die Übertragung neue Spuren verursacht. Als Quelle für die Tools dienen meist öffentliche Server, nicht direkt der Rechner des Angreifers.

Lokale Hintertüren

Die Hintertüren lassen sich in zwei Varianten unterteilen: lokale Backdoors und Netzwerk-Hintertüren. Durch eine lokale Hintertür kann ein vorhandener lokaler User-Account Root-Rechte erlangen. Der Cracker loggt sich dann als normaler User in das System ein und führt ein Programm aus, das ihm eine Root-Shell gibt. Die Hintertür wird meist durch ein Passwort geschützt, so dass sie kein anderer User nutzen kann.

Geeignete Wirtsprogramme für Backdoors sind Login, Chsh, Passwd oder ein beliebiges anderes Programm mit SUID-Root-Rechten. Die Funktionsweise (ohne Wirt) illustriert Listing 1: Das Programm muss der Benutzer nur starten – und schon ist er Root. Die Datei gibt sich sogar selbst SUID-Root-Rechte, wenn sie von Root gestartet wird. Abbildung 1 zeigt die Auswirkung. Übrigens enthält dieses einfache Beispiel einen Buffer-Overflow-Fehler, der für diesen Zweck aber nicht weiter stört.

Der zweiten Teil dieses Beispiels, also User- und Group-ID auf »0« setzen und eine Shell starten, findet sich so ähnlich auch in den Programmpatches der Rootkits wieder, eventuell verlangen diese vorher noch ein eigenes Passwort. Besonders interessant für diese Veränderungen sind Programme, die bereits ähnliche Funktionen liefern, zum Beispiel »su« oder »login«. Dort sind die Änderungen weitaus schwieriger zu finden als in anderen Programmen.

01 #include <stdio.h>
02 #include <unistd.h>
03 #include <stdlib.h>
04 
05 int main(int argc, char *argv[])
06 {
07   char buf[40];
08 
09   /* Führt Root das Programm aus? */
10   if (getuid () == 0)
11   {
12     /* Setze den Dateieigentümer auf "root" */
13     printf ("Setze Dateieigentümer auf Root.n");
14     sprintf (buf, "chown root %s", argv[0]);
15     system (buf);
16 
17     /* Setze das SUID-Flag */
18     printf ("Setze SUID-Flag.n");<c>19     sprintf (buf, "chmod +s %s", argv[0]);
20     system (buf);
21   }
22 
23   /* Normaler Benutzer führt das Programm aus */
24   else
25   {
26     /* Setze UID und GID auf 0 (root) */
27     if ((setuid (0) != 0) || (setgid (0) != 0))
28     {
29       printf ("Datei ist nicht SUID-Root.n");
30       return -1;
31     }
32     printf ("Öffne eine Root-Shell.n");
33     execl ("/bin/sh", "sh", 0);
34   }
35   return 0;
36 }

Abbildung 1: Die in Listing 1 angegebene lokale Hintertür gibt sich selbst SUID-Root-Rechte, wenn sie von Root gestartet wird. Danach kann jeder normale Benutzer mit ihrer Hilfe zu Root werden.

Netzwerk-Hintertüren

Die zweite Gruppe von Backdoors sind Netzwerk-Hintertüren. Durch sie kann der Cracker ein bereits geknacktes System jederzeit wieder über das Netzwerk betreten, ohne ein normales Benutzerkonto zu besitzen. Auch hier gibt es eigenständige Hintertüren und solche, die sich in normalen Diensten verstecken. Gepatchte Versionen gibt es von fast allen Internet-Daemons, die über Root-Rechte verfügen oder diese erlangen können. Dazu gehören beispielsweise »inetd« und »sshd«.

Will der Angreifer seine Hintertür nutzen, verlangt auch die Netzwerk-Variante meist ein Passwort. Bei gut versteckten Hintertüren ist dieses Passwort an einer Stelle einzugeben, an der normalerweise andere Daten erwartet würden. Wurde der Cracker von seiner eigenen Tür erkannt, bindet diese eine Shell an den Port oder führt die übergebenen Kommandos aus und überträgt die Ausgabe zurück.

Die eigenständigen Netzwerk-Hintertüren gibt es in vielen Varianten, Unterschiede liegen meist in der Art der Implementierung oder in den benutzen kryptographische Verfahren. Die meisten dieser Backdoors bieten zumindest eine einfache Verschlüsselung an, um die übertragenen Daten vor Sniffern und damit vor den Augen des Admins zu schützen. Das bietet dem Cracker einen weiteren Schutz und erschwert es, seine Aktionen nachzuvollziehen.

Netzwerk-Sniffer

Der Ethernet-Sniffer bildet bei vielen Rootkits einen wichtigen Bestandteil, durch ihn kann der Cracker wichtige Informationen aus dem Netzwerkverkehr herausfiltern und speichern. Dadurch kann er meist weitere Systeme im Netz knacken oder er erfährt Firmeninterna und vertrauliche Informationen.

Der Sniffer besteht in der Regel aus einem eigenständigen Programm, das aber durch diverse manipulierte Programme noch geschützt werden muss. Daher bieten solche Rootkits, die einen Sniffer enthalten, gepatchte Versionen von »ifconfig«, »netstat« und ähnlichen Werkzeugen an, so dass diese sonst so verlässlichen Hilfsmittel den Sniffer nicht mehr finden können.

Trotz aller Schutzvorkehrungen gibt es viele sehr unterschiedliche Methoden, um Rootkits auf einem System aufzuspüren. Die meisten aktuell kursierenden Rootkits lassen sich mit einigen Tricks noch recht gut aufspüren und erfolgreich vom System verbannen.

Vorsorge ist der beste Schutz

Im Idealfall hat ein Admin schon vor dem Verdacht eines Einbruchs vorsorglich Maßnahmen getroffen, um Rootkits zu finden. Auf jeden Fall benötigt er die wichtigsten Systemprogramme auf einem schreibgeschützten Medium. Diese Programme dürfen selbstverständlich in keiner Weise manipuliert sein, sie müssen auch unabhängig von allen Dateien auf dem Rechner sein. Daher sind sie am besten statisch gelinkt, die Manipulation kann schließlich auch in den Shared Libraries stecken.

Gegen eine Manipulation im Kernel sind diese Tools aber machtlos. Hier hilft nur, das System von einem sicheren Medium zu starten (Bootdiskette mit Diskettenbetriebssystem oder Live-CD), die Festplatte Read-only zu mounten und dann das System zu untersuchen.

Ein wichtiges Hilfsmittel im Kampf gegen Rootkits sind Prüfsummen. Sie können feststellen, ob Dateien verändert wurden. Einfache CRC-Summen sind allerdings nicht geeignet, da einige Tools dafür sorgen, dass die gepatchte Datei dieselbe CRC-Summe hat wie das Original. Die Checksummen müssen vor der Manipulationen erstellt werden, am besten direkt nach der Installation des Systems. Diese Listen sollte man auf einem schreibgeschützten Medium speichern, um zu verhindern, dass sie ein Angreifer manipuliert.

Mit einer solchen Liste bewaffnet kann der Admin seine Programme regelmäßig überprüfen. Über einen Cron-Job kann er diesen Test auch völlig automatisieren – vorausgesetzt ein Angreifer kann die MD5-Liste nicht ändern, er durchsucht die Cron-Dateien nicht nach entsprechenden Aufträgen und modifiziert weder »md5sum« noch den Kernel.

Abbildung 2: Das Programm »md5sum« vergleicht die aktuelle MD5-Prüfsumme mit den gespeicherten Werten: Zehn Dateien wurden hier modifiziert. Mit »strings« lässt sich feststellen, dass es sich um das Ambient’s Rootkit (ark) handelt.

Rootkits finden

An Stelle des einfachen »md5sum« wären auch komplexere Tools wie Tripwire oder Aide geeignet. In vielen Fällen genügt das einfache Programm aber völlig. Wichtig ist vor allem, die Dateien ausreichend häufig zu sichern und zu überprüfen und dabei keine Programme zu übersehen.

Auch wenn keine Backups und keine Prüfsummen vorhanden sind, ist noch nicht alles verloren. Es gibt immer noch einige Möglichkeiten, um Rootkits zu finden. Eine verräterische Spur vieler Cracker-Tools rührt daher, dass sie ein eigenes Unterverzeichnis oder eine eigene Konfigurationsdatei benötigen. Diese Daten schreiben viele Rootkits in »/dev«, in der Hoffnung, dass dort niemand sucht. Gewöhnlich enthält dieses Verzeichnis aber keine normalen Dateien, sondern nur Device-Files. Ein einfacher Find-Aufruf genügt, um diese Hinterlassenschaften aufzuspüren (siehe Abbildung 3):

find /dev -type f

Die gepatchten Programme versuchen ihre Konfig-Files zu öffnen. In der Folge ist der String »/dev« auch in vielen modifizierten Dateien enthalten. Auch dort ist er mit Hilfe des »strings«-Befehls einfach zu finden:

strings patchted-file | grep /dev

Eine etwas kompliziertere Möglichkeit, ein Rootkit zu finden, ist der System-Call-Trace. Mit Hilfe von »strace« lassen sich alle Systemaufrufe eines Programms verfolgen. Die Ausgabe kann allerdings sehr umfangreich sein, ist dafür aber auch sehr aufschlussreich. Will ein Rootkit eine seiner Konfigurationsdateien öffnen, so geschieht dies über einen entsprechenden Sys-Call.

Abbildung 3: Telekit [3] versteckt seine Konfigurationsdateien in »/dev«. Ein einfacher Find-Aufruf genügt, um sie dort aufzuspüren.

»/proc« ist Admins Freund

Auf der Suche nach Rootkits ist das »/proc«-Verzeichnis eines der interessantesten Hilfsmittel. Hier sind viele wichtige Systeminformationen zu finden, die ein Rootkit eigentlich verstecken will. Das wissen zwar auch die Programmierer der Cracker-Tools und manche Rootkits verbergen Informationen in »/proc«, dennoch lohnt sich ein Blick in dieses Verzeichnis fast immer.

In »/proc« sind unter anderem alle laufenden Prozesse mit ihrer Prozess-ID aufgelistet. Wenn »ls« und »find« nicht so manipuliert sind, dass sie auch einige dieser Dateien verstecken, kann ein Vergleichen der »/proc«-Informationen mit der Ausgabe von »ps« bereits ein Rootkit aufdecken. Bei versteckten Prozessen lohnt sich ein Blick in »/proc/ PID/stat« oder in die deutlich leichter verständliche »/proc/ PID/status«: Wenn dort ein Prozess auftaucht, der mit den normalen Tools nicht zu sehen ist, deutet das auf ein Rootkit hin. Es kann aber auch vorkommen, dass »ps« und »top« unverändert sind, aber in »/proc« nicht alle Prozesse auftauchen.

Informativ sind auch die Einträge mit Netzwerkinformationen. Am wichtigsten ist es, die offenen Ports zu prüfen und mit den Ausgaben von Netstat oder einem ähnlichen Tool zu vergleichen. Dazu gibt es den Ordner »/proc/net« mit Dateien, die für jedes Protokoll die offenen Sockets enthalten.

Aufschlussreich kann auch ein Portscan des eigenen Rechners sein, ausgehend von einem sicheren Rechner über das Netz gestartet. Sollten dabei offene Ports vorkommen, die Netstat nicht anzeigt, ist das ein recht eindeutiger Hinweis auf ein Rootkit. Unerwartet geöffnete Ports sollten beim Admin sowieso alle Alarmglocken schrillen lassen.

Rootkit gefunden: Was nun?

Sollte bei der Suche tatsächlich ein Rootkit zum Vorschein kommen, gilt es zunächst, das System vom Netzwerk zu trennen. Dadurch wird es möglich, den Rechner in Ruhe zu untersuchen und zu säubern. Bei der Analyse ist es nicht nur wichtig zu entdecken, wer den Einbruch begangen hat. Entscheidend ist vielmehr zu wissen, wie der Cracker Zugang zum System erhalten und welche Schwachstelle er dafür genutzt hat. Dabei spielen die Logdateien wieder eine entscheidende Rolle.

Eine wichtige Frage ist, ob man das System völlig neu installiert oder ob es ausreicht, nur die modifizierten Programme und die Hintertüren zu entfernen. Die Antwort darauf ist nicht leicht. Sie richtet sich unter anderem danach, wie viel der Admin über den Einbruch herausfindet und ob er wirklich alle Aktionen des Crackers nachvollziehen kann. Sonst könnte es sein, dass er eine Hintertür übersieht und der Einbrecher erneut eindringt, wenn der Rechner wieder am Netz hängt. Damit wäre aus Sicht des Admins nichts gewonnen.

Der Täter kehrt zum Tatort zurück

Die Erfahrung, dass viele Cracker ihre Tatorte gern erneut aufsuchen, kann man auch für Abwehrzwecke nutzen. Vorausgesetzt er kennt alle Zugänge des Crackers, nicht jedoch seine Identität, kann ein Admin seinen Widersacher auch in eine Falle tappen lassen. In einem so genannten Honeypot[5] beobachtet er alle Aktionen des Angreifers, verfolgt ihn und studiert sein Verhalten. Aus solchen Studien lassen sich Rückschlüsse auf das Motiv des Crackers ziehen und sein weiteres Verhalten besser einschätzen.

Sollte er diesen Rechner nur zufällig gefunden und geknackt haben, ist es recht unwahrscheinlich, dass er ihn erneut behelligt. Er muss schließlich davon ausgehen, dass der Admin jetzt die Lücken gestopft hat und besonders aufmerksam seine Log-Files liest. War der Eindringling aber auf der Suche nach internen Informationen oder hat er andere Motive, in genau diesen Host einzubrechen, dann droht vermutlich weiterhin Gefahr von seiner Seite. (fjl)