Rootkits - Versteckte Hintertüren

Introduction

Auch wenn ein Rechner richtig und aufmerksam administriert wird, kann es einzelne Fehler im System geben. Die meisten -und bei diesen kann ein Administrator nichts zu- werden durch Bugs in remote- sowie lokalen Programmen hervorgerufen und führen unter Umständen zu root-Rechten. Selbst wenn man täglich die Bugtraq-Listen der bekanntesten Sites wie www.securityfocus.de oder www.securitytracker.com abgrast und nach Bugs in auf seinem System installierten Paketen sucht, so kann es doch mit Leichtigkeit vorkommen, dass einzelne Fehler übersehen oder auf diesen Seiten nicht aufgeführt werden bzw. noch gar nicht entdeckt wurden (was bei Open Source im Gegensatz zu allen Windows-Programmen wohl nicht von langer Dauer sein dürfte - gerade Buffer Overflows oder Format String Fehler bleiben niemals lange verborgen). Als Administrator hängt man gegenüber einem Hacker immer einen Schritt zurück, auch wenn man sich die größte Mühe gibt, dies abzuändern.

Fakt ist, dass ein Hack meist nach demselben Muster abläuft:

Opfer erspähen,
Passives Scannen und Informationen sammeln,
Aktives Angreifen und in das System eindringen (gain root),
Hintertüren installieren und seine Spuren verwischen.

Wichtig ist, dass man sich als Administrator nicht nur um die Sícherheitsmaßnahmen kümmert, die einen Rechner bzw. ein Netzwerk vor einem Hack (also vor Punkt 3) schützen, sondern auch darauf aus ist, worst-case-Szenarien (Rechner infiltriert; Punkt 4) mit einzubeziehen und Vorkehrungen für diesen speziellen Fall zu treffen. Beliebte Tools, die Cracker wie auch Skript-Kinder immer wieder benutzen, um weitere Maßnahmen nach einem Hack einzuleiten, werden unter dem Oberbegriff Rootkits zusammen gefasst. Der Sinn von Rootkits ist, einem Angreifer auch ohne die erste ausgenutzte Sicherheitslücke immer wieder und ohne erkannt zu werden zu root-Rechten zu verhelfen, so dass ein Admin gar nicht merkt, dass sein System geknackt wurde. Aber rootkits können auch noch mehr: so können sie nicht nur die Spuren verwischen, die beim Knacken eines Rechners entstanden sind, eine wichtige Aufgabe ist auch, weitere Informationen über den gehackten Rechner zu sammeln, Passwörter der Benutzer auszuspähen oder auch Sniffer zu installieren, die Daten aus dem Netzwerkverkehr filtern. So eingesetzt können sie es einem Angreifer sehr erleichtern, wenn dieser in andere Systeme des Netzwerks eindringen will, um weitere wichtige Daten zu stehlen. Es handelt sich bei Rootkits also um nichts anderes als um eine Sammlung von Tools, die es auch schon Skript-Kindern leicht machen, ein System infiltriert zu halten.

In der Regel sind Rootkits als Trojanische Pferde realisiert, wobei wichtige Systemprogramme durch gepatchte Versionen ersetzt werden, die die Aktivitäten eines Hackers verschleiern. Manchmal kommen sie allerdings auch als LKM (Loadable Kernel Modul) vor, welche ohne Programme agieren, die Änderungen hingegen eine Ebene unter der Anwenderschicht durchführen.

Vertrauen kann schaden

Rootkits gehen also im Allgemeinen davon aus, dass ein Administrator seinen Programmen und ihrer Funktionsweise vertraut. Allerdings habe ich auch schon im Artikel über die allgemeine Sicherheit in Netzen geschrieben, dass man dies lieber nicht machen sollte, in der Regel bleibt einem Systembetreuer allerdings keine andere Wahl. Rootkits modifizieren Programme, so dass sie einen Angreifer nicht verraten können. So z.B. wird ps so abgeändert, dass die Prozesstabelle zwar anzeigt, den Trojaner und andere Programme allerdings verschweigt. ls könnte so gepatcht werden, dass es dem Admin Dateien des Rootkits vorenthält, usw. Ein erster Lösungsansatz wäre, alternative Programme wie pstree statt ps oder find anstelle von ls einzusetzen, wenn jedoch nichts Auffälliges zu entdecken ist, kann man nicht einfach davon ausgehen, dass nichts da ist - auch diese Programme könnten modifiziert worden sein! LKMs vollbringen ihr Werk allerdings geschickter: sie kommen ohne Trägerprogramme aus und können alle Änderungen von sich aus übernehmen, so z.B. das Löschen von Einträgen in Logfiles, das Abändern von Benutzerliste / Dateiausgabe / Prozesstabelle / Modulliste oder das Ausführen eines Trojaners. Da solche Module ihre Unwesen meist auf Kernelebene treiben, treffen ihre Änderungen alle Programme und sie können nicht mit dem Benutzen alternativer Tools ausfindig gemacht werden.

Interessantes Logging

Das manuelle Modifizieren von Log-Dateien kann einen größeren Zeitabschnitt in Anspruch nehmen, für einen Cracker vielleicht zu lange, da er so schneller von einem Administrator ausfindig gemacht werden kann. Beim Abändern der Logfiles werden deswegen oft kleine Programme wie "Zap" benutzt. Sie löschen die Einträge in "wtmp", "utmp", "lastlog" und "messages", oft auch andere Files in "/var/adm" bzw. "/var/log". Wird das "syslog" allerdings so konfiguriert, dass Einträge nicht in den Standarddateien bzw. -verzeichnissen gespeichert werden, können solche automatisierten Tools schnell ihre Wirkung verlieren und ein Admin kann wichtige Informationen über den Angreifer sammeln. Ein neuer Ansatz sind deshalb "intelligente" Tools, die z.B. die Datei "/etc/syslog.conf" sowie die Konfigurationsdateien anderer Logging-Programme auslesen und so den Speicherort der Logs feststellen (dabei könnte erstens überprüft werden, ob einschlägige Log-Programme als Prozesse laufen und ob die Configs in den Standardverzeichnissen untergebracht sind - ansonsten wird es schwierig, aber über die Parameter, mit denen ein Programm gestartet wurde, kann man auch einen abgeänderten Speicherort für Config-Dateien herausfinden). Somit kann man auch nicht davon ausgehen, dass die Logs unverändert sind - aber die Lösung ist so simpel wie auch nahe liegend: Remote Logging. Das im Artikel der allgemeinen Sicherheit in Netzen vorgestellte Verfahren, bei dem syslog so eingerichtet wird, dass es die Logging-Dateien auf einem anderen Rechner mit syslog-Daemon abspeichert, kann bei einem richtig und sicher konfigurierten Log-Host (mit so gut wie keinen offenen Ports und nur einem Zugang für Root) die richtige Lösung unseres Problems darstellen und den Angreifer zumindest erst einmal in Schach stellen. Eine interessante Lösung ist auch, den Angreifer mit seinen eigenen Waffen zu schlagen, d.h. ein LKM zu programmieren, welches entweder die syslog.conf mit modifizierten Daten ausgibt oder aber die Prozesstabelle so abändert, dass Logging-Programme vor den Augen eines Angreifers versteckt bleiben. Oder wie wäre es, wenn das System, wenn es einen Angriff entdeckt, den Infiltrator automatisch an einen extra für diesen Zweck modifizierten Rechner leitet, der ihm ein Scheinsystem und Scheinnetzwerk vorgaukelt, im Hintergrund aber alle relevanten Informationen über ihn sammelt?! Dies wäre zwar mit viel Kernel-Programmierarbeit verbunden und schwer zu konfigurieren, man kann es sich aber zumindest einmal überlegen. Ein ähnliches Ziel verfolgen auch die immer mehr in die Mode kommenden "Honeynets", welche mit Hilfe von Keyloggern, Sniffern und IDS wie snort Informationen über einen Angreifer sammeln und seine Aktivitäten überwachen und kontrollieren können. "Willst du Hacker abwehren?! Dann denke wie einer!" ist auch kein schlechter Leitspruch, den man ruhig öfters einmal beherzigen sollte. Administratoren und Hacker beherrschen zumeist dieselben Techniken und verfügen über nahezu dasselbe Wissen, nur ihre Motive unterscheiden sich voneinander...

