zurück zum Artikel

Die meisten Cracker verschleiern ihre Aktivitäten mit Hilfe so genannter Rootkits. Um Eindringlinge trotzdem aufzuspüren und und den Server wieder zu säubern, müssen auch Adminstratoren wissen, womit sie es da zu tun haben.

Ein Einbruch in ein Computersystem verläuft typischerweise in drei Stufen ab: Zunächst analysiert der Angreifer sein Ziel und versucht, Schwachstellen zu identifizieren. Dann erfolgt der eigentliche Einbruch mit Hilfe eines passenden Exploits -- einem Programm oder Skript, das einen Programmfehler oder eine Fehlkonfiguration ausnutzt und dem Einbrecher Zugang zum System verschafft. Unter Umständen muss er sich über eine weitere, lokale Schwachstelle dann noch Administratorrechte verschaffen. Im letzten Schritt verwischt er die Spuren und richtet sich einen permanenten Zugang zum System ein.

Prinzipiell könnte der Cracker natürlich immer wieder dieselbe Lücke benutzen. Doch zum einen hinterlassen die meisten Exploits auffällige Spuren in Log-Dateien, die jedesmal mühselig zu tilgen wären. Zum anderen muss der Cracker damit rechnen, dass der rechtmäßige Administrator das Loch irgendwann schließt und ihn damit aussperrt. Da die meisten Einbrüche über Standard-Exploits erfolgen, die auch anderen bekannt sind, hätte der Cracker den Rechner auch sicher nicht lange für sich allein. Im für ihn schlimmsten Fall wirft ihn sogar ein Konkurrent wieder aus dem System. Um das zu vermeiden, schließen sogar manche Einbrecher die ihnen bekannten Sicherheitslöcher des einmal eroberten Systems.

Ein Rootkit zu installieren, ist das Mittel, um eine private Hintertür einzurichten. Außerdem verbirgt es auch gleich deren Existenz und die Aktivitäten des Einbrechers vor dem rechtmäßigen Eigentümer. In vielen Fällen enthalten die Rootkits auch gleich Netzwerk-Sniffer und Tastatur-Logger, um Passwörter auszuspähen sowie Tools um andere Systeme zu scannen und anzugreifen.

