Skip to content

Rootkits - Schadsoftware im System

Rootkits sind mit die schlimmsten Vertreter von Schadsoftware. Ihre Aufgabe: Sich selbst möglichst tief im System verankern und danach alles tun, um eine Entdeckung zu verhindern. Sie sind heutzutage nur noch selten allein anzutreffen, meist sind sie Bestandteil eines umfangreicheren Schädlings, zuständig für dessen Tarnung und Erhalt.

Rootkits - Unix als Namensgeber

Rootkits stammen ursprünglich aus dem Unix-Umfeld. Ihre ursprüngliche Aufgabe bestand darin, die Aktionen eines erfolgreichen Angreifers, der sich Administrator-Rechte (unter Unix eben die des Benutzers root) beschaffen konnte, vor einer Entdeckung zu verbergen.

Die ersten Varianten der Unix-Rootkits bestanden einfach aus einem präparierten Daemon wie telnetd oder sshd zum Öffnen einer Hintertür und einer Reihe modifizierter Tools wie ps zur Anzeige laufender Prozesse oder ls zum Anzeigen von Verzeichnislisten, die beim Aufruf die zum Rootkit gehörenden Prozesse und Dateien nicht anzeigten. Außerdem wurden die Logfiles manipuliert bzw. das Eintragen verdächtiger Vorgänge verhindert. Nachdem ein Angreifer sich einen root-Zugang verschafft hatte, installierte er das Rootkit, um seine weiteren Zugriff zu verschleiern und seine Spuren zu verwischen.

Von Unix zu Windows und darüber hinaus

Inzwischen gibt es auch Rootkits für andere Systeme, insbesondere Windows, Mac OS X und Smartphones, sowie für Kernel und User Mode bzw. Userland. Während die Kernel-Rootkits sich direkt im Betriebssystem-Kernel einnisten, klinken sich die vor allem unter Windows verbreiteten Userland-Rootkits über verschiedene API-Methoden in alle relevanten Prozesse ein.

Ein Spezialfall der Rootkits sind Bootkits, Kernel-Rootkits, die den Bootloader durch eigene Code ersetzten und daher noch vor dem Betriebssystem geladen werden. Dadurch können sie alle danach geladenen Schutzfunktionen unterlaufen, wie z.B. eine Festplattenverschlüsselung oder die Prüfung zu ladender Kerneltreiber.

Bootkits - Rootkits im MBR

Wie so oft, begann alles mit der Theorie: Derek Soeder und Ryan Permeh vom Sicherheitsunternehmen eEye präsentierten auf der Sicherheitskonferenz Black Hat USA 2005 das eEye BootRootKit als Proof of Concept für Schadsoftware, die aus dem Bootsektor heraus den Windows-NT-Kernel manipuliert (Paper als PDF). Ende 2007 wurde ein darauf basierendes MBR Rootkit "in the wild" entdeckt. Das Rootkit überschreibt den Master Boot Record der Festplatte mit eigenem Code, der sich beim Booten in den Kernel einhängt und damit die Kontrolle über das System erlangt. Die ersten Versionen wurden im Rahmen von Drive-by-Infektionen über kompromittierte Websites verbreitet.

Das vorerst namenlose MBR Rootkit verbreitete sich von Anfang an erstaunlich schnell - oder auch nicht, je nachdem, welcher Quelle und welchem Antiviren-Hersteller man weniger misstraut.

Nun ist es ziemlich unpraktisch, ein MBR Rootkit als MBR Rootkit zu bezeichnen (auch wenn manche Menschen ihren Hund Hund nennen), so dass es bald "Mebroot" genannt wurde. Oder auch "Sinowal" bzw. "Sinowa" nach dem installierenden Trojaner, oder aber auch "StealthMBR".

Vielleicht wäre "MBR Rootkit" ja doch kein so schlechter Name gewesen... Spass beiseite (obwohl der jetzt eigentlich erst richtig anfängt): Erst mal ist es ein altes und leidiges Problem, dass die Antivirenhersteller unterschiedliche Namen für den gleichen Schädling verwenden, was bei der Flut an neuen Schädlingen gar nichts ausbleiben kann. Und dann tritt hier ein zweites Problem zu Tage:

