DAS ROOTKID UEBERLEBENS HANDBUCH / (c) 2001 Oliver Schroeder v0.1



letzte Änderung: 16.1.2002

Inhalt:


1. Wie hackt man andere Rechner?
2. Wie kann ich feststellen, ob ich gehackt wurde?
3. loadable kernel modules (lkms)
4. Ein Rechner wurde gehackt. Na und?
5. Ich wurde gehackt! Was tun?
Empfehlungen zu einer Server-Installation
Referenzen



1. Wie hackt man andere Rechner?

Wenn man (erfolgreich) Hackerangriffe verhindern will, muß man verstehen wie sie gemacht werden. Und man muß die Illusion fallen lassen, man könne sie effektiv verhindern.

Um in ein fremdes System einzudringen gibt es (fast) undendlich viele Möglichkeiten:

Ziel ist es in jedem Falle, root-Rechte auf dem Zielrechner zu erlangen. Sobald man root-Rechte hat erfolgt der zweite Teil der Attacke: Die Verschleierung der eigenen Anwesenheit. Dazu werden alle Logfileeinträge, die auf das Eindringen hinweisen, entfernt. Weiterhin werden Systemprogramme (oder sogar der Kernel selbst) manipuliert, um eigene Aktivitäten zu verstecken.

Der nächste Schritt hängt von der Motivation des Hackers ab. Spätestens an dieser Stelle muß man sich also fragen, warum ein Hacker überhaupt versucht in ein fremdes System einzudringen. Hauptsächlich dürften dafür folgende Gründe in Frage kommen:

Erstaunlich oft handelt es sich bei den Hackern um Skriptkids, die einfach nur in einem IRC-Netzwerk Krieg spielen wollen.



2. Wie kann ich feststellen, ob ich gehackt wurde?

Wenn ein wirklich fähiger Hacker ein System gehackt hat, sind die Aussichten ihn zu entdecken gering. Wenn der Hacker geschickt und gekonnt vorgegangen ist, kann niemand ein gehacktes System erkennen, zumindest nicht ohne Hilfsmittel. Wie oben angedeutet handelt es sich aber (heutzutage) grösstenteils um Skriptkiddies, die einfach nur fertige Programme (Exploits und rootkits) ausführen ohne zu wissen, was sie da genau tun. In letzterem Fall findet man häufig noch Rückstände in irgendwelchen Logfiles.
In den meisten Fällen wird ein rootkit installiert. Dieses löscht automatisch alle Logfileeinträge und tauscht viele Systemprogramme aus, z.B. Meistens werden weitere Systemprogramme ausgetauscht.

Der Tausch dient der Verschleierung der eigenen Anwesenheit, der Installation zusaetzlicher Hintertüren ins System und i.d.R. der Installation eines Netzwerksniffers um weitere Zugangsdaten zu anderen Rechner zu erlangen. Man kann also i.A. den Einbruch gar nicht feststellen, da alle Hilfsmittel, mit denen man einen erfolgreichen Einbruch entdecken könnte, ausgetauscht wurden.

In der Regel wird man Unstimmigkeiten entdecken. Z.B. große Lücken in Logfiles, nicht erklärbarer Platzverbrauch auf den Festplatten, der Rechner lauscht auf ungewöhnlichen Ports usw.



3. loadable kernel modules (lkms)

Ein Hacker versucht grundsätzlich, seine Anwesenheit und Aktivitäten zu verschleiern. Aus diesem Grund werden alle system-utilities ausgetauscht, die auf ihn hinweisen könnten.
Ausgetauschte Programme kann man aber mit entsprechenden Hilfsmitteln (rpm, IDS) leicht ausfindig machen. Hacker haben sich deshalb gefragt, ob man das Problem der Tarnung nicht auch anders und eleganter lösen kann. Die Antwort auf diese Frage lautet: ja, man kann.
Nahezu jedes Betriebssystem unterstützt dynamische Treiber, d.h. zur Laufzeit des Kernels ladbare Module, die die Kernelfunktionalität erweitern. Der Kernel stellt den Modulen dazu eine Sprungtabelle zur Verfügung in der alle Funktionen und deren "Aufenthaltsort im Speicher" aufgelistet sind. Ein Modul kann also sehr einfach Einträge an diese Tabelle anhängen und so eigene Funktionen zum Kernel hinzufügen.
Niemand, auch nicht der Kernel, hindert aber ein Modul daran andere Einträge zu verändern. So kann ein Modul beispielsweise die Funktion (wir nennen die Kernelversion des 'ls' an dieser Stelle mal so) 'sys_ls' austauschen. Wenn ein Programm ein Verzeichnis auflisten möchte (z.B. das ls-Programm), wird diese Kernel-Funktion aufgerufen. Ein Hacker wird in seinem Modul also Funktionen schreiben, die (in Pseudocode) in etwas so aussehen:

  int init_new_sys_ls ()
  {
  	old_sys_ls = kernel_sprung_tab [sys_ls];
	kernel_sprung_tab [sys_ls] = new_sys_ls;
  }

  int new_sys_ls ()
  {
	if (VerzeichnisEintrag == "GeheimesHackerProg")
		return;
	return (old_sys_ls);
  }

