BIOS-Boot startet was genau? Finde schädliche Boot-Records in großen Umgebungen

Malware nutzt noch immer Komponenten moderner Systeme aus, die schon in den 1980er Jahren entwickelt wurden. Während manche Hacker in immer kürzeren Abständen neue Cyberbedrohungen entwickeln, nutzen andere nach wie vor den konventionellen BIOS-Bootprozess aus, um Unternehmen in aller Welt anzugreifen. Da sogenannte Bootkits (Malware zur Manipulation des Bootprozesses) schon vor dem Betriebssystem gestartet und ausgeführt werden, sind sie oft auch dann noch im System vorhanden, wenn die Incident-Response-Experten glauben, dass sie ein System vollständig wiederhergestellt haben.

In diesem Blogbeitrag beschreiben wir die Herausforderungen, die bei der Untersuchung großer Mengen von Boot-Records auftreten und die Herangehensweise von FireEye bei der Suche nach schädlichen Boot-Records in großen Unternehmensnetzwerken.

Die Herausforderungen

Beim Schutz vor und der Reaktion auf Angriffe in großen Netzwerken treten zwei Arten von Herausforderungen auf.

Einerseits ist die Erfassung von Boot-Records für die Analyse nicht trivial. Sie bestehen aus Master Boot Records (MBR) und Volume Boot Records (VBR). Bootkits sind geradezu berüchtigt dafür, dass sie überschriebenen Boot-Code oft mithilfe sogenannter Hooks oder Einschübe in legitimen APIs verbergen. Wenn Analysten die Boot-Records von der Festplatte im User-Space lesen, fängt das Bootkit diese Lesezugriffe möglicherweise ab und gibt legitim wirkenden Code zurück.

Bootkit: Eine ausgefeilte und spezialisierte Art von Malware, die in einer frühen Phase des Bootprozesses ausgeführt wird und sich daher nur schwer erkennen und entfernen lässt. Weitere Informationen über den Bootprozess und ein VBR-Bootkit finden Sie in unserem Blogbeitrag zu ROCKBOOT.

Andererseits ist es praktisch unmöglich, alle Boot-Records mit Reverse-Engineering-Methoden zu testen. Wenn ein Malware-Analyst prüfen soll, ob ein bestimmtes System mit einem Bootkit infiziert wurde, könnte er eine Kopie der Systemfestplatte erstellen und dann die beim Bootprozess abgearbeitete Zeichenfolge rekonstruieren und nach schädlichen Einschüben durchsuchen. Doch dieser Prozess ist zeitaufwendig und selbst ein ganzes Heer erfahrener Reverse-Engineering-Experten würde nicht ausreichen, um alle Systeme im Netzwerk eines modernen Großunternehmens mit dieser Methode zu überwachen. Nur zur Illustration: Das in unserem Blogbeitrag über ROCKBOOT beschriebene Unternehmensnetzwerk umfasste etwa 10.000 Systeme. Da jedes System mindestens zwei Boot-Records hat (einen MBR und einen VBR), müssten dort also mindestens 20.000 Boot-Records analysiert werden! Manche Leser fragen sich an dieser Stelle vielleicht, warum Sicherheitsexperten in Unternehmen nicht einfach Hashwerte aller Boot-Records erstellen und nur die vom Standard-Image abweichenden Boot-Records analysieren. Schließlich könnte man annehmen, dass die Systeme in einem Unternehmensnetzwerk – und besonders ihre Boot-Records – sich kaum voneinander unterscheiden. Das ist jedoch nicht der Fall. Den MD5-Hashwerten zufolge gibt es in dem oben erwähnten Unternehmen mit 10.000 Systemen beispielsweise 6.000 verschiedene Boot-Records. Tabelle 1 zeigt, wie viele verschiedene Boot-Records wir bei unseren Einsätzen in Unternehmensnetzwerken verschiedener Größe typischerweise finden.

Unternehmensgröße (Anzahl der Systeme)

Durchschnittliche Anzahl unterschiedlicher Boot-Records (MD5)

100-1000

428

1000-10.000

4.738

über 10.000

8.717

Tabelle 1 : Durchschnittliche Anzahl von Boot-Records mit unterschiedlichen MD5-Hashwerten

Jetzt fragen Sie sich vielleicht, wie viele dieser Unterschiede auf die dynamischen Daten in den Boot-Records zurückzuführen sind und ob es möglich ist, einen Hashing-Algorithmus zu entwickeln, der nur bestimmte Abschnitte der Boot-Records berücksichtigt. Das haben wir auch probiert. Für die Master Boot Records haben wir beispielsweise die Bytes in den folgenden beiden Abschnitten genutzt, um den Hashwert zu ermitteln:

md5( offset[0:218] + offset[224:440] )

In einem von uns untersuchten Netzwerk fanden wir mit dieser Methode nur 90 verschiedene MBRs in etwa 185.000 Systemen. Sie hat jedoch auch ihre Nachteile. Insbesondere müssen für Anwendungen wie Altiris, SafeBoot und PGPGuard eine ganze Reihe von Spezialfällen berücksichtigt werden. Dazu muss der Algorithmus für jede Anwendung angepasst werden. Die Anpassungen selbst sind nicht groß, aber im Vorfeld müssen viele Boot-Records mit Reverse-Engineering-Methoden analysiert werden, um die richtigen Werte für die Offset-Operation zu finden.

Nach einigen weiteren Versuchen wussten wir, dass zur Lösung dieses Problems die folgenden Fähigkeiten erforderlich waren:

  • Zuverlässige Erfassung der Boot-Records von Systemen
  • Verhaltensanalyse der Boot-Records, die über eine statische Analyse hinausging
  • Analyse Zehntausender von Boot-Records in einem angemessenen Zeitraum

Im Rest dieses Blogbeitrags beschreiben wir, wie wir diese Herausforderungen bewältigt haben.

Erfassung der Bytes

Bootkits fügen schädliche Treiber in den Stack mit den Festplattentreibern ein, um Lese- und Schreiboperationen abzufangen, wenn sie den Stack passieren. Dadurch hinterlassen sie keine Spuren auf der Festplatte. Um diesen Angriffsvektor zu überwachen, haben wir einen eigenen Kernel-Treiber entwickelt, den wir als „Raw Read“ bezeichnen. Dieser Treiber kann verschiedene Einträge im Festplattentreiberstack lesen. Mit diesem Treiber haben wir den untersten Stackeintrag gefunden und gelesen (Abbildung 1).


Abbildung 1: Schädliche Treiber werden als Filtertreiber in den Stack eingefügt, der „Raw Read“-Treiber liest die Bytes aus dem untersten Eintrag.

So können wir den Rest des Treiberstacks und alle Hooks im User Space außer Acht lassen. (Wichtiger Hinweis: Wenn der unterste Treiber im E/A-Stack einen Inline Code Hook enthält, kann der Angreifer die Lesezugriffe immer noch abfangen.) Außerdem können wir die aus dem untersten Eintrag im Treiberstack mit den äquivalenten, aus dem User Space gelesenen Bytes vergleichen. Wenn diese beiden Zeichenfolgen nicht übereinstimmen, ist dies ein erstes Indiz dafür, dass der Boot-Record manipuliert wurde.

Analyse der Bytes

Wie bereits erwähnt ist es praktisch unmöglich, Hunderttausende von Boot-Records mit Reverse-Engineering-Verfahren und statischen Analysen zu untersuchen. Automatisierte dynamische Analysen, und insbesondere die simulierte Ausführung von Boot-Records, sind hingegen ein praxistauglicher Ansatz. Dabei werden, technisch korrekt ausgedrückt, die Real-Mode-Befehle in einem Boot-Record emuliert.

Als Emulations-Engine haben wir das Unicorn-Projekt genutzt. Unicorn basiert auf dem Softwareemulator QEMU und unterstützt die Emulation im Real Mode mit 16 Bit-Adressen. Die zu analysierenden Boot-Records werden auf den Endpunkten erfasst und an die Emulations-Engine geschickt. Bei der Emulation werden die auf höheren Ebenen verfügbaren Funktionen aufgezeichnet. Dabei kann es sich zum Beispiel um Lese- und Schreibzugriffe auf den Arbeitsspeicher oder auf Festplatten oder um andere Interrupts handeln, die bei der Emulation beobachtet werden.

Der Ausführungs-Hash

Damit die weitere Untersuchung durch menschliche Analysten so effizient wie möglich erfolgen kann, müssen identische analysierte Boot-Records konsolidiert werden. Das wird als „Folding down“ oder „Stacking“ bezeichnet. Ein interessantes Merkmal großer Umgebungen ist, dass es dort oft Boot-Records mit identischer Funktionalität gibt, die aber unterschiedliche Strings, Offsets oder ähnliche Daten enthalten. Diese Duplikate lassen sich nur schwer mithilfe von Hashwerten identifizieren, wie aus Tabelle 1 ersichtlich ist. Kann die Emulation dieses Problem lösen? Sie kann, mit einem „Ausführungs-Hash“. Die Idee ist einfach: Bei der Emulation werden die in jedem ausgeführten Assembler-Befehl enthaltenen mnemonischen Symbole erfasst. Am Ende der Emulation werden nur diese Symbole genutzt, um den Hashwert zu erstellen (zum Beispiel „md5(‘and’ + ‘mov’ + ‘shl’ + ‘or’)). Abbildung 2 zeigt, wie die Assembler-Befehle emuliert und genutzt werden, um den „Ausführungs-Hash“ zu ermitteln.


Abbildung 2: Ausführungs-Hash

Mit dieser Methode lassen sich die über 650.000 verschiedenen Boot-Records, die wir bislang erfasst haben, in knapp über 300 Gruppen mit jeweils identischem Ausführungs-Hash einteilen. Dadurch wird es deutlich einfacher, die Boot-Records zu identifizieren, die genauer untersucht werden sollten. Ein Ausführungs-Hash, der nur auf wenigen Systemen in einem Unternehmen gefunden wird, ist unser zweiter Hinweis auf kompromittierte Boot-Records.

Verhaltensanalysen

Bootkits können (genau wie andere Malware-Varianten auch) sehr unterschiedliche schädliche Aktivitäten ausführen. Wir wollten nicht den alten Fehler wiederholen, für jede Malware-Variante eine eigene Signatur zu erstellen. Deshalb haben wir uns darauf konzentriert, die Verhaltensweisen zu identifizieren, die vom normalen Bootprozess abweichen. Dazu haben wir die bei der Emulation ausgeführten Befehle in eine Analyse-Engine eingespeist. Die Analyse ergab, dass mehrere Bootkits das im Folgenden beschriebene schädliche Verhalten aufweisen.'

Sie fügten Einschübe (Hooks) in die Interruptvektortabelle (IVT) und den Datenbereich im BIOS (BDA) ein, um während des Bootprozesses eintreffende System-Interrupts und Daten abzufangen. Auf diese Art kann ein Angreifer Lesezugriffe auf die Festplatte abfangen und veranlassen, dass die Frage nach der verfügbaren Speichergröße falsch beantwortet wird. Damit können sie verhindern, dass die Bootkits bei einer Durchsuchung der Festplatte oder des Arbeitsspeichers gefunden werden.

Diese Einschübe sind daran erkennbar, dass sie während des Bootprozesses in den für die IVT oder den BDA reservierten Speicherbereich schreiben. Die IVT befindet sich im Speicherbereich von 0000:0000h bis 0000:03FCh und der BDA unter 0040:0000h. Malware kann den Interrupt Handler 13h nutzen, um Schreibzugriffe auf Festplatten während des Bootprozesses einzusehen und zu ändern. Es gibt auch Bootkits, die die vom BDA gemeldete Größe des Arbeitsspeichers ändern, vermutlich, damit das Bootkit im Arbeitsspeicher versteckt werden kann.

Und damit haben wir unseren dritten und letzten Hinweis auf ein infiziertes Bootsystem: verdächtiges Verhalten wie IVT-Hooks, das Dekodieren und Ausführen von Daten auf der Festplatte, verdächtige Bildschirmausgaben und das Ändern von Daten oder Dateien auf der Festplatte.

Skalierung für große Umgebungen

Mit dynamischen Analysen lassen sich Boot-Records deutlich besser analysieren als mit statischen Analysen oder Hashing, doch der damit verbundene Zeitaufwand ist um mehrere Größenordnungen höher. In unserer cloudbasierten Analyseumgebung dauert die Emulation eines Boot-Records im Schnitt 4,83 Sekunden. Wenn wir das oben beschriebene, mit ROCKBOOT infizierte Unternehmensnetzwerk (mit etwa 20.000 Boot-Records) auf diese Weise untersuchen wollten, würde die dynamische Analyse über 26 Stunden dauern! Wir brauchten ein skalierbares Analyseverfahren, dessen Durchsatz mit der von unseren Endpunkttechnologien gelieferten Datenmenge stieg, um unseren Analysten die benötigten Ergebnisse rechtzeitig zu liefern. Die Tatsache, dass in der Regel eine große Anzahl von Boot-Records auf einmal analysiert werden muss – zum Beispiel, wenn wir unsere Endpunkttechnologie bei einem neuen Kunden installieren – macht die Aufgabe noch schwieriger.

Doch mit serverlosem Cloud Computing stand uns eine neue Technologie zur Verfügung, mit der wir einen skalierbaren Service für die emulationsbasierte Analyse entwickeln konnten – und das zu vertretbaren Kosten. Einer der Vorteile von serverlosen im Vergleich zu herkömmlichen Cloud-Instanzen ist, dass keine CPU-Kosten anfallen, wenn der Service nicht genutzt wird. Nur die genutzte Speicherkapazität wird in Rechnung gestellt. Selbst wenn wir für einen neuen Kunden Zehntausende von Boot-Records analysieren müssen, können wir diese Cloud-Lösung schnell auf die erforderliche Kapazität skalieren und eventuelle schädliche Boot-Records nahezu in Echtzeit identifizieren.

Wir haben uns für diese Anwendung für Amazon Web Services (AWS) entschieden. Abbildung 3 zeigt die Architektur im Überblick.


Abbildung 3: Verlauf der Boot-Record-Analyse

Unser Design nutzt derzeit:

  • Ein API-Gateway als Schnittstelle für RESTful-Services
  • Lambda-Funktionen für die Validierung, Emulation und Analyse sowie die Speicherung und Rückgabe der Ergebnisse
  • DynamoDB verfolgt den Fortschritt der Boot-Record-Analyse im System
  • S3 speichert die Boot-Records und Emulationsberichte

Unsere Architektur stellt eine RESTful API mit einer Handvoll Endpunkte bereit. Hier ein allgemeiner Überblick des Arbeitsablaufs:

  1. Endpunkt-Agenten im Netzwerk des Kundenunternehmens nutzen den speziell für diesen Zweck von FireEye entwickelten Kernel-Treiber „Raw Read“ (siehe „Erfassung der Bytes“ weiter oben), um die Boot-Records zu erfassen und an den IR-Server (Incident Response) von FireEye zu schicken.
  2. Der IR-Server schickt die Boot-Records gruppenweise an die auf AWS gehostete REST-Schnittstelle und fragt in regelmäßigen Abständen nach, ob die Ergebnisse der Analyse vorliegen.
  3. Außerdem stellt der IR-Server eine grafische Oberfläche bereit, auf der die Analysten sich die konsolidierten Ergebnisse für das gesamte Unternehmensnetzwerk anzeigen lassen können. Wenn die Analyse schädliche Boot-Records findet, werden automatisch Warnmeldungen angezeigt.

Die REST-API ist über das API-Gateway von AWS zugänglich, das außerdem als Proxy für eingehende Anfragen fungiert und diese an die relevante Lambda-Funktion weiterleitet. Diese als „Submission“ bezeichnete Lambda-Funktion prüft die empfangenen Daten, speichert die auch als „Boot Code“ bezeichneten Boot-Records in S3 und verteilt die eingehenden Anfragen dann auf mehrere Analyse-Lambda-Funktionen.

Die Analyse-Lambda-Funktionen führen die Emulation durch. Da die Lambda-Funktionen nach Bedarf gestartet werden, ist mit diesem Modell ein unglaublich hohes Maß an paralleler Verarbeitung möglich. In AWS können die parallele Verarbeitung von Lambda-Funktionen, die Zuweisung von Speicher- und CPU-Ressourcen u. a. m. mit verschiedenen Einstellungen konfiguriert werden. Wenn die Analyse abgeschlossen ist, wird ein Bericht für den Boot-Record erstellt und in S3 gespeichert. Dieser Bericht enthält die Ergebnisse der Emulation und Metadaten aus dem Boot-Record (zum Beispiel ASCII-Zeichenketten).

Wie oben erwähnt schickt der IR-Server regelmäßig Anfragen an die API-Schnittstelle auf AWS und lädt den Analysebericht hoch, sobald dieser fertig ist.

Big-Data-Analysen finden noch mehr

Der hier beschriebene Prozess zur Identifizierung schädlicher Boot-Records funktioniert nur, wenn wir wissen, nach welchen Hinweisen auf schädliche Aktivitäten oder Ausführungs-Hashes wir suchen müssen. Was geschieht, wenn ein neuer schädlicher Boot-Record (mit einem neuen Hashwert) unbemerkt bleibt?

Um dies zu vermeiden, nutzen wir die unternehmensinterne Big-Data-Plattform, die wir nach der Übernahme von X15 Software in FireEye Helix integriert haben. Wir haben bereits Hunderttausende von Emulationsergebnissen in diese Plattform geladen, sodass unsere Analysten die Ergebnisse schnell durchsuchen können, um verdächtiges Verhalten wie neue Bildschirmausgaben, ungewöhnliche Offsets für Jump-Befehle oder Muster in Lese- und Schreibzugriffen auf Festplatten aufzudecken.

So können neue Boot-Records und Kandidaten für Reverse-Engineering-Analysen identifiziert und damit letztendlich neue Signaturen für die Analyse-Engine erstellt werden.

Fazit

Schon in den ersten Wochen nach dem Einsatz dieser Lösung haben wir in mehreren Kundenumgebungen Systeme gefunden, die mit den verschiedensten Arten von Bootkits infiziert waren, von ROCKBOOT und HDRoot! bis hin zum zugegebenermaßen eher witzigen JackTheRipper, das über Disketten verbreitet wird (kein Scherz). Bislang hat unser System fast 650.000 verschiedene Boot-Records erfasst und verarbeitet, um die in diesem riesigen Heuhaufen versteckten Nadeln (die verdächtigen und schädlichen Boot-Records) zu finden.

Kurz gesagt: Dank der Kombination eines ausgefeilten Verfahrens zur Erfassung von Boot-Records mit einem skalierbaren, serverlosen Cloud-Service und einer automatisierten Emulations-Engine können wir Tausende von Boot-Records in kürzester Zeit analysieren. Diese Lösung wird nun im Rahmen der FireEye-Services Managed Defense und Incident Response eingesetzt.

Danksagung

Dimiter Andonov, Jamin Becker, Fred House und Seth Summersett haben an diesem Blogbeitrag mitgearbeitet.