Gut Gewappnet?!

Die aktuellen Nachrichten lassen kaum einen Zweifel: Rootkits verursachen Probleme für Microsofts Betriebssysteme. Auch für das kommende – sicherheitstechnisch aufgerüstete – Windows Vista demonstrieren namhafte Experten bereits erste Rootkits, um den Fortbestand des Problems zu verdeutlichen [1].

Schadenfreude ist hier aber fehl am Platz: Auch Unix- und Linux-Systeme werden seit vielen Jahren von Rootkits geplagt. Wie aber sieht ein solcher Schädling überhaupt aus und wie gelangt er auf den Rechner?

Im Grunde handelt es sich bei einem Rootkit um eine Art Baukasten für den Einbruch in Rechnersysteme. Die Schritte der Einbrecher ähneln sich bei allen Attacken; vereinfacht dargestellt, sehen sie so aus:

• 1. Festlegung des Zielsystems
• 2. Analyse des Zielsystems (Betriebssystem, Dienste, Benutzer, etc.)
• 3. Recherche der Sicherheitslücken
• 4. Einbruch (Exploit)
• 5. Verwischen der Spuren
• 6. Installation von Hintertüren
• 7. Installation von (Kennwort-)Sniffern

Während die Punkte 1 bis 4 sehr individuell vom Zielsystem abhängen, gleichen sich die Schritte 5 bis 7 bei allen Einbrüchen. Ob diese über einen FTP-Server oder ein erratenes Kennwort erfolgen, spielt für die Installation einer Hintertür keine Rolle. Die Aufgabe des Rootkits besteht darin, die Schritte 5 bis 7 zu vereinfachen und teilweise zu automatisieren.

Ein Rootkit dient dabei nicht als Einbruchswerkzeug, sondern hilft dem Angreifer nach getaner Arbeit, unentdeckt zu bleiben und weiter das System zu nutzen.

Rootkit-Evolution

Über die Jahre entwickelten Hacker verschiedene Arten von Rootkits für Linux. Die erste Generation arbeitet dateibasiert und tauscht lediglich einzelne Dateien aus, um Hintertüren einzubauen. Ein neuer Inetd-Superserver stellt dann einen Telnet-Server bereit, der an einem zusätzlichen Port lauscht. Befehle wie chfn verwandeln einen normalen Benutzer bei der Eingabe eines bestimmten Kennwortes in einen Root-Benutzer.

Um die Installation vor zusätzlichen Programmen wie Sniffern und Log-Dateien zu verbergen, tauschen diese Rootkits auch Kommandos wie ls, find, ps und top aus. Die neuen Befehle zeigen die Dateien und Prozesse des Einbrechers nicht an. Einer der bekanntesten Vertreter dieser Gattung heißt Linux-Rootkit-5 (LRK5). Interessierte Leser finden dieses und weitere vorgestellte Rootkits ohne Probleme im Internet (siehe Kasten "Rootkits")

Abbildung 1: Die Webseite Packetstorm Security hält nicht nur Informationen zu Rootkits, sondern auch die Schädlinge zur eigenen Analyse bereit.

Werkzeuge gegen diese Rootkits gab es recht schnell. Das bekannteste heißt Tripwire (Stolperdraht). Es schützt vor solchen Angriffen, indem es zu Beginn eine Datenbank mit den Prüfsummen der auf dem System befindlichen Dateien anlegt. Dann prüft Tripwire regelmäßig die Integrität der Dateien anhand der Datenbank. Es bietet guten Schutz vor dateibasierten Rootkits (Abbildung 2), ist allerdings aufwändig zu installieren.

Abbildung 2: Tripwire schützt vor der ersten Generation von Rootkits. Es verfolgt Veränderungen an bestimmten Dateien.

Die zweite Rootkit-Generation verfolgt einen anderen Ansatz. Statt Systemdateien auszutauschen, um Dateien und Prozesse zu verstecken, modifizieren diese Rootkits den Linux-Kernel, sodass dieser bestimmte Prozesse und Dateien und auch Netzwerkverbindungen nicht mehr anzeigt. Ein Austausch der Befehle ls oder ps erübrigt sich und Tripwire erkennt den Eindringling nicht mehr.

