Ausarbeitung

Betriebssysteme I: Klassische UNIX Exploits
Markus Sieber
Proseminar Secure Computing
Wintersemester 2006/2007
Technische Universität München
6. Dezember 2006
Inhaltsverzeichnis
1 Sicherheitskonzepte und ihre Lücken
1.1 Umgesetzte Sicherheitskonzepte in Unix Kerneln . . . . . .
1.1.1 Usermode/Kernelmode . . . . . . . . . . . . . . . .
1.1.2 Mehrbenutzersystem . . . . . . . . . . . . . . . . .
1.1.3 Prozesszugriffskontrolle . . . . . . . . . . . . . . . .
1.1.4 Dateisystem Zugriffskontrolle . . . . . . . . . . . .
1.2 Entstehen von Lücken . . . . . . . . . . . . . . . . . . . .
1.2.1 Buffer Overflows . . . . . . . . . . . . . . . . . . .
1.2.2 Fehlende Überprüfung in priviligierten Programmen
2 Root Exploits
2.1 Exploits gegen höher priviligierte Anwendungen
2.1.1 Beispiel: vixie crontab exploit . . . . . .
2.2 Exploits gegen den Kernel . . . . . . . . . . . .
2.2.1 Vorraussetzungen . . . . . . . . . . . . .
2.2.2 Beispiel: Linux ptrace Exploit . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Rootkits
3.1 Userland Rootkits . . . . . . . . . . . . . . . . . . . .
3.1.1 Funktionsweise . . . . . . . . . . . . . . . . .
3.1.2 Gestelltes Beispiel . . . . . . . . . . . . . . . .
3.2 Kernel Rootkits . . . . . . . . . . . . . . . . . . . . .
3.2.1 Funktionsweise . . . . . . . . . . . . . . . . .
3.2.2 Beispiel: adore-NG . . . . . . . . . . . . . . .
3.3 Erkennmöglichkeiten . . . . . . . . . . . . . . . . . .
3.3.1 Grundsätzliches zum Erkennen von Rootkits .
3.3.2 Möglichkeiten im laufenden Betrieb (unsicher)
3.3.3 System mit Resucue System untersuchen . . .
4 Ausblick
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
3
3
4
6
6
6
.
.
.
.
.
7
7
7
7
8
8
.
.
.
.
.
.
.
.
.
.
9
9
9
9
9
9
10
10
10
11
11
13
3
1
1.1
Sicherheitskonzepte und ihre Lücken
Umgesetzte Sicherheitskonzepte in Unix Kerneln
Unix Kernel, zu denen auch Linux zählt, wurden von Anfang an mit gewissen Sicherheitsfeatures konzipiert.´ Auf die nun etwas genauer eingegangen werden soll.
1.1.1
Usermode/Kernelmode
Prozessoren unterstützen mindestens zwei Betriebsmodi. Im sogenannten kernel mode
wird ein unbegrenzter Zugriff auf die Systemressourcen gewährt, das heißt jeder implementierte Befehl wird von der CPU verarbeitet, Speicherzugriff wird nicht limitiert und
auch I/O Operationen dürfen uneingeschränkt ausgeführt werden. Im Gegensatz dazu sind
Prozesse, die im user mode auf der CPU ausgeführt werden stark limitiert. Diese Prozesse
müssen, um I/O Operationen ausführen zu dürfen, eine Schnittstelle zum Kernel benutzen, der dann die gewünschte Operation im kernel mode ausführt. Eine I/O Operation
auf eine Festplatte kann folglich nur vom Kernel getätigt werden. Wenn ein Prozess eine
Datei lesen will, muss er die entsprechenden Funktionen des Kernels benutzen. [1]
1.1.2
Mehrbenutzersystem
Unix wurde als Multiuser-Betriebssytem entworfen. Jedem Benutzer wird mit seinem Namen eine eigene, einzigartige BenutzerID zugeordnet, die sogenannte UID. Ein Benutzer
kann nur auf seine eigenen Prozesse zugreifen, bzw denen Signale schicken. Ein besonderer
User ist root, der die UID 0 besitzt. Dieser User wird vom Kernel besonders behandelt:
Er hat Zugriff auf alles. Aus diesem Grund ist es ein Ziel von Linuxdistributionen, so
wenig Code wie möglich unter root Rechten auszuführen. [1]
1.1.3
Prozesszugriffskontrolle
Da Linux wie erwähnt ein Multiuserbetriebssystem ist, wird zu jedem Prozess gespeichert
welchem User dieser Prozess zugeordnet ist. Die Zugriffsrechte des Prozesses werden anhand dieser Information festgelegt. Wenn ein Benutzer nun einen neuen Prozess startet,
werden seine UID, EUID und SUID auf die BenutzerID des Anwenders gesetzt. Wenn der
Prozess nun über einen Syscall - eine Funktion im Kernel - eine Operation durchführen
will, überprüft der Kernel mit der effectiven UID“, ob der Prozess das Recht hat die
”
gewünschte Operation durchzuführen.
Es kommt allerdings auch vor, dass die Anwendung mehr Rechte benötigt, als dem
Benutzer gegeben sind. Aus diesem Grund wurde das System mit EUID (=effektive UID),
reale“ UID und SUID (=saved UID) entworfen [5].
”
4
Als Beispiel sei die Anwendung passwd erwähnt, mit welcher das Passwort eines Benutzers geändert werden kann. Diese braucht natürlich Schreibzugriff auf die entsprechende
Datei, die der Anwender selbst aber nicht einmal lesen darf, da dort die Passwörter gespeichert werden. Für die Anwendung passwd ist deshalb das suid-Bit gesetzt, welches
dafür sorgt, dass beim Start dieser Anwendung die EUID und SUID des neuen Prozesses
nicht auf die Benutzerid des Starters gesetzt werden, sondern auf die, die der Besitzer
der Datei hat, in unserem Fall root. Die Anwendung wird also mit EUID=0, SUID=0,
UID=BenutzerID gestartet. Wenn nun ein Zugriff auf die Systemdatenbank mit den Passwörtern erfolgt, wird die EUID für diesen Zweck überprüft, welche ja 0 ist. Es wird also
Zugriff auf diese Datenbank gegeben.
Abbildung 1: Bei dem Programm passwd ist das SUID Bit gesetzt
Da es höchst sicherheitskritisch ist, eine Anwendung mit root Rechten auszuführen,
kann die Anwendung sich selbst die benötigten Rechte nur an der Stelle geben, an der
sie auch tatsächlich notwenig ist. Der Prozess kann über einen Syscall also seine EUID
auf die UID setzen und hat damit wieder nur die Rechte des Anwenders. Sobald er die
nötigen zusätzlichen Rechte braucht, kann er sich wiederum eines Syscalls bedienen, der
seine EUID wieder auf das Alte setzt, was in der saved user ID“ kurz SUID gespeichert
”
ist.
Da Unix Kernel und damit natürlich auch Linux Gruppenunterstützung mitliefern,
existieren noch drei weitere solche IDs zu jedem Prozess: GID, EGID und SGID, die
genauso wie auch die BenutzerIDs funktionieren.
Bei einer Rechteüberprüfung wird also zuerst getestet ob der Prozess mit seiner EUID
Zugriff auf das entsprechende Betriebsmittel hat und falls dies nicht der Fall ist, wird
seine EGID getestet. [2]
1.1.4
Dateisystem Zugriffskontrolle
Die in Linuxumgebungen benutzten Filesysteme, speichern zu jeder Datei neben Inhalt
und Dateiname auch noch Informationen, wer die Datei lesen/schreiben oder ausführen
darf. Dazu besitzt eine Datei folgende zusätzliche Attribute:
1. Dateibesitzer
5
2. Gruppe des Dateibesitzers
3. Zugriffsrechte für den Dateibesitzer: lesen, schreiben und/oder ausführen
4. Zugriffsrechte für die Benutzer, die derselben Gruppe angehören: lesen, schreiben
und/oder ausführen
5. Zugriffsrechte für alle Anderen: lesen, schreiben und/oder ausführen
6. suid-Bit, siehe auch 1.1.3
7. sgid-Bit, welches analog wie das suid-Bit funktioniert, eben nur mit den Gruppenrechten
Für Verzeichnis existieren genau dieselben Rechtebits (Lesen, Schreiben und Ausführen), wobei Ausführen mit Betreten gleichzusetzen ist. Der Inhalt eines Verzeichnisses ist
also nur lesbar, wenn das Verzeichnis auch das Auführrecht besitzt.
Damit Prozesse für den Zugriff auf das Filesystem andere Rechte benutzen können,
wie für die restlichen Betriebsmittel, besitzt jeder Prozess neben den in 1.1.3 erwähnten
IDs auch noch eine FSUID und eine FSGID, die im Normalfall der EUID bzw EGID
entsprechen.
Der Kernel überprüft bei einem Zugriff auf das Filesystem die über die Dateiattribute
vergebenen Rechte mit der FSUID und der FSGID des Prozesses. Das heißt wenn die
FSUID des Prozesses dem Eigentümer der Datei entspricht, werden die Zugriffsrechte des
Dateibenutzers verwendet. Falls die FSGID des Prozesses der Gruppe der Datei entspricht
werden entsprechend die Zugriffsrechte für die Gruppe verwendet. Der Benutzer root hat
alle Rechte auf die Datei, ganz egal welche Attribute vergeben sind.
Um die Zugriffsrechte einer Datei zu verändert, existiert ein syscall. Dieser erlaubt es
jedoch nur dem Besitzer der Datei diese Attribute zu verändern (oder eben dem Benutzer
root)
Abbildung 2: Dateiauflistung und Anzeige der Zugriffsrechte
6
Die Zugriffsrechte sind wie folgt zu verstehen: Falls das erste Zeichen ein d“ ist, so
”
handelt es sich um ein Verzeichnis, bei normalen Dateien steht dort ein -“1 . Es folgen drei
”
Reihen mit je drei Zeichen. Zuerst die Rechte für den Benutzer selbst, dann für die Gruppe
und schließlich für den Rest. r steht für Lesen, wenn das Lesenrecht nicht gesetzt ist, so
steht dort nur ein -. Genau wie für das Lesenrecht folgen dann noch w für Schreibrecht
und x für das Ausführrecht. Falls das SUID Bit gesetzt ist, wird x durch ein S ersetzt.
Modere Filesysteme bieten inzwischen auch ein sogenanntes ACL System an, wodurch
der Besitzer neben den oben kennengelernten Zugriffsrechten noch weiter vergeben kann.
Er kann also zusätzlich explizit festlegen, dass der Benutzer Tom die Datei auch lesen
darf, obwohl er es über die normalen Zugriffsrechte nicht hätte.
Es sei an dieser Stelle auch noch angemerkt, dass es noch ein Sonderrecht für Verzeichnisse gibt, das sogenannte sticky Bit[11].
1.2
1.2.1
Entstehen von Lücken
Buffer Overflows
Sehr häufige Fehler in Computerprogrammen sind die Buffer Overflows. Über das Ausnutzen dieser Programmierfehler haben wir bereits einiges gehört, deshalb wird hier nicht
genauer darauf eingegangen.
1.2.2
Fehlende Überprüfung in priviligierten Programmen
Viele Programme haben auch ganze einfach ungenügend Überprüfungen eingebaut. In
Webanwendungen kommen diese Art der Fehler sehr häufig vor, wodurch es dem Angreifer
oft möglich wird Benutzerrechte auf dem angegriffenen System zu bekommen.
1
Es gibt noch andere Arten von Dateien“ wie FIFOs, Links und andere spezielle Dateien.
”
7
2
Root Exploits
Eine Schwachstelle in einem Softwareprogramm kann also dazu genutzt werden seine Rechte zu erweitern. Genau dies tun Exploits. Root Exploits sind Programme, die Schwachstellen in Software nutzen, um die Privilegien eines Benutzers auf Root Rechte auszuweiten.
Derartige Schwachstellen, die durch Programmierfehler entstehen, kommen in allen größeren Projekten vor. Die Hersteller von Software veröffentlichen gewöhnlich regelmäßig
Updates, die auch in der Regel die bekannt gewordenen Sicherheitslücken schließen.
2.1
Exploits gegen höher priviligierte Anwendungen
Auf einem Unixsystem sind die Zugriffsrechte für die Anwender sehr stark eingeschränkt.
Es gibt darum Programme die mit höheren Benutzerrechten laufen, wie zum Beispiel
- bereits erwähnt - das passwd Programm. Wenn in dieser Software Fehler gemacht
worden sind, können diese genutzt werden, um die Rechte dieses Programms dafür zu
nutzen andere Anweisungen auszuführen, die vom Programmierer nicht angedacht waren.
Wenn das neue Passwort, welches der Anwender eingibt zum Beispiel in ein Array von
30 Zeichen gespeichert wird, der Nutzer aber mehr als 30 Zeichen eingibt, so kommt es
zu einem Buffer Overflow, der ausgenutzt werden kann, um bösartigen Programmcode in
den Speicher zu schreiben.
2.1.1
Beispiel: vixie crontab exploit
Cron ist ein Anwendung, die dafür sorgt, dass bestimme Programme zu bestimmten
Zeiten ausgeführt werden. Der Crondämon läuft auf einem Unix System üblicherweise
mit root Rechten, da er sein EUID ändern muss, wenn die Anwendungen der Benutzer
ausgeführt werden. Die Anwender können ihre eigenen Cron Dateien erstellen, die dem
Crondämon sagen, wann er welches Programm ausführen soll, natürlich mit den Rechten
des jeweiligen Benutzers.
Da der Vixie Cronserver, der standardmäßig von Redhat benutzt wird, ungenügend
Kontrolle gegen die Daten in der Crontab Datei durchgeführt hat, war es möglich über
den allokierten Speicherbereich hinaus zu schreiben. Es konnte dadurch bösartiger Code
in den Speicher geschrieben werden, der das Vixie Cron Programm überschrieb. Dieser
Code wurde dann als root ausgeführt. [8]
2.2
Exploits gegen den Kernel
Aber nicht nur Software die im Usermode läuft ist anfällig gegen solche Arten von Angriffen. Auch der Kernel selbst kann Fehler enthalten, die ein bösartiger Nutzer ausnutzen
kann, um seine Rechte zu erweitern.
8
2.2.1
Vorraussetzungen
Um Fehler in der Kernelimplementierung ausnutzen zu können, muss der Angreifer meist
die Möglichkeit haben Code auf dem System auszuführen. Um dies zu erreichen muss er
unter Umständen erst eine andere Anwendung exploiten, die mit den Rechten eines normalen Systembenutzers läuft. Falls der Kernel jedoch einen Fehler in der Umsetzung der
Netzwerkprotokolle hat, so kann der Anwender diesen Fehler auch von einem entfernten
Rechner ausnutzen. Diese Fehler sind jedoch unwahrscheinlich.
Da der Systemadministrator seinen Linux-Kern selbst übersetzen kann und gewisse,
für ihn nicht benötigte, Funktionalität einfach weglassen kann, funktioniert nicht jeder
Linux Kernel Exploit auf jedem Linux Rechner, auch wenn die Kernelversion dieselbe ist.
2.2.2
Beispiel: Linux ptrace Exploit
Im März 2003 wurde ein Fehler im Linux Kernel bekannt, durch den ein Anwender root
Rechte erhalten konnte. Dieser Fehler benutzt eine Fehlimplementierung des Linux-Kerns.
Alle Linux Kernel der Serie 2.4 bis 2.4.20 und auch die der Serie 2.2 bis 2.23 sind davon
betroffen. Ptrace ist eine Kernelfunktion, die dazu gedacht ist, eine Debugmöglichkeit für
Entwickler bereit zu stellen. Prozesse lassen sie mit ptrace sehr gut überwachen. Immer
wenn ein Prozess auf eine Funktion zugreift, die in einem Kernelmodul implementiert
ist, wird eine neuer Childprozess gestartet, bei dem die EUID auf 0 gesetzt wird. Der
Vaterprozess - der Exploit - kann sich mit ptrace an diesen anderen Prozess anhängen,
während die EUID noch nicht auf 0 gesetzt ist. Über die ptrace Funktionen ist es dann
möglich den Programmcode des Childprozesses zu überschreiben. Da der Childprozess
dann seine EUID auf 0 ändert also mit root-Rechten läuft, kann der Exploit so jeden
beliebigen Code ausführen.
Der ptrace Exploit setzt voraus, dass im Kernel Moduluntersützung vorhanden ist
und ptrace Calls erlaubt sind. Dies ist aber in so gut wie jedem Linux System der Fall.
[6]
9
3
Rootkits
Damit ein Angreifer auch noch vollständige Rechte auf einem kompromittierten System
behält, selbst wenn die eignetliche Lücke geschlosse ist, kann er ein Rootkit installieren.
Rootkits sind Programme, die ein Benutzer, der in ein Computersystem eingebrochen
ist, installieren kann, um jederzeit wieder Zugriff auf das System zu erhalten. Für diesen
Zweck haben sie eine eingebaute Backdoor, über die der Angreifer jederzeit wieder Administratorrechte erhalten kann, auch wenn der eigentliche Fehler, über den er eingebrochen
ist wieder behoben wurde. Rootkits tarnen sich dabei selbst, so dass der Systemadministrator es schwer hat zu erkennen, dass ein solches Programm auf seinem Computer
installiert ist.
3.1
3.1.1
Userland Rootkits
Funktionsweise
Userland Rootkits sind Programme die auf der Benutzerebene installiert sind. Der Kernel
wird dabei unangetastet gelassen. Über bestimmte Befehlscodes, die nur der Angreifer
kennt, kann er das Rootkit jederzeit dazu bringen, seine Befehle auszuführen. Da das
Rootkit meist als Benutzer root läuft, hat der Angreifer die vollständige Kontrolle über
das System.
3.1.2
Gestelltes Beispiel
Ein einfaches Userland Rootkit würde einen root-Prozess starten, der einen Netzwerk
Port öffnet. Befehle die über diesen Port geschickt werden, führt das Programm mit root
Privilegien auf dem System durch. Zur Tarnung kann das Rootkit auch noch die Binaries
ls ps und netstat so abändern, dass das Rootkitprogramm nicht auftaucht. Auf diese
Weise kann der Administrator es nicht mit Standarttechniken entdecken.
3.2
3.2.1
Kernel Rootkits
Funktionsweise
Kernel Rootkits installieren sich in den meisten Fällen als Kernelmodul, welches die Kernel
Schnittstellen - die Systemaufrufe - so verändert, dass es selbst nicht mehr angezeigt wird.
Da zum Auflisten des Verzeichnisinhaltes syscalls benutzt werden, ist das Rootkit so in der
Lage sämtliche seiner Dateien (und die, die der Angreifer verstecken will) zu tarnen und
einfach nicht mit auszugeben. Dasselbe kann das Rootkit für Prozesse machen oder auch
für Netzwerk-Sockets um entfernten Zugriff auf den geknackten Rechner zu bekommen.
10
Kernelmodule sind geradezu prädestiniert, um Rootkits eine gute Basis zu bilden. Denn
alle syscalls lassen sich in den neuen Kernelmodulen überschreiben. Die neue Version des
syscalls kann weiterhin die Alte benutzen und dann eine gefilterte Ausgabe zurückliefern.
Kernelmodule können so auch wichtige Systemdateien modifizieren, zum Beispiel die Datei, die festlegt, welche Module geladen werden. Eine Anzeige der Datei kann aber diesen
Eintrag herausfiltern.
3.2.2
Beispiel: adore-NG
Ein sehr bekanntes Kernel Rootkit ist Adore NG. Adore NG besitzt folgende Funktionalitäten:
1. Dateien und Verzeichnisse können versteckt werden
2. Prozesse und Sockets lassen sich ebenfalls verstecken
3. Logs werden automatisch gefiltert. Versteckte Prozesse erzeugen keine Logeinträge
Adore NG lässt sich sehr einfach auf einem System installieren. Um Dateien zu verstecken, benutzt Adore NG die die Benutzer- und GruppenID der Datei. Im Programmcode
wird eine sogenannte ELITE UID und eine ELITE GID festgelegt. Wenn eine Datei diese Benutzer- und GruppenID besitzt, wird sie von den modifizierten Syscalls nicht mehr
angezeigt.
Benutzen lässt sich das Rootkit dann mit dem Programm ava. Dazu muss der Anwender sich über den ADORE KEY ausweisen. Da einige Schnittstellen zwischen dem ava
Client und dem Rootkit über das Filesystem ablaufen, lässt sich das Rootkit auch mit
Standartbefehlen über das proc Filesystem eingeschränkt bedienen. Die Authentifizierung
läuft wieder mit dem ADORE KEY ab. [9]
3.3
3.3.1
Erkennmöglichkeiten
Grundsätzliches zum Erkennen von Rootkits
Während Userland Rootkits sehr leicht über einen Fileintegrity Scanner erkannt werden
können, ist es mit Kernel Rootkits deutlich schwerer. Da ein Kernel Rootkit alle Funktionen, die die Existenz des Rootkits preisgeben, modifizieren kann, ist es theoretisch
möglich, dass ein Kernel Rootkit im Betrieb perfekt getarnt ist. Wenn man die Daten
des Systems allerdings auf einem anderen Computer mit dem Backup vergleicht, wird das
Rootkit sehr schnell auffallen, jedoch wird diese Praktik ja nur verwendet, wenn festgestellt werden konnte, dass ein Angreifer auf dem System war. Diese Spuren lassen sich
jedoch auch gut verwischen.
11
3.3.2
Möglichkeiten im laufenden Betrieb (unsicher)
Im laufenden Betrieb können Userland Rootkits erkannt werden, indem man statisch komplierte Programme benutzt, die mit Sicherheit nicht verändert wurden. Kernel Rootkits
können aufgedeckt werden, da kein perfektes Rootkit bekannt ist und über bestimmte
Techniken kann nachgewiesen werden, dass der Kernel nicht so operiert wie er sollte.
Wenn man zum Beispiel über den syscall signal allen PIDs von 1-999999 ein Signal
schickt, so kann man über den Rückgabewert erfahren, ob dieser Prozess existiert. Da
jedoch kaum ein Rootkit den signal syscall umprogrammiert, erfährt man somit alle PIDs
von existierenden Prozessen, auch die von den vom Rootkit versteckten. Man kann diese
Information nun mit der aus /proc vergleichen (oder der Ausgabe vom ps). Dort werden
die versteckten Prozesse nicht angezeigt. Man sollte jedoch immer im Hinterkopf behalten,
dass Rootkits auch diese Schwachstelle beheben können, indem sie den syscall signal
umschreiben.
Eine weitere Möglichkeit, um öffentlich verfügbare Kernel Rootkits aufzuspüren, ist
den Kernelspeicher nach bekannten Signaturen dieser Rootkits zu durchsuchen. Die meisten Cracker sind nicht in der Lage ihre Rootkits enstsprechend umzuprogrammieren, so
dass sich die Signatur angemessen ändert. Doch auch hier gibt es Ausnahmen, dadurch
gibt auch diese Technik keine 100 prozentige Sicherheit.
Um versteckte Dateien aufzuspüren, kann man eine Userspace Implementierung des
benutzten Filesystems benutzen und die Partition so mit der im Dateisystem eingebundenen vergleichen. Natürlich ist es theoretisch über ein Kernel Rootkit auch möglich diese
Ausgabe abzufälschen, aber in der Praxis viel zu aufwändig.
Es gibt ein Opensource Programm Namens chkrootkit [10], in welchem viele solche
Erkennungstechniken eingebaut sind. Es bietet außerdem auch einige Anwendungen zum
Untersuchen der Netzwerkinterfaces und offenen Ports, denn die Standartsoftware unter
Linux könnte ja durch das Userland Rootkit verändert worden sein.
Eine weitere Möglichkeit um Rootkits aufzuspüren, die sich an einen Netzwerkport
hängen, ist es von einem anderen Rechner aus einen Portscan durchzuführen. Wenn das
Rootkit einen Netzwerkport geöffnet hat, so reagiert der Kernel anderst auf Packete an
diesen Port, als wenn der Port geschlossen ist. Ein Kernel Rootkit kann natürlich auch diesen Mechanismus im Kernel abändern, aber da die Netzwerkfunktionalität sehr komplex
ist verzichten die meisten Rootkits auf diese Technik.
3.3.3
System mit Resucue System untersuchen
Wenn man das System mit Hilfe eines Rescue Systems bootet, kann man von diesem
System aus die Daten des Systems untersuchen. Man kann die Checksumme - üblicherweise
einen MD5-Hash - des Kernels mit einem Backup vergleichen und auch die Module und
12
Anwendungen die gestartet werden überprüfen. Dadurch kann man mit großer Sicherheit
ein Rootkit erkennen. Für diesen Zweck ist ein Backup des Systems sehr von Vorteil.
13
4
Ausblick
Einen absoluten Schutz vor Exploits und Rootkits gibt es nicht und wird es nie geben. Es
gibt nur relative Sicherheit. Um diese relative Sicherheit zu steigern gibt es moderne Entwicklungen, die darum bemüht sind, dass Buffer Overflows nicht mehr so gut ausnutzbar
sind. PAX und Intels XD sind ein paar dieser Entwicklungen. Es gibt auch andere Ansätze
um die Computersicherheit zu steigern, so zum Beispiel RSBAC - Rule Set Based Access
Control, welches es ermöglicht die Zugriffsrechte von Prozessen weiter einzuschränken.
Auch wenn Anwendungen mit root-Rechten laufen, haben diese dann nicht den kompletten Systemzugriff. Da diese neuen Technologien jedoch sehr schwer zu administrieren sind,
sind sie nicht weit verbreitet.
14
Literatur
[1] Andrew S. Tanenbaum (2003): Moderne Betriebssysteme. Pearson Education
[2] Daniel P. Bovet, Marco Cesati (2005): nderstanding the Linux Kernel. O’Reilly Media
[3] Anonymous (1999): Linux hacker’s guide. Markt & Technik
[4] Brian Hatch, James Lee, George Kurtz (2001): Hacking Linux exposed. Mcgraw-Hill
[5] Linux Benutzer/GruppenID Sicherheitskonzept:
http://www.stanford.edu/ stinson/cs155/notes/setuid.txt (zuletzt abgerufen am
9.1.07)
[6] Ivan Buetler (2003): Funktionsweise des Linux ptrace Exploits
http://www.csnc.ch/static/download/misc/Linux PTrace Root Compromize.pdf
ComPass Security (zuletzte abgerufen am 9.1.07)
[7] ptrace Exploit Programmcode:
http://august.v-lo.krakow.pl/ anszom/km3.c
[8] Vixie Crontab Root Exploit:
http://insecure.org/sploits/vixie.crontab.overflow.html
[9] Adore NG Rootkit:
http://stealth.openwall.net/rootkits/
[10] Rootkit Erkennprogramm: http://www.chkrootkit.org/
[11] Sticky Bit: http://en.wikipedia.org/wiki/Sticky bit
-