Erkennung des Virus Linux/Rst-B
Sophos stellt ein Tool zur Erkennung des Linux-Virus Rst-B bereit. Dieser Artikel analysiert das Tool und gibt einige Hintergrundinformationen.
Vorwort
Ein Blog-Beitrag der Sicherheitsfirma Sophos machte am 13. Februar die Runde durch die Nachrichtenticker: »Botnets, a free tool and 6 years of Linux/Rst-B«. Bei so manchem Ticker lasen sich die Schlagzeilen so, als würden Botnetze hauptsächlich aus Linux-Rechnern bestehen, was im Widerspruch zu allem bisher Bekannten stehen würde.
Sechs Jahre Linux/Rst-B
Liest man den Original-Artikel, stellt sich die Lage etwas anders dar. Sophos betreibt, wie viele andere Sicherheitsexperten auch, sogenannte Honeypots. Das sind Rechner, die ein vermeintlich attraktives und mehr oder weniger leicht zu eroberndes Ziel für Angreifer aller Art darstellen. Sie sind jedoch präpariert, um jegliche Angreife genau aufzuzeichnen und damit Aufschlüsse über Methoden und Werkzeuge der Kriminellen zu erhalten. Die Tatsache, dass es sich um Fallen handelt, wird nahezu perfekt verschleiert. Honeypots kann man auch mit Open-Source-Tools aufsetzen.
Bereits im November 2007 hatte Sophos über seine Linux-Honeypots berichtet. Sie seien weniger häufig angegriffen worden als die Windows-Rechner, doch erstaunlicherweise seien viele der Programme, die die Angreifer hochgeladen hatten, mit dem Virus Linux/Rst-B infiziert gewesen. Obwohl dieses Virus bereits seit 2002 existiert, kann es sich auch auf aktuellen Distributionen noch fortpflanzen. Es richtet eine Hintertür auf dem befallenen Rechner ein, wenn es zur Ausführung kommt, und infiziert alle Programmdateien im aktuellen Verzeichnis und in /bin. Das Einrichten der Hintertür erfordert laut Sophos aber Privilegien, dafür dürfte nur Root in Frage kommen.
Nun kann es kaum die Absicht der Angreifer gewesen sein, Dateien auf dem Rechner zu infizieren, in den sie eingebrochen sind, denn damit steigt die Wahrscheinlichkeit ihrer Entdeckung. Ziel der Angreifer ist jedoch meist, unentdeckt den Shell-Account für Spam-Versand und andere kriminelle Aktivitäten zu nutzen. Laut Sophos kann also nur eine unabsichtliche Verwendung von infizierten Hacker-Tools vorliegen. In Windows-Kreisen soll es häufig vorkommen, dass Hacker-Tools infiziert sind, so dass die Urheber der Infektion die Arbeit des Knackens von Accounts von unwissenden anderen Hackern ausführen lassen und sich letztlich der Rechner bemächtigen, die andere für sie geknackt haben. Betrogene Betrüger, so hat es den Anschein.
Wie relevant ist Rst-B nun in der Praxis? Von Infektionen in nennenswertem Umfang ist unter Linux noch nichts bekannt. Vielleicht ist es für die Kriminellen schwieriger als unter Windows, infizierte Dateien an den Mann zu bringen. Denn die bekannten Linux-Downloadseiten sind kaum zu unterwandern. In den wenigen Fällen, in denen Server kompromittiert wurden, wurden manipulierte Dateien schnell entdeckt. Da das Einrichten der Hintertür anscheinend Root-Privilegien erfordert und nur unbelehrbar dumme Anwender als Root ins Netz gehen, trifft das Problem auch nur die, die es verdienen.
Im neuesten Bericht schreibt Sophos nun, dass in 70% der Hacker-Software, die auf die Honeypots hochgeladen wurde, das Rst-B-Virus zu finden war. Weiter erläutert der Bericht, warum Linux-Rechner für Kriminelle ein attraktives Ziel bieten: Viele laufen als Server rund um die Uhr und eignen sich gut zur Steuerung einer großen Zahl infizierter Windows-Rechner (Zombies).
Offensichtlich benötigen die Cracker solche Steuerungsrechner in weit geringerer Zahl als Zombies. Über tatsächliche Einbrüche schweigt sich Sophos jedoch aus. Es wird nur festgestellt, dass die meisten Einbrüche über schwache SSH-Passwörter stattfinden. Die Ausnutzung von Sicherheitslücken spielt eine untergeordnete Rolle. Die meisten Einbrüche könnten also bereits durch einen konsequenten Umgang mit Passwörtern vermieden werden.
Aufgrund des Alters von Rst-B fantasierten einige Publikationen von »sechs Jahre alten Sicherheitslücken« in Linux. Zumindest wirkte es auf mich so, und das war der Anlass zu diesem Artikel. Nichts könnte jedoch weiter von der Wahrheit entfernt sein. Eine Sicherheitslücke ist hier nicht im Spiel.
Das Rst-B-Erkennungsprogramm
Wie gesagt, es ist unbekannt, welche Rolle Rst-B in der Praxis spielt, und ich halte es für ziemlich unwahrscheinlich, dass Sie je damit in Berührung kamen. Die meisten Anwender, mich eingeschlossen, wussten bis vor kurzem nicht einmal, dass es Rst-B gibt. Die Anzahl der bekannten Linux-Schadprogramme ist sehr gering und die in der Praxis aufgetretenen sind noch spärlicher. Dennoch kann es nicht schaden, zu diesem Anlass einmal die Probe aufs Exempel zu machen.
Zur Erkennung von Rst-B stellt Sophos ein C-Programm bereit. Nachdem man die Lizenz (BSD-artig) anerkannt hat, kann man das Tool herunterladen. Es kommt als Archiv detection_tool.tar.gz und enthält den Quellcode, der lediglich aus einer Datei und einem Makefile besteht, sowie ein vorcompiliertes Programm.
Da es keine Garantie gibt, dass das vorcompilierte Programm dem Quellcode entspricht, der im Paket enthalten ist, untersuchen wir den Quellcode eingehend, bevor wir das Programm compilieren oder ausführen. Da bereits im Makefile Schadsoftware ablaufen könnte, müssen wir auch diese Datei untersuchen. Das ist in diesem Fall einfach. Die Aufrufe des C-Compilers und von rm zum Aufräumen sind unverdächtig. Gehen wir zum C-Code über.
Die Datei detection_tool.c besteht aus 567 Zeilen Quellcode, Kommentare und Leerzeilen mitgerechnet. Im ersten Teil des Quellcodes befinden sich unverdächtige Definitionen, Hilfsfunktionen sowie der bekannte CRC-32-Algorithmus. Der Test, ob eine Datei infiziert ist, erfolgt in der Funktion is_infected. Diese mappt die geöffnete Datei in den Speicher, das ist eine bekannte Technik, um Dateien schneller zu lesen als mit einem einfachen read(). Der Rest der Funktion besteht aus Vergleichen, teilweise unter Verwendung von CRC-32.
Der restliche Quellcode besteht aus Funktionen, um eine Datei zu öffnen, was ausschließlich lesend geschieht, Verzeichnisse rekursiv nach allen Dateien zu durchsuchen, und der Funktion main, die die Argumente verarbeitet und alles startet.
Die schnelle Untersuchung zeigt, dass das Programm keine Dateien ändern kann und nicht aufs Netzwerk zugreift. Die einzige Ausgabe erfolgt auf die Standardausgabe. Fragwürdige Konstrukte gibt es nicht.
Nach dieser Erkenntnis generieren wir das Programm mit make.