Diese Rootkits arbeiten als Kernel-Module, man nennt sie auch LKM-Rootkits. LKM steht für Loadable Kernel Module (ladbares Kernel-Modul). Das erste weit verbreitete Rootkit dieser Art ist Knark. Um eine Hintertür einzubauen, muss ein Angreifer gewöhnlich entweder eine zusätzliche Anwendung installieren oder eine vorhandene austauschen. Diesen Austausch erkennt Tripwire aber womöglich. Hierfür bietet Knark eine zusätzliche Lösung.

Angenommen, der Angreifer möchte den Secure-Shell-Server gegen eine modifizierte Variante austauschen, die ihm automatisch Root-Rechte verleiht. In diesem Fall installiert er seine modifizierte Shell zusätzlich zur originalen Shell auf dem System. Anschließend weist er den Kernel an, den modifizierten SSH-Server zu verbergen und bei einem nur lesenden Zugriff auf den SSH-Server die originale unveränderte Datei auszuliefern. Führt der Nutzer den SSH-Server hingegen aus, kommt die vom Angreifer modifizierte Datei zum Zuge. Tripwire liest die originale Datei ja lediglich und stellt daher keinen Austausch fest.

Um sich vor diesen LKM-basierten Rootkits zu schützen, verwenden viele Administratoren keine modularen, sondern monolithische Kernel. Sie kompilieren alle benötigten Treiber fest in den Kernel ein. Will ein Angreifer dann einen Treiber austauschen oder installieren, muss er den Kernel erneut kompilieren.

Die dritte Generation von Rootkits umgeht auch diese Hürde. Sie ermöglicht es dem Angreifer, den monolithischen Kernel zu kompromittieren. Diese Fähigkeit beruht auf der Tatsache, dass der Benutzer root Schreibzugriff auf den gesamten Arbeitsspeicher und damit auch auf den Kernel-Code besitzt. Das erste Rootkit dieser Art war 2001 KIS (Kernel Intrusion System). Dieses musste der Angreifer noch speziell für den Kernel auf dem Opfersystem anpassen. Moderne Rootkits (etwa Suckit) kompromittieren indes fast jeden beliebigen Kernel. Die Rootkits enthalten Code, um sich selbst in den Kernel-Speicher zu laden, und brauchen die Unterstützung des Kernels nicht mehr. Ein monolithischer Kernel schützt hier also nicht.

Schutz vor der 3. Generation

Leider gibt es keine einfache Möglichkeit, sich vor dieser Generation von Rootkits zu schützen. Drei Ansätze kommen in Frage:

• Kein Nachladen von Kernel-Modulen erlauben: Werkzeuge wie LIDS oder SELinux verbieten dem Benutzer root das Laden von Kernel-Modulen und das Schreiben des Kernel-Speichers. Leider erweist sich ihre Konfiguration als sehr aufwendig und fehleranfällig. AppArmor bietet keinen Schutz.
• Einbruch auf dem System verhindern: Gelangt der Einbrecher nicht in das System, kann er auch kein Rootkit installieren. Um dies zu gewährleisten, sollten Sie alle Softwarepakete auf dem neuesten Stand halten. Zusätzlichen Schutz bieten eine Firewall und ein Intrusion Detection System [2,3,4]. Den zur Zeit besten Schutz erhalten Sie, wenn Sie weitere Werkzeuge wie AppArmor, LIDS oder SELinux einsetzen [5]. Diese Werkzeuge überwachen die laufenden Anwendungen. Nutzt ein Angreifer eine Sicherheitslücke in diesen Anwendungen aus, um eine Shell zu starten, Programme nachzuladen oder Zugriff auf das System zu erhalten, verhindern diese Tool das mit der richtigen Konfiguration. Aufgrund ihrer Komplexität würde eine ausführliche Erläuterung jedoch den Rahmen dieses Artikels sprengen.
• Es hilft zudem immer, wenn Sie das System regelmäßig überprüfen.