Während unter Unix und Linux schon seit Jahren leistungsfähige Rootkits bekannt sind, waren ähnliche Programme für Windows bis vor kurzem eher einfach gestrickt und leicht aufzuspüren. So kommt es, dass bis heute viele Systemverantwortliche Windows-Rootkits als minder gefährlich ansehen -- obwohl der Sicherheitsexperte Greg Hoglund bereits 1999 auf deren Potenzial hingewiesen hat [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.

Der Ring der Macht

Der Ring der Macht

Unter Windows kommen als Hintertüren oft Backdoor-Programme wie NetBus, SubSeven und Back Orifice 2000 als Rootkit zum Einsatz. Sie arbeiten nach dem Prinzip von Fernwartungsprogrammen wie PCAnywhere und erlauben die vollständige Kontrolle eines Windows-Rechners über das Netz. Mit einem Viren-Scanner lassen sich solche Backdoors vergleichsweise einfach aufspüren.

Ein Kernel-Rootkit für Windows NT und dessen Nachfolger ist nicht ganz einfach zu realisieren. Denn ein normaler User-Prozess -- auch wenn er mit Administratorrechten läuft -- kann nicht einfach Modifikationen am Kernel vornehmen. Intels x86-CPUs unterstützen vier verschiedene Betriebsmodi -- meist als Ring 0 bis 3 bezeichnet. Windows benutzt davon nur Ring 0, den Kernel-Modus mit vollem Zugriff auf den Speicher, und Ring 3, den User-Modus mit den geringsten Zugriffsrechten. Insbesondere haben Prozesse im Ring-3-Modus keinen Zugriff auf Speicherbereiche des Kernels, die mit Ring 0 markiert sind. Allerdings gibt es eine Reihe dokumentierter und undokumentierter Methoden, diese Einschränkung zu umgehen.

So hat Greg Hoglund als Machbarkeitsstudie das NT-Rootkit entwickelt [3]. Es enthält einen Gerätetreiber namens "_root_.sys" und eine ausführbare Datei namens "deploy.exe", die die Installation des Treibers erledigt. Hoglund umgeht dabei die Ring-0-Schutzmechanismen, indem er den so genannten Security Reference Monitor (SRM) außer Gefecht setzt, der für die Überwachung der Zugriffsrechte zuständig ist.

Die Befehle "net start _root_" und "net stop _root_" schalten das Rootkit ein und aus. Im aktiven Zustand versteckt es Objekte wie Dateien und Verzeichnisse, die mit der Zeichenfolge "_root_" beginnen, vor allen Programmen im User-Modus. Auch Prozesse und Registry-Einträge, die mit dieser speziellen Zeichenfolge beginnen, zeigt das System nicht mehr an. Das gilt auch für Benutzer mit Administratorrechten.

Als Hintertür installiert das Rootkit einen eigenen TCP/IP-Stack, der allerdings fest auf die IP-Adresse 10.0.0.166 konfiguriert ist. Sie ist weder lokal mittels netstat noch im Netzwerk über ping oder andere Befehle zu entdecken. Ein Angreifer erreicht auf allen Ports dieser Adresse einen einfachen Telnet-Server, dessen Netzwerkaktivitäten das Rootkit vor lokalen Prozessen vollständig verbirgt. Erst ein externer Port-Scan auf 10.0.0.166 zeigt alle Ports als offen an.

Schließlich demonstriert Hoglund, wie ein Kernel-Rootkit auch Viren-Scanner und Sicherheitsprogramme wie Tripwire täuschen kann, die kryptographische Hash-Werte der Programme speichern, um spätere Veränderungen aufzudecken. Dazu lädt das NT-Rootkit beim Ausführen eine andere Datei, als beim Lesen des Programmcodes. Hoglund hat dies exemplarisch für die Windows-Shell cmd.exe implementiert.

Um es auszuprobieren, kopiert man calc.exe auf C:\ und cmd.exe nach C:\_root_cmd.exe. Nach dem Start von _root_cmd.exe erscheint dann statt eines Kommandozeilenprompts der Taschenrechner auf dem Bildschirm. NT-Rootkit leitet den Aufruf einfach auf das Programm calc.exe um. Öffnet man allerdings _root_cmd.exe in einem Hex-Editor, so zeigt dieser das Original an -- also die unveränderte Datei _root_cmd.exe, die auch jeder Scanner als das Original identifizieren würde.

Rootkits In-The-Wild

Da es sich bei dem NT-Rootkit nur um eine Machbarkeitsstudie handelt, hat Hoglund die Funktionen absichtlich eingeschränkt, und auf viele bösartige Features typischer Rootkits verzichtete er ganz. Allerdings tauchen mittlerweile erste wirklich gefährliche Exemplare in freier Wildbahn auf.

Im Januar und Februar des Jahres 2003 breitete sich ein "Mini-Rootkit" aus, das inzwischen von Antivirenherstellern als "Slanret" und "Krei", beziehungsweise zusammen als "Backdoor-ALI" bezeichnet wird. Das Rootkit wurde hauptsächlich von Einbrechern auf Systemen installiert, in die sie durch eine Schwachstelle im Microsoft-SQL-Server eindringen konnten.

Die Slanret-Komponente ist eine 7 KByte große Datei namens "ierk8243.sys", die als Treiber zum Betriebssystemkern hinzugeladen wird. Über eine spezielle Schnittstelle können dann Programme privilegierten Zugriff auf das System erlangen. Sie können über diese Schnittstelle Dateien anlegen, Prozesse starten oder Registry-Einträge erstellen, die das System nicht anzeigt. Erst wenn man Slanret aus dem System entfernt, tauchen diese Objekt wieder auf.

Die 27-KByte-große Krei-Komponente besteht ebenfalls nur aus einer Datei. Sie heißt "ipsechlp.dll" und startet einen Dienst namens "IPSEC Helper Service" der auf Port 449 lauscht. Dieser Zugang fungiert als Backdoor, über die der Angreifer einen vollständigen Zugriff auf das System erlangen kann. Da Krei die von Slanret bereitgestellte Schnittstelle benutzt, ist es solange nicht zu entdecken, wie Slanret aktiv ist.

Erkenne den Feind

Erkenne den Feind

Wie man sich gegen Rootkits schützt, lässt sich in einem Satz zusammenfassen: Verhindern Sie, dass jemand unrechtmäßigen (Administrator-)Zugriff auf Ihre Server bekommt. In der ausführlichen Version kämen an dieser Stelle die üblichen Tipps wie: unnötige Dienste abschalten, die übrigen mit reduzierten Rechten laufen lassen, Sicherheits-Updates einspielen und so weiter.

Viele zusätzliche Schutzmaßnahmen lassen sich zwar mit Administratorrechten umgehen oder aushebeln, sie erhöhen jedoch den Aufwand für den Angreifer. Dazu gehört die Installation eines monolithischen Kernels, zu dem man keine Module nachladen kann. Des Weiteren verhindern Kernel Patches wie LIDS [4] unter Linux den schreibenden Zugriff auf den Hauptspeicher. Hier muss man allerdings den eigenen Aufwand gegen Nutzen abwägen, da bestimmte Programme, wie der X-Window-Server XFree86, diese Funktion benötigen.

Für Windows NT/2000 hat Pedestal Software mit dem Integrity Protection Driver (IPD) ein interessantes Konzept zum Schutz vor Rootkits vorgestellt. Der Open-Source-Gerätetreiber verhindert das Austauschen und Nachladen von Gerätetreibern. In der Registry kann man mit IPD keine Einträge mehr ändern oder hinzufügen [5].

Richtig knifflig wird es bei der Frage, wie man feststellt, ob der eigene Server mit einem Rootkit bestückt wurde -- zum Beispiel in der Zeit zwischen dem Bekanntwerden eines Sicherheitslochs und dem Einspielen des passenden Patches. Da auch Programmierer von Rootkits Fehler machen, kann man Rootkits manchmal selbst im Betrieb noch aufspüren. Bei Slanret wurde offensichtlich übersehen, dass das Rootkit auch im aktiven Zustand an dem Eintrag "ierk8243.sys" in den Windows-Systeminformationen unter Softwareumgebung/Treiber zu erkennen ist.

Eine weitere Möglichkeit, Rootkits im laufenden Betrieb zu erkennen, ist der Vergleich der internen Liste der nach außen geöffneten Ports mit einem externen Port-Scan. Die lokalen Server-Dienste zeigt unter Linux

netstat -plut

an. Unter Windows XP liefert

netstat -a -o

eine ähnliche Liste inklusive der Prozess-IDs. Diese lassen sich über den Task-Manager identifizieren, wenn man unter Ansicht/Spalten die PID aktiviert hat. Unter Windows 2000 gibt es die Option -o nicht, hier helfen Zusatz-Tools wie Active Ports [1] weiter.

Zeigt ein Port-Scan zum Beispiel mit nmap den TCP-Port 65535 als offen an, dieser taucht aber in der Ausgabe von netstat nicht auf, ist die Wahrscheinlichkeit, dass man sich Ärger eingehandelt hat, schon recht hoch. Wenn netstat den zugehörigen Dienst anzeigt, dieser aber nicht zum System gehört, ist ebenfalls Misstrauen angesagt. Bei Windows gehört allerdings schon einiges an Erfahrung dazu, die "normalen" Dienste als solche zu identifizieren.

Den Beweis, dass alles mit rechten Dingen zugeht, kann ein Port-Scan jedoch nicht liefern. Dazu verstecken Backdoors ihre Aktivitäten oft zu raffiniert. Wir haben beispielsweise schon Exemplare gesichtet, die die Hintertür erst aktivierten, nachdem sie ein ICMP-Paket bestimmter Größe im Netzwerkverkehr entdeckt hatten. Andere Rootkits verzichten ganz auf Server-Dienste und bauen, nachdem sie ein Paket mit einer bestimmten Signatur gesichtet haben, eine Verbindung von drinnen nach draußen auf.

Für die Zukunft ist sogar mit so genannten "Sniffer based Backdoors" zu rechnen. Hier öffnet das Rootkit keinen Port, um mit einem Angreifer zu kommunizieren, sondern belauscht lediglich den Netzwerkverkehr im gesamten Segment. Entdeckt es ein spezielles Paket, das nicht an den kompromittierten Rechner selber adressiert sein muss, verschickt es ein passendes Antwortpaket. Diese Antwort enthält dann eine gefälschte Absenderadresse, so dass die Kommunikation nicht bis zu dem kompromittierten Rechner zurückverfolgt werden kann. Zumindest gilt dies solange, wie nicht auf Layer-2 die MAC-Adressen der beteiligten Netzwerkkarten überwacht werden.

Suche mit Pferdefuß

Suche mit Pferdefuß

Eine weitere Anlaufstelle bei der Jagd nach Rootkits ist der Hauptspeicher des möglicherweise infizierten Rechners: Analog zu Viren lassen sich auch Rootkits über charakteristische Signaturen aufspüren. Unter Linux liefert "strings /dev/kmem" die Grundlage für solche Scans. Genau wie bei Viren-Scannern gilt auch hier die Einschränkung, dass man auf diesem Weg nur bekannte Rootkits zuverlässig aufspüren kann.

Um die Suche nach bekannten Rootkits zu erleichtern und zu automatisieren, hat das Projekt chkrootkit [6] ein Skript für Linux-Systeme erstellt, dass diese und weitere Scans zusammenfasst. In der Version 0.40 findet es immerhin 47 verschiedenen Rootkits, Würmer und bösartige, ladbare Kernel-Module. Dabei greift es auf diverse System-Utilities zurück, die man allerdings auch von einem anderen Medium laden lassen kann. Um auch Library-Rootkits außen vor zu halten, sollten diese externen Programme dann auch statisch gelinkt sein. Dazu muss man sie in der Regel allerdings neu übersetzen. Sicherheitsbewusste Administratoren führen chkrootkit regelmäßig und nach jedem Einspielen von Security-Patches aus.

Hilfreich sind auch Tools wie der File System Integrity Checker Tripwire [7]. Existiert ein garantiert integrer Tripwire-Datensatz, kann man damit nachträgliche angelegte oder modifizierte Dateien aufspüren und genauer inspizieren. Auch Intrusion Detection Systeme wie Snort [8] können Rootkits entdecken. Mit passenden Signaturen registriert und meldet ein solches netzwerkbasiertes IDS schon den Download des Rootkits oder dessen Netzwerkaktivitäten.

All diese Tests haben jedoch einen gewaltigen Pferdefuß: Sie können zwar einen positiven Befund liefern -- also ein Rootkit entdecken -- aber keine Sicherheit geben, dass das System tatsächlich sauber ist. Dafür muss man in den sauren Apfel beißen und das System von einem garantiert sauberen Medium booten. Beim Verdacht, dass ein Rootkit unter Windows als Gerätetreiber, also im Betriebssystemkern aktiv ist und nicht von Virenscannern gefunden werden kann, hilft oft schon, das System im abgesicherten Modus zu starten und erneut die Festplatte scannen lassen. Besser ist es jedoch, wenn man gleich von einer Rettungs-CD bootet. Ohne den schützenden Mantel des aktiven Rootkits können Viren-Scanner und Tools wie Tripwire verdächtige Dateien zuverlässig aufspüren. Letzteres liefert selbst bei noch unbekannten Root-Kits einen zuverlässisen Befund -- man muss dazu allerdings allen Veränderungen seit dem letzten Tripwire-Lauf nachgehen.

Aufräumarbeiten

Hat man ein Rootkit auf dem eigenen Server entdeckt, steht einiges an Arbeit an. Denn es genügt keineswegs, die von Tripwire oder einem Viren-Scanner inkriminierten Rootkit-Dateien zu löschen. Als erstes gilt es, zu ermitteln, wie der Einbrecher in das System gelangt ist, damit man den Rechner gegen erneute Angriffe absichern kann. Außerdem benötigt man den Zeitpunkt des Einbruchs, um festzustellen, welches der Backups noch sauber ist. Bei beidem hilft es, wenn man die Log-Meldungen des Servers an ein externes, gesichertes System weitergeleitet hat. Aus den Log-Dateien lassen sich in vielen Fällen der Zeitpunkt des Einbruchs und der dafür verwendete Dienst ermitteln.

Anhand der Namen der ausgetauschten und neu installierten Dateien findet man über Suchmaschinen in der Regel recht schnell den Namen des verwendeten Rootkits heraus. Für die meisten Standard-Kits stellen die Hersteller von AV-Software Anleitungen zum sicheren Entfernen bereit. Wer diesen folgt und darauf verzichtet, ein garantiert sauberes Komplett-Backup einzuspielen, sollte dabei jedoch beachten, dass der Einbrecher unter dem Schutz des Rootkits weitere Veränderungen am System vorgenommen haben kann. So kommt es durchaus vor, dass ausgebuffte Cracker für solche "Notfälle" eine zweite, unabhängige Hintertür einbauen. Im Falle einer Entdeckung gelangen sie dann zum Beispiel über ein dezent modifiziertes CGI-Skript sofort wieder ins System. Denn wenn in diesen Kreisen etwas mehr Ruhm und Ehre einbringt, als der Einbruch in einen Rechner, dann ist es das Zurückerobern eines gerade gesäuberten Systems und die damit verbundene Demütigung des verantwortlichen Administrators.

Literatur

[1] Mixter, Tarnkappen für Einbrecher, Rootkits: Funktionsweisen und Gegenmaßnahmen, c't 4/02, S. 196

[2] Hoglund, A *REAL* NT Rootkit, patching the NT Kernel, Phrack 55 [2]

[3] NT-Rootkit [3]

[4] LIDS [4]

[5] Integrity Protection Driver [5]

[6] chkrootkit [6]

[7] Tripwire [7]

[8] Snort [8] (ju [9])

URL dieses Artikels:
https://www.heise.de/-270198

Links in diesem Artikel:
[1] http://www.ntutility.com/freeware.html
[2] http://www.phrack.org/show.php?p=55&a=5
[3] http://www.megasecurity.org/Tools/Nt_rootkit_all.html
[4] http://www.lids.org/
[5] http://www.pedestalsoftware.com/products/intact/downloads/free_downloads.asp
[6] http://www.chkrootkit.org/
[7] http://www.tripwire.org/
[8] http://www.snort.org/
[9] mailto:ju@ct.de

Copyright © 2003 Heise Medien