Dipl.-Inform. Carsten Eilers

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.

Kommentare

Ansicht der Kommentare:
Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben






Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.



Standard-Text Smilies wie 🙂 und 😉 werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!