Auf diese Weise wird die Datei "GeheimesHackerProg" nicht mehr aufgelistet. Weder durch 'ls' noch durch irgendein anderes Programm ("echo *" z.B.) und der Hacker muss keines der vorhandenen Programme austauschen. Sein geheimes Progrämmchen wird nach dem Laden des Moduls einfach nicht mehr gelistet.

An dieser Stelle möge der Leser sich gewiss werden, das wirklich alle Vorgänge auf einem Computer über den Kernel abgewickelt werden. Ein Modul soll geladen werden? sys_load_module. Alle geladenen Module sollen aufgelistet werden? sys_list_modules. Alle Prozesse sollen angezeigt werden? sys_list_procs.
Der Hacker kann sogar Teile einer (Konfigurations-) Datei vertecken. Der Hacker muss dafür sorgen, das sein Modul auch nach einem Neustart wieder geladen wird. Deshalb wird er, unter Unix-Systemen, in einem der zahlreichen Initskripte (rc-Dateien) eine entsprechende Anweisung eintragen. Durch Ausblenden von Dateiinhalten kann der Administrator diesen Eintrag jedoch nicht sehen.

An dieser Stelle wird deutlich, wie weitreichend die Manipulationsmöglichkeiten der Hacker mit Kernelmodulen sind. Selbst Intrusion Detection Systeme (IDS) versagen wenn Kernelmodule im Spiel sind. Natürlich muss der Hacker root-Rechte auf dem gehackten Rechner besitzen und dabei noch berücksichtigen, daß er ja selbst auf seine Dateien zugreifen möchte und muss deshalb noch Hintertüren einbauen um die Tarnung umgehen zu können. Das soll uns an dieser Stelle aber nicht weiter interressieren, Möglichkeiten dafür gibt es sprichwörtlich wie Sand am Meer.
Von derartigen Kernelmodulen findet man jede Menge anwedungsfertig im Internet für alle gängigen Betriebssysteme, wie z.B. BSD, Linux, Solaris aber auch für alle Windows Varianten.
Wenn ein wirklich gut geschriebenes (und gut konfiguriertes) Kernelmodul dieser Art installiert wurde, hat der Administrator praktisch keine Möglichkeit mehr den Hacker überhaupt zu bemerken. Allenfalls an sekundären Merkmalen, wie ungewönlichen Netzverkehr.



4. Ein Rechner wurde gehackt. Na und?

Wenn ein Rechner gehackt wurde ist es doch ausreichend diesen genauer unter die Lupe zu nehemen und ggf. wieder neu aufzusetzen, oder?

Nein, ist es nicht. In aller Regel befinden sich im selben Netzsegment mehrere Rechner und der Angreifer kann alle Verbindungen mit diesen mitlauschen. Sie verwenden ssh? Kann man z.B. mit einer "man in the middle attack" (MITM) und DSniff mitlauschen. Sie verwenden Switches und dehalb kann ein anderer (gehackter) Rechner andere Verbindungen nicht "sehen"? Irrtum, Switche lassen sich z.B. mit ettercap austricksen.
Durch das mitlauschen der ssh-Verbindungen muss der Hacker noch nicht einmal die anderen Rechner angreifen. Es reicht eine Weile zuzuhören, denn es werden alle Logins mit ihren Passwörtern mitprotokolliert (DSniff). Solange also noch ein gehackter Rechner in diesem Netzsegment vorhanden ist, muss man davon ausgehen dass auch alle anderen gehackt sind, auch wenn dort keine Anzeichen zu finden sind. Der Hacker hat ja einen regulären Zugang auf diese.



5. Ich wurde gehackt! Was tun?

Wenn man den Verdacht eines gehackten Rechners hat empfehle ich folgende Vorgehensweise: Wurde der Rechner tatsächlich gehackt, empfehle ich folgendes:



Empfehlungen zu einer Server-Installation



Referenzen:

(nearly) Complete Linux Loadable Kernel Modules
Attacking FreeBSD with Kernel Modules
Attacking Solaris with loadable kernel modules
Detecting Loadable Kernel Modules (LKM)
chkrootkit, nice tool for detecting rootkits
logfile einer sshd attacke (von mir) auf einen anderen Rechner





copyright © 1997-2018  Oliver Schroeder (remove XYZ)