Login
Login-Name Passwort


 
Newsletter
Werbung

Mi, 21. November 2012, 12:20

Software::Web

Linux/Webserver-Rootkit aufgetaucht

Ein bislang unbekanntes Rootkit klinkt sich als Kernel-Modul in Linux-Systeme ein, um Schadcode in Form von Iframes in allen durch den Webserver ausgelieferten Webseiten abzulegen. Der Sinn des limitierten Schädlings ist nicht klar, doch überrascht vor allem seine Funktionsweise.

Larry Ewing

Linux gilt immer noch als eines der sichersten Systeme. So existieren für das freie Betriebssystem weder nennenswerte Viren, noch sind große Sicherheitslücken bekannt, die das System angreifbar machen würden. Die immer noch größte Gefahr geht von unachtsamen Anwendern aus, die nicht sorgsam genug mit dem System umgehen oder ihre Systeme nicht auf dem neuesten Stand halten. Doch auch Linux-Nutzer sind von bösartiger Software nicht gefeit, wie ein am 13. November entdecktes Rootkit beweist.

So meldete ein Benutzer ein Fehlverhalten auf seinem System, das bis dato unbekannt zu sein schien. Kunden des Unternehmens hatten herausgefunden, dass der Server der Firma mit jeder ausgelieferten Seite ein eingebundenes Iframe transportierte. Die Adresse der Seite zeigte wiederum auf eine externe Quelle, die Code ausführt und Windows-Systeme infiziert. Das Fehlverhalten ging sogar so weit, dass Error-Seiten des Servers das fragliche Konstrukt enthielten, was unter anderem die Schlussfolgerung nahe legte, dass das Problem tiefgründiger sein musste und sich nicht nur auf eine präparierte Seite des Servers erstreckte.

Für das Fehlverhalten zeigte sich nach diversen Untersuchungen ein bislang unbekanntes Rootkit verantwortlich. Der Schädling kommt in Form eines Kernel-Moduls, das speziell für den Kernel 2.6.32-5-amd64 von Debian Squeeze compiliert wurde. Wird das knapp 500 KB große Modul auf einem passenden System geladen, führt es verschiedene Schritte durch. So fügt die Schadensroutine einen Eintrag in /etc/rc.local hinzu, um beim jedem Start geladen zu werden. Ferner extrahiert es die Speicherbereiche der vorhandenen Kernel-Funktionen, um mittels diverser Hooks die Aufrufe von »vfs_readdir()«, »vfs_read()«, »filldir64()« und »filldir()« umzuleiten und durch eigene Funktionen zu ersetzen. Sinn der Aktion ist es die eigene Existenz zu verschleiern. Denn liefert der Kernel in der Ausgabeliste einen Verweis auf eine der Schadensdateien, unterbindet das Rootkit diese Ausgabe. Im Falle der Verschleierung von Prozessen haben die Programmierer allerdings einen Fehler eingebaut, denn diese werden intern unter anderem nach ihrer ID katalogisiert und nicht nach dem Namen, so dass die gestarteten Prozesse durchaus im System sichtbar sind.

Ein weiterer Teil der Modulinitialisierung stellt das Laden des Schadcodes dar. Hier verbindet sich das Modul mit einem Server mittels einer einfachen, durch einen Hash gesicherten TCP-Verbindung und lädt den eigentlichen Schadcode, der verschiedene Formen annehmen kann. Denkbar sind neben der bereits vorhandenen Implementierung als Iframe auch ein Javascript oder direkte HTML-Konstrukte, die Sicherheitslücken von anderen Systemen ausnutzen.

Ist das System präpariert, initialisiert der Schädling die eigentliche Schadensfunktion. Dazu bindet es erneut einen Hook in das System ein und manipuliert die Funktion tcp_sendmsg(), die ein Teil der  TCP-Output-Engine des Kernels darstellt und für den Empfang von SKB-Daten aus dem Userland oder dem Page-Cache verantwortlich ist. Hier ist es dem Rootkit nun auch möglich, in die ausgehende Verbindung eigenen Code einzuschleusen. Dazu überprüft die Funktion, ob diverse Voraussetzungen erfüllt wurden. Unter anderem muss es sich bei den Paketen um den Port 80 und einen bestimmten Content-Typ handeln. Zudem darf die Zieladresse nicht auf einer Liste von insgesamt 1708 gesperrten IP-Adressen erscheinen, die Suchmaschinenbetreibern oder Sicherheitsunternehmen gehören. Entdeckt die Funktion ein Paket, das den zuvor festgelegten Kriterien entspricht, bindet sie den Schadcode direkt in das ausgehende Paket ein.

In Anbetracht der Tatsache, dass es sich um eine weitgehend neue Implementierung handelt, die nicht auf bestehende Rootkits aufsetzt, kann davon ausgegangen werden, dass der Schädling explizit für diesen Zweck erstellt wurde. Ein dedizierter Angriff auf eine bestimmte Seite oder ein System kann anhand der Implementierung weitgehend ausgeschlossen werden. Auch ein ernsthafter Versuch, einen neuen, gefährlichen Schädling unter Linux zu etablieren, kann anhand diverser Indizien als ausgeschlossen gelten. So ist die Funktion des Moduls nur auf einem einzelnen System gewährleistet. Die teils sehr starren Konstruktionen sowohl des Kernelmoduls wie aber auch der Sendeeinheit sind extrem fehleranfällig und führen zudem zu einer schnellen Entdeckung des Tools.

Unklar bleibt der Verbreitungsweg des Schädlings. Das eigentliche Kernelmodul verfügt diversen Untersuchungen nach über keinerlei Reproduzierungsfunktionalität. Dementsprechend bleibt noch zu klären, wie sich das Rootkit auf dem System des Anwenders einnisten konnte. Auch die Frage der Größe des Moduls wirft Fragen auf. So war das Modul weder von Debug-Informationen bereinigt noch optimiert. Die Extraktion der Symbole des Kernels bedient sich primitivster Hilfsprogramme und verzichtet auf typische Kernel-Funktionen. Im Gegensatz dazu weisen andere Bereiche des Codes interessante Ansätze und fortschrittliche Ideen auf. Dementsprechend gehen Beobachter davon aus, dass es sich bei dem Modul um einen Teil eines Systems handelt, das offenbar noch in der Erprobungsphase steckt und noch nicht ganz fertig zu sein scheint. Im jetzigen Zustand erfüllt das Rootkit allerdings nur bedingt seine Aufgabe und taugt nicht für eine ernsthafte Anwendung. Ganz zu schweigen von einem Posten eines ernsthaften, bösartigen Rootkits unter Linux.

Werbung
Kommentare (Insgesamt: 8 || Alle anzeigen || Kommentieren )
systemd (dirk, Sa, 24. November 2012)
Re: Rootkit (blablabla, Do, 22. November 2012)
Re[2]: Kernel Modul als Rootkit? (anonym, Do, 22. November 2012)
Re: Kernel Modul als Rootkit? (rrrrr, Do, 22. November 2012)
Kernel Modul als Rootkit? (Frankes, Mi, 21. November 2012)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung