Die Möglichkeiten der Rootkit’s und der Kampf gegen sie

Eines der größten Probleme für die Malware-Autoren war schon immer das Unvermögen, die Anwesenheit eines Fremdcodes im System für den Anwender auf Dauer unsichtbar zu machen, im Idealfall sogar für das Antivirus-Programm. In der letzten Zeit, da sich das Schreiben eines Schadprogramms immer mehr von einer Beschäftigung aus jugendlichem Leichtsinn in ein Profitgeschäft mit kriminellem Hintergrund umwandelt, stehen besonders die Hacker-„Geschäftsleute“ vor der aktuellen Herausforderung, die „Spuren zu verwischen“. Auf welche Weise kann man ein Programm zum Diebstahl von Bankdaten oder einen illegalen Proxy-Server für den Spamversand vor dem Eigentümer des Computers verbergen?

Die modernen Cyberkriminellen lösen dieses Problem genauso, wie es die „Cyber-Hooligans“ vor 10-15 Jahren lösten. Einer der ersten Viren für den PC war Virus.Boot.Brain.a, ein bootfähiger Virus, der Systemfunktionen für den Zugang zur Festplatte abfing und beim Lesen des Bootsektors, beispielsweise durch ein Antivirus-Programm, anstelle der infizierten die Originaldaten einsetzte. Mit der Zeit wurden dieselben stealth-Mechanismen (Abfangen von Systemfunktionen und Unterschiebung von Daten) in Windows-Viren (Virus.Win32.Cabanas.a) verwendet.

Schadprogramme für UNIX sind noch nicht so weit verbreitet, wie für DOS und Windows, jedoch gerade von dort kam der Terminus Rootkit, der jetzt sehr häufig für die Bezeichnung der stealth-Technologien verwendet und von Autoren der Trojanerprogramme für Windows eingesetzt wird.

Ursprünglich bedeutet der Terminus Rootkit – Programm-Bausatz, der es dem Hacker ermöglicht, sich auf der gehackten Maschine festzusetzen, und der ein Entdecken verhindert. Hierfür werden System-Ausführungsdateien (login, ps, ls, netstat u.ä.) oder System-Bibliotheken (libproc.a) ausgetauscht, oder ein Kernel-Modul wird installiert. Ziel ist es, Versuche des Anwenders abzufangen, wahre Information darüber zu erhalten, was auf seinem Computer vor sich geht.

In der letzten Zeit erhält die Verwendung von Rootkit-Technologien zur Verbergung der Schadprogramme im System immer größere Verbreitung. Dies ist in der Grafik (Abb.1) ersichtlich:

Abb.1 Anwachsen der Verwendung von Rootkit-Technologien 
in Schadprogrammen
Abb.1 Anwachsen der Verwendung von Rootkit-Technologien
in Schadprogrammen

Der zunehmende Bekanntheitsgrad von Rootkit’s steht mit der öffentlichen Verbreitung der Quelltexte vieler Rootkit’s im Internet im Zusammenhang. Das Einfügen von Änderungen ist für die Autoren der Schadprogramme ein leichtes Spiel. Ein weiterer Aspekt, der die Popularität der rootkit’s fördert, ist die Tatsache, dass die Mehrheit der Windows-Anwender mit Admin-Rechten arbeitet, was den Rootkit’s eine erfolgreiche Installation auf dem PC bedeutend erleichtert.

Für die Unsichtbarkeit vor dem Anwender und das Unvermögen des Aufspürens durch Antivirus-Programme wird von kriminellen Virenschreibern und von Entwicklern so genannter „legaler“ Spionageprogramme gut und gern öffentlich Reklame gemacht.

Betrachten wir ausführlich die Situation für Windows und UNIX.

Rootkit-Technologien für Windows

Verbergen der Anwesenheit im System

Gegenwärtig kann man die existierenden Methoden für das Verbergen im System, die von Rootkit’s angewandt werden, in zwei Gruppen einteilen:

  1. Modifizierung der Abarbeitungswege durch die Anwendungsprogramme;
  2. Modifizierung der System-Strukturen.

Diese Methoden werden für das Verbergen von ungewöhnlichen Netz-Aktivitäten, Registry Änderungen und auffälligen Prozessen verwendet mit Ziel die Erkennung durch den Anwender oder von Antiviren-Programmen zu verhindern.