Unerwünschte Hintertüren

Die Hintertüren, die ein Rootkit installiert, müssen nicht immer Netzwerk-Backdoors sein, zumal diese leicht durch Portscans von anderen Systemen aus kenntlich gemacht werden; darauf sollte man sich also keinesfalls verlassen. Lokale Hintertüren können hingegen auf Systemen, auf denen mehrere User einen Account haben, viel unauffälliger arbeiten. Gerade wenn ein LKM werkelt, welches die Benutzertabelle abändert, kann ein normaler User-Account mit einer Shell, die suid läuft, schnell zu einem effektiven Werkzeug werden. Beim ersten Eindringen startet das LKM ein kleines Programm, welches einen User ohne Home-Verzeichnis anlegt, sich selber das SUID-Flag setzt und dann immer wieder mit Root-Rechten gestartet werden kann, um eine root-Shell zu öffnen. Das LKM macht dann den Rest des Versteckspiels. Somit sieht ein Administrator nicht einmal den neuen User und erst recht nicht sein zweifelhaftes Treiben. Meist ist die Backdoor noch in einem anderen Programm enthalten und / oder mit einem Passwort versehen, so dass sie kein normaler User ausnutzen kann. Relevante Wirtsprogramme sind zumeist solche, die bereits ähnliche Aufgaben erfüllen wie die Backdoor an sich, so z.B. "login" oder "su". Dies macht es einem Administrator zumindest schwieriger, die Änderungen feststellen zu können.

Trojanische Pferde - zu bekannt?

Das Problem der trojanischen Pferde, die Angreifer in ein System einschleusen, ist schon seit längerem bekannt. Ihr Vorteil ist, dass ein Eindringling auch ohne explizites Benutzerkonto jederzeit wieder in ein System eindringen kann und dadurch weniger Spuren hinterlässt. Da sie aber recht schnell durch Portöffnungen entdeckt werden, mussten sich die bösen Jungs neue Wege einfallen lassen, Trojaner in einem System zu installieren, ohne erkannt zu werden. Zumeist werden deshalb heutzutage lediglich bereits bestehende Services gepatcht, so dass z.B. ein Passwort an einer Stelle abgefragt wird, an der man dies bei einer normalen Verbindung zu dem Service eigentlich nicht erwarten würde und dem Angreifer entweder eine root-shell zurück gegeben wird oder das Programm die gewünschten Kommandos ausführt und die Ausgabe dieser Befehle zurückgibt. Gepatchte Versionen gibt es fast von jedem Internet-Daemon, der einem Benutzer zu Root-Rechten verhelfen kann, so z.B. telnet oder ssh.

Eigenständige Hintertüren sind wie schon gesagt relativ leicht zu entdecken, auch der Traffic, den sie verursachen, kann einfach von einem Sniffer mit gelesen werden. Um sich wenigstens davor zu schützen und die Aktionen für einen Admin schwer nachvollziehbar zu machen, benutzen separate Backdoors zumeist einfache kryptographische Verfahren, wodurch die übertragenen Daten verschlüsselt werden.

"Rootkit's Important Tool": der Sniffer