Such das Rootkit

Scheuen Sie den Aufwand, den AppArmor oder SELinux erfordern, und hegen Sie zugleich den Verdacht, dass Sie ein Rootkit an Bord haben, suchen Sie mit verschiedenen Werkzeugen nach dem Schädling.

Neben Hausmitteln wie ls, netstat, lsof stehen Ihnen auch einige Spezialwerkzeuge zur Verfügung, denn mit den Hausmitteln kommen Sie häufig nicht weit. Versteckt ein Kernel-Rootkit einen offenen Port, zeigen netstat und lsof diesen nicht mehr an. Die Suche bleibt vergebens. Das bekannteste Spezialwerkzeug heißt chkrootkit, ein vergleichbares Tool nennt sich rkhunter. Die Programme suchen nach Anzeichen bereits veröffentlichter und analysierter Rootkits. Leider kennen fähige Einbrecher auch diese Werkzeuge und passen den Code des Rootkits entsprechend an. Daher suchen chkrootkit und rkhunter auch nach weiteren generischen Merkmalen eines installierten Rootkits. Speziell bei Kernel-Rootkits haben die Helfer häufig Erfolg.

Sie spielen die Werkzeuge recht einfach und mit Root-Rechten auf Ihr System. Als Nutzer von Ubuntu oder Suse Linux installieren Sie die Software auch direkt über den jeweiligen Paketmanager, erhalten dann aber nicht unbedingt die neueste Version.

Alternativ laden Sie eine aktuelle Version von Chkrootkit [6] als tar.gz-Archiv von der Webseite herunter. Entpacken Sie das Archiv, übersetzen Sie das Programm mit make und rufen Sie anschließend mit Root-Rechten ./chkrootkit auf. Geben Sie dem Aufruf die Option -q mit, spuckt Chkrootkit nur Warnungen aus.

Rkhunter [7] entpacken Sie ebenfalls und installieren es – als Root – über den Aufruf ./installer.sh. Der Befehl rkhunter startet das Tool, mit der Option --quiet gibt es nur Warnungen aus. Die Abbildungen 3 und 4 zeigen jeweils die Ausgaben der Befehle unter Fedora Core 6.

Abbildung 3: Chkrootkit arbeitet nicht immer perfekt und schlägt mitunter Fehlalarm. Benutzer führen das Programm immer mit Root-Rechten aus.

Abbildung 4: Rkhunter knabbert an fehlenden MD5-Prüfsummen. Daher kann die Software einige Dateien nicht überprüfen.

Die Ergebnisse zeigen, dass die Werkzeuge durchaus Probleme mit der Analyse haben. So stuft Chkrootkit einige Dateien und Prozesse zu Unrecht als verdächtig ein; Rkhunter verfügt noch nicht über aktualisierte MD5-Prüfsummen, um die Dateien der Distribution zu verifizieren. Speziell bei Chkrootkit müssen Sie selbst tätig werden, um Prozesse und Dateien zu analysieren, wozu Sie jedoch entsprechendes Hintergrundwissen brauchen. Bei Rkhunter besteht weniger Handlungsbedarf. Unterstützt Rkhunter Ihre Distribution, dient es als recht ordentliches Mittel, um Ihren Rechner zu überprüfen, und erfordert nur wenig manuelle Korrekturen.

Fazit

Besser fahren Sie generell, wenn Sie einen Einbruch verhindern und so die Installation eines Rootkits ausschließen. Spielen Sie also alle Updates zeitnah ein und schalten Sie nicht benötigte Dienste ab. Jeder zusätzliche erreichbare Dienst auf einem System stellt ein mögliches Sicherheitsrisiko dar.

Diese Vorsichtsmaßnahmen schützen Sie allerdings nicht vor Angreifern, die bislang unbekannte Sicherheitslücken ausnutzen. Hier helfen – richtig konfiguriert – Werkzeuge wie AppArmor, LIDS oder SELinux.