Ist dieser Schädling denn nun ein Bootkit, der von einem Trojaner installiert wird, oder ein Trojaner, der ein Bootkit installiert? Nicht zu vergessen, dass es ja auch eine Drive-by-Infektion ist, die ohne Zutun des Benutzers installiert wird, so dass es ja per definitionem kein Trojaner sein kann. Da sich die Grenzen zwischen den verschiedenen Schädlingsarten immer mehr verwischen, gibt es immer mehr Möglichkeiten, einen Schädling einzuordnen und mit einem Namen zu versehen. Betrachten wir nur mal eine Drive-by-Infektion: Die besteht aus dem JavaScript-Code zum Aufruf der Exploits, den Exploits für die verschiedenen Schwachstellen, dem eingeschleusten Schadcode und dem davon nachgeladenen Schadcode. Ob und wie die zusammen gefasst oder einzeln benannt werden, hängt ganz allein von den jeweiligen Entdeckern ab. Und da ein Schädling meist von mehreren Antivirenherstellern parallel entdeckt wird, wird eine Koordinierung kaum gelingen, so wünschenswert sie auch ist.

Im Folgenden werde ich für diesen MBR Rootkit den Namen Mebroot verwenden. Denn hier geht es ja um Rootkits und nicht um den Trojaner, der es installiert.

Nur der Vollständigkeit halber: 2007 veröffentlichten Nitin und Vipin Kumar von NVLabs einen weiteren Proof of Concept für ein Rootkit im MBR, genannt Vbootkit, dass die aktuellste Version von Windows Vista infizieren konnte. Die erste Version von Mebroot lief aber aufgrund mehrerer hardcodierter Adressen nur unter Windows XP. Spätere Versionen waren aber flexibler.

Von Mebroot zu Alureon

Im Mai 2010 berichtete Symantec über Verbindungen zwischen Mebroot und dem Trojaner Tidserv, während Trend Micro eine Verbindung zum Trojaner TDSS meldete. Kein Wunder, denn beide sind identisch - und haben noch einen weiteren Namen: Alureon. Alureon wiederum sorgte im Februar 2010 für Aufregung, weil die Installation der Updates zu Microsofts Security Bulletin MS10-015 auf damit infizierten Rechnern zu einem Blue Screen of Death beim Neustart führte. Auslöser waren hartkodierte Adressen im Rootkit, die in den neu installierten Treibern natürlich nicht mehr passten.

Um Alureon geht es auch in der nächsten Folge, in der auch das "Stoned Bootkit" vorgestellt wird.

Carsten Eilers


Übersicht über alle Artikel zum Thema

Angst einflößende Schadsoftware: Scareware
Ransomware: Geld her, oder die Daten sind weg
Spyware - Der Spion in Ihrem Computer
Viren - Infektiöse Schadsoftware mit langer Ahnenreihe
Würmer - Schadsoftware, die sich selbst verbreitet
Trojaner - Der Feind im harmlosen Programm
Zeus - Trojaner, Botnet, Schädlingsbaukasten, ...
Exploit-Kits - Die Grundlage für Drive-by-Infektionen
Rootkits
Rootkits - Schadsoftware im System
Rootkits gegen Festplattenverschlüsselung und für BSoD
TDL4 - Gefährliches Botnet oder nur eine neue Sau im digitalen Dorf?
SubVirt und Blue Pill - Rootkits mit Virtualisierung
Rootkits für Xen und SMM
Rootkits (fast) in der Hardware
Rootkits für Smartphones und Mac OS X
Remote Administration Toolkits - Fernwartung in der Grauzone
Botnets - Zombie-Plagen im Internet
Schadsoftware - Infektionen verhindern
Schadsoftware im Überblick

Trackbacks

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 3.2014 - JavaScript in Angreiferhand

Vorschau anzeigen
Im windows.developer 3.2014 ist ein Artikel über Angriffe über JavaScript erschienen. JavaScript-Code kann so wie jedes andere Computerprogramm auch Schwachstellen enthalten, und so wie in jeder anderer Programmiersprache kön

Dipl.-Inform. Carsten Eilers am : Wie vertrauenswürdig ist "Hardware" eigentlich?

Vorschau anzeigen
Aus aktuellen Anlass mal eine Frage: Vertrauen Sie ihrem Rechner und ihrem Smartphone? Also dem reinen Gerät, nicht der installierten Software? Wenn ja: Warum eigentlich? Der aktuelle Anlass... Die Chinesen kopieren wirklich alles, wa

Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"

Vorschau anzeigen
Bei entwickler.press ist mein eBook über die Sicherheit von JavaScript erschienen: "JavaScript Security - Sicherheit im Webbrowser" Wie der Name schon sagt geht es um die Sicherheit von JavaScript (und HTML5, dass ja viele neue JavaSc

Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 5: Resident XSS

Vorschau anzeigen
Diesmal geht es um eine Art von XSS-Angriffen, die auf eine herkömmliche XSS-Schwachstelle als Einfallstor angewiesen ist. Denn beim sogenannten Resident XSS wird der Schadcode über eine der bekannten XSS-Schwachstellen (also reflektierte

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.