Netzwerk-Sniffer stellen in vielen Rootkits einen wichtigen Bestandteil dar, können sie doch den gesamten Traffic lesen, der über ein angebundenes Hub / Switch läuft (was bei einer Art Firmenrouter schon mal die gesamten Daten darstellen kann) mitlesen und der Cracker diesen anschließend auswerten, um weitere Passwörter oder aber auch Firmengeheimnisse zu erfahren. Somit kann er zum einen weitere Rechner im Netz angreifen und zum anderen gewonnene vertrauliche Informationen an eine konkurrierende Firma verkaufen. Zumeist handelt es sich bei Sniffern um eigenständige Programme, welche allerdings des Weiteren gepatchte Versionen von Bordmitteln zur Verfügung stellen, so dass der Sniffer mit diesen nicht mehr entdeckt werden kann (anhand des für ihn typischen promiscious mode), so z.B. "ifconfig" oder auch "netstat".

Gegenschlag

Auch wenn die Mittel der Rootkits verschieden sind, läuft ihre Implementierung fast immer nach dem selben Schema ab. Das ist auch der Grund, weshalb man sie mit verschiedenen Techniken doch relativ gut aufspüren und isolieren kann.

Hat ein Admin seinen Job gut gelernt, so hat er bereits im Vorfeld Maßnahmen getroffen, die einem Rootkit keine Chance lassen und es bereits bei kleinsten Aktionen ausfindig machen. Wie zuvor schon einige Male erwähnt, verändern Rootkits oftmals Programme, um ihr Treiben vor den Argus-Augen eines Administrators zu verbergen. So gesehen stellt dieses Verhalten aber auch eine große Schwachstelle aktueller Rootkits dar. Schließlich lässt sich mit Prüfsummen die Unverfälschtheit aller Daten (in diesem Fall vor allem der Systemprogramme) feststellen. Einfache CRC-Summen sollten bei einer Überprüfung allerdings nicht verwendet werden, da einige Tools es fertig bringen, dass die CRC-Sum einer gepatchten Datei exakt den gleichen String enthält wie die des Originals. MD5-Summen, unter Linux einfach mit dem Programm "md5sum" erstellt, bieten da aufgrund ihrer starken Verschlüsselung schon ein größeres Maß an Sicherheit. Damit das Programm seine Vorteile allerdings auch ausspielen kann, sollten die gewonnenen Ergebnisse auf einem schreibgeschützten Medium gespeichert und etwaige Abweichungen an relevanten Systemprogrammen sofort einem Administrator gemeldet werden. Schließlich kann man die Prüfung auch von einem Cronjob erledigen lassen, man sollte aber bedenken, dass ein Angreifer zunächst die Crontab nach entsprechenden Einträgen durchsuchen wird, bevor er ein Rootkit installiert. Auch könnte eine Kernel-Manipulation dazu führen, dass "md5sum" falsche Werte ausgibt. Eine Liste mit Checksummen sollte sofort nach der Installation eines Systems erstellt werden, um einem Angreifer keine Möglichkeit einer Manipulation zu geben. Nur so kann die Authentität der Daten gewährleistet werden...

Man sollte auf alle Fälle sehr akribisch mit der Auswahl der zu untersuchenden Programme umgehen und keine Programme vergessen. Ebenso wäre es sinnvoll, Systemverzeichnisse (wie /etc und auch /dev) nach neuen Dateien zu untersuchen, um sicher zu gehen, dass keine Dateien hinzugefügt wurden, von denen ein Administrator nichts weiß. Anstatt "md5sum" kann ich den Einsatz von ausgereiften Tools wie "tripwire" oder "aide" nur empfehlen, die wesentlich mehr leisten können.

Als Vorsorge sollte ein Admin zudem ein eigenständiges und lauffähiges Linux-System auf Diskette oder Live-CD installiert haben, so dass er nach dem Verdacht einer Rootkit-Installation seine Festplatten read-only mounten kann, ohne dass ihn dabei Änderungen im Kernel seines Systems etwas ausmachen könnten. Zudem sollten alle Programme, mit denen man ein System untersucht, statisch gelinkt sein, da Manipulationen ja auch in den shared libraries stecken können.