Die erste Methode zum Verbergen von Informationen kann sowohl im Anwender-Modus als auch im Kernel-Modus realisiert werden. Die praktische Umsetzung für den Anwender-Modus ist durch seine relative Einfachheit gekennzeichnet. Häufiger, als eigentlich sonst durch Applikationen üblich, wird hier eine Methodik eingesetzt, die auf dem Abfangen der Aufrufe der API-Funktionen (Abb.2) beruht:

Abb. 2  Abfangen der Anfragen an die API-Funktionen
Abb. 2 Abfangen der Anfragen an die API-Funktionen

Typischerweise erfolgen Aufrufe der System-API-Funktionen durch Dienstprogramme entweder über spezielle Datenbereiche (Import/Export-Tabellen), oder mit Hilfe der API-Funktion „GetProcAddress“. Da der Programm-Code in DLL-Modulen realisiert ist, kann das Rootkit die Anfragen der Anwendung abfangen und sich so in den Prozeß einschleusen. Der Übeltäter hat damit die Möglichkeit, alle Anwendungen des Benutzers zu kontrollieren. Die dargestellte Manipulation des Abarbeitungsweges ist gut dokumentiert und einfach in der Realisierung, was ihre Verwendung durch die Rootkit’s erleichtert.

Neben diesem „Vorteil“ der leichten Umsetzung gibt es bei der Realisierung von Rootkit’s im Anwender-Modus einen wesentlichen Nachteil – das wirksame Verbergen der Manipulation. Das Vorhandensein von Rootkits im Anwender-Modus des Systems kann ohne große Anstrengung über spezielle Hilfsprogramme festgestellt werden. Und genau dies ist der Grund für das in der letzten Zeit gestiegene Interesse für Rootkit-Technologien im Kernel-Modus, ungeachtet des höheren Schwierigkeitsgrades ihrer Entwicklung.

Betrachten wir nun also die Methoden des Kernel-Modus, welche eine unvergleichbar höhere Qualität der Verbergung der Manipulation aufweisen. Die überwiegende Mehrheit der Rootkits im Kernel-Modus verwenden nicht dokumentierte Strukturen des Betriebssystems. So wird, beispielsweise häufig das Abfangen der Anwendungsprogramme aus der Tabelle KeServiceDescriptorTable verwendet, in welcher die Zahl der Services variiert – in Abhängigkeit von der Version des Betriebssystems. Dies zwingt die Rootkits- Entwickler zur Durchführung zusätzlicher Analysen des System-Codes, um Hinweise auf Anwendungsprogramme aus oben erwähnter Tabelle festzustellen. Diese Vorgehensweise erinnert sehr an das Abfangen der API-Funktionen.

Beispiel der Modifizierung der Systemstrukturen ist die Veränderung der System-Liste PsActiveProcessList. Diese Vorgehensweise wird von Rootkit FU (welcher von Kaspersky Anti-Virus als Rootkit.Win32.Agent.l erkannt wird) verwendet: ein beliebiger Prozess kann vor den meisten Systemutilities verborgen werden (Abb. 3, 4).

Abb.3 Liste der Prozesse vor dem 
          Rootkit-Start
Abb.3 Liste der Prozesse vor dem
Rootkit-Start

Abb.4  Liste der Prozesse nach dem
            Rootkit-Start
Abb.4 Liste der Prozesse nach dem
Rootkit-Start

Auf Abb. 3 ist ersichtlich, dass der gestartete Text-Editor Notepad in der Liste der aktiven Prozesse unter dem Namen notepad.exe sichtbar ist (mit fetter, roter Linie umkreist). Abb. 4 zeigt den Bildschirm nach dem Start des Rootkits FU mit dem Befehl, den Prozess zu verbergen. Auf der Abbildung ist ersichtlich, dass bei aktivem Editor sein Name aus der Liste der aktiven Prozesse verschwunden ist (fetter, roter Pfeil).

Das Erkennen von Rootkits

Im Wettlauf mit der Erkennung werden Rootkits immer eine Nasenlänge vor den Anti-Virenprogrammen liegen. Ein Grund dafür ist das permanente Erscheinen neuer Technologien für rootkits. Zum anderen ist ein Grund auch die Tatsache, dass die Entwickler der Anti-Virenprogramme Zeit für die Durchführung der Analyse und Bereitstellung der Erkennung benötigen. Dennoch haben wir, ungeachtet der scheinbar schwierigen Erkennung der Rootkits, bereits effektive Methoden erarbeitet und in Version 6 unserer Produkte, die derzeit in unserem Labor getestet werden, realisiert. Betrachten wir im folgenden die Reaktion unseres Produktes auf das Erscheinen des beobachteten Rootkit FU im System.

Das Ergebnis rootkits war das Verbergen des Vorhandenseins des Prozesses „notepad.exe“ im System. Die Antirootkit-Funktionen erkennen dieses Verbergen jedoch und das Antiviren-Programm gibt dem Anwender eine entsprechende Warnung aus (Abb.5).

Abb. 5 Erkennen unbekannter verborgener Prozesse
Abb. 5 Erkennen unbekannter verborgener Prozesse

Das entwickelte Subsystem ermöglicht nicht nur bereits in die Antivirus-Dateien aufgenommene rootkits auf dem Anwendercomputer zu bestimmen, sondern auch unbekannte, wie in Abbildung 5 gezeigt wird.

Ein ähnliches Subsystem gibt es auch für die Erkennung von Rootkits im Anwender-Modus. Diese schalten sich wie oben dargestellt in den Kommunikationsprozess mit den DLLs ein und manipulieren diesen.

Das neue Subsystem reagiert in diesem Fall wie folgt: der Anwender wird darüber informiert, dass ein konkreter Prozess versucht, Code in einen fremden Adress-Bereich einzuschleusen (Abb.6).

Abb.6. Erkennen des Einführens des Codes in einen fremden Adress-Bereich
Abb.6. Erkennen des Einführens des Codes in einen fremden Adress-Bereich

Rootkit-Technologien für UNIX

Verbergen der Anwesenheit im System

Die Situation in UNIX erinnert sehr an die Situation unter Windows. Der Angreifer installiert das Rootkit auf dem Computer nachdem er einen privilegierten Zugang „root“ erhalten hat. Root-Rechte, erforderlich für die Installation der überwiegenden Mehrheit der Rootkits, erhält der Übeltäter über die Ausnutzung bekannter Sicherheitslücken, wenn er Zugang zum System mit gewöhnlichen Anwenderrechten hat. In diesem Fall kann er das System lokal angreifen oder Hilfsprogramme zum Hacken der Datenbanken mit den Passwörtern verwenden. Wenn der Übeltäter die entsprechenden Rechte nicht besitzt, kann er, um in das System einzudringen, von der Ferne angreifen oder beispielsweise Sniffer zum Abfangen der Passwörter einsetzen. Ein derartiges Abfangen von Passwörtern ist für eine ganze Reihe Dienste (ftp, telnet u.a.) möglich, da diese die Übergabe der Passwörter im Netz in offener Form abwickeln.

Abhängig von den bereitgestellten Möglichkeiten kann das rootkit verschiedene Schadprogramme (Trojan-DDoS, Backdoor und sonstige) enthalten, welche auf dem kompromittierten Computer installiert werden und vom Angreifer die Befehle zur Ausführung abwarten. Außerdem können die Rootkits Patches enthalten, die Sicherheitslücken im Systemschutz schließen, mit dem Ziel, ein wiederholtes Eindringen seitens eines anderen Angreifers zu vermeiden.

Genauso, wie unter Windows, gibt es UNIX-Rootkits im Anwendungs- und im Kernel-Modus.

Betrachten wir zunächst wieder den Anwendungs-Modus: In der Regel bestehen die Rootkit’s aus Trojaner-Versionen gewöhnlicher Programme, welche die Anwesenheit ihrer Komponenten im System verbergen und aus einer Backdoor, die einen verdeckten Zugang ins System gewährt. Beispiele für Rootkits im Anwendungs-Modus sind lkr, trOn, ark und andere.

Sehen wir uns das Beispiel trOn an: Um sein Vorhandenseins im System zu verbergen, führt dieses Rootkit eine Reihe von Aktionen durch. Während der Installation stellt es den syslogd-Deamon ab, anschließend tauscht es folgende System-Utilities mit seinen Trojaner-Versionen aus: du, find, ifconfig, login, ls, netstat, ps, top, sz. Darüber hinaus ergänzt es im System die Trojaner-Version des sshd-Deamon. Zum Schluss startet es im Hintergrund sniffer, in inetd.conf wird der Start von telnetd, rsh, finger-Deamons ergänzt, inetd neugestartet und syslogd erneut gestartet.

Normal befindet sich trOn in /usr/src/.puta, aber dank seiner bereits installierten Komponente ls, ist das Verzeichnis unsichtbar.

Betrachten wir nun Rootkit’s im Kernel-Modus: Rootkit’s dieses Typs bieten alle Fähigkeiten des vorangegegangenen Typs, jedoch stärkerer Wirkung: Rootkits im Anwender-Modus können einzelne binäre Dateien modifizieren, Rookits des Kernel-Modus brauchen nur den Kernel selbst verändern, was die „Qualität“ des Verbergens der Information bedeutend erhöht.

Es existieren einige Methoden für das Eindringen der Rootkits in den Kernel des Systems:

  1. Verwendung von LKM: Linux Kernel (wie auch viele andere Betriebssysteme) lassen es zu, Module (oder Treiber) im laufenden Betrieb (on-the-fly) zu laden, was es dem Übeltäter erlaubt, die System-Aufrufe des Kernel zu verändern damit dieser falsche Information herausgibt (z.B. eine nachgebesserte Dateiliste). Die Nutzung einer solchen Herangehensweise kann man abwenden, wenn man den monoliten Kernel ohne LKM-Unterstützung kompiliert. Die Entscheidung dafür hat jedoch einen wesentlichen Mangel – man muss in den Kernel alle erforderlichen Treiber einschließen;
  2. Einträge in /dev/kmem, welcher den Zugang in Speicherbereiche gibt, die normalerweise vom Kernel belegt sind. Einträge in /dev/kmem überschreiben den Kernel ebenfalls im laufenden Betrieb. Der Angreifer muss für die Veränderung des Kernels lediglich einen geeigneten Speicher-Platz finden. Ein Problem, das leicht zu lösen ist. Es existiert eine Patch, der einen direkten Eintrag in /dev/kmem unterbindet. Genauso kann man das über mmap tun;
  3. Infizierung vorhandener Module: Diese Methode unterscheidet sich von der ersten dadurch, dass das Rootkit keine einzelnen Modul enthält sondern das Eindringen in vorhandene nutzt. Das Anwenden dieser Vorgehensweise macht Rootkits resistent bei einem Neustart, indem einige Module infiziert werden, welche auf jeden Fall geladen werden (z.B. den Treiber des Dateisystems).

Erkennen der Rootkits

Zum Erkennen von Rootkits kann man leider keine universellen Ratschläge geben, doch das nachstehend Gesagte ermöglicht ein Erkennen der Mehrheit der aktuellen Rootkits:

  1. Das Verfolgen anomalen Verhaltens von Programmen, der ungewöhnlichen Nutzung des Netzes, auszuführende Aufgaben beim Systemstart und die registrierten Einträge der Anwender;
  2. Verwendung der folgenden Hilfsprogramme, welche bei der Erkennung der Anwesenheit von rootkits im System unterstützen: Saint Jude, Chrootkit, RkScan, Carbonite, Kstat, Rootkithunter, Tripware, Samhain und andere.

Resümee

Alle für Windows betrachteten Methoden zum Entdecken der aktiven Rootkits nutzen die Erkennung des Eindringens in und der Störung des Systems während des laufenden Betriebs. Genau diese Auswirkungen werden von unserem Produkt genutzt und ermöglichen es sehr effektiv unbekannte Rootkit’s zu erkennen. Mehr noch, in den jüngsten Windows-Versionen wird den Rootkit-Entwicklern das Leben noch schwerer gemacht, da diese Windows-Versionen Veränderungen im System-Code und den System-Strukturen nicht zulassen. Dieser Schritt der Entwickler der Betriebssysteme erlaubt es, für bestimmte Zeit das Wachstumstempo neuer rootkits für die aktuellen Versionen von Windows zu verringern.

Der Überhang der Zahl der Schadcodes für Windows im Vergleich zu UNIX ist durch die gegenwärtig größere Verbreitung von Windows begründet. Im Falle eines Ansteigens der Popularität von Unix wird sich die Situation allmählich ändern – es werden neue rootkits für Unix erscheinen und genauso Methoden zur Erkennung und Beseitigung.

Abschließend möchten wir bemerken, dass der effektivste Schutz im Kampf gegen Rootkits die Prävention ist.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.