Sollte man keine Vorkehrungen zum Aufspüren eines Eindringlings getroffen haben, wird die Suche schon etwas schwieriger. Man kann allerdings versuchen, nach normalen Dateien in /dev oder unbekannten Dateien in /etc zu suchen, welche Konfigurationstools für die Rootkits darstellen könnten. Gerade in /dev, wo ansonsten nur Device-Files abgelegt werden, macht sich eine normale Datei recht schnell bemerkbar (heraus zu finden mit "find /dev -type f"). Gepatchte Dateien enthalten in Folge dessen oftmals auch den String /dev, den sie zum Aufruf benötigen. Danach zu suchen ist nicht schwer. Und last but not least sei da "strace" angesprochen, welches alle Systemaufrufe eines Programmes verfolgt und ausgibt. Anhand dieser Liste kann man dann wiederum ein Öffnen von Konfigurationsdateien erkennen.

Des Weiteren spielt /proc eine wichtige Rolle beim Aufspüren von Rootkits, kann man hier doch Systemvariablen abrufen, die ein Rootkit eigentlich verstecken wollte. Einige Rootkits manipulieren auch diese Daten, will man eine umfassende Systemüberprüfung durchführen, kommt man an einem Blick in dieses Verzeichnis allerdings nicht vorbei (und ein Script zu schreiben, welches die vom System ausgegebenen Daten mit denen aus /proc vergleicht, stellt sich auch nicht als allzu schwierig dar). Große Bedeutung kommt dabei z.B. den Werten zu, welche die Prozesse identifizieren (/proc/PID/status) oder auch Netzwerkinformationen (/proc/net) ausgeben...

Wenn nicht schon standardmäßig geschehen, sollte man die Ports des Rechners auch noch einmal von einem sicheren Rechner aus scannen, um sicherzugehen, keine TCP oder UDP Netzwerk-Hintertüren übersehen zu haben.

Gesucht - Gefunden

Wenn man sich sicher ist, ein Rootkit gefunden zu haben, sollte die erste Maßnahme sein, den Rechner vom Netzwerk zu trennen. Auf der anderen Seite kann man das System aber auch weiter am Netz lassen, wenn man dem Cracker mit einem Honeynet oder ähnlichen Mitteln eine Falle gestellt hat (siehe separater Artikel hierzu). Dabei wird der Angreifer weiterhin bei seinen Taten beobachtet, sein Vorgehen analysiert und Daten über ihn gesammelt, um ihn später überführen zu können. Sollte diese doch recht umständliche Einrichtung nicht erfolgt sein, so muss der Rechner eben sorgfältig und vor allem vom Netz getrennt analysiert und von etwaigen Schädlingen gesäubert werden. Vor allem sollten die Logs (die hoffentlich remote gespeichert wurden) sorgfältig zu lesen sein, um Rückschlüsse auf eine genutzte Sicherheitslücke und Daten des Angreifers ziehen zu können. Anschließend sollten veränderte Programme entfernt und durch ihre "sauberen" Originale ersetzt werden. Dies setzt allerdings voraus, dass man als Admin die genaue Verfahrensweise eines Rootkits kennt und alle Änderungen genauestens nachvollziehen kann. Sollte dies nicht der Fall sein, kommt man um eine Neuinstallation kaum herum...

Fazit

Es ist wie immer in der IT-Sicherheit: der Bessere gewinnt. Rootkits gibt es viele und die meisten werden blindlings von Crackern und Skript-Kindern eingesetzt. Das gibt einem Admin viele Möglichkeiten in die Hand, sie aufzuspüren. Kennt er ihre Verfahrensweise, so kann er sie auch effektiv abwehren. Andererseits können sich Cracker vor einer Aufdeckung ihrer Aktivitäten allerdings auch schützen, wenn sie die Tools der Admins kennen und sich dagegen zur Wehr setzen. Dann kann man als Admin allerdings nicht sagen, dass man sich dem Problem nicht angenommen hätte; allerdings muss man sich dann fragen, ob die Konfiguration des Systems denn nicht doch hätte besser ausfallen können und wird spätestens dann über den Einsatz von IDS oder Honeynets nachdenken...