SEMINARARBEIT

im Studiengang Informationsmanagement und Computersicherheit

Lehrveranstaltung Angewandte Informationssicherheit

BIOS-Rootkit LightEater

In den dunklen Ecken abseits des Betriebssystems

Ausgeführt von:

Hermann Wagner, BSc (1410303021) Dipl.-Ing. Michael Zach (1410303032) Begutachter: Dipl.-Ing. (FH) Mag. Alexander-Philipp Lintenhofer

Ort, Datum

21.6.2015

2

Kurzfassung

Ende März 2015 sorgte eine Sicherheitsmeldung in der Presse für besondere Aufmerk-

samkeit. Auf einer Konferenz haben zwei Forscher präsentiert, wie einfach es heute ist,

Malware zu programmieren, die sich im BIOS einnistet und damit praktisch nicht zu

entdecken geschweige denn wieder zu entfernen ist. Eine Ursache dafür ist der Umstieg auf

UEFI, eine einheitliche Spezifikation zur BIOS Entwicklung, die aber noch zahlreiche

Designfehler und Bugs enthält, aber auf fast allen heute erhältlichen PCs vorhanden ist. Wie

die beiden Sicherheitsexperten auch zeigen konnten wird damit sogar eine Automatisierung

beim Aufspüren und Ausnutzen von Verwundbarkeiten in solchen UEFI BIOS-Implemen-

tierungen möglich. Auch besonders auf Sicherheit hin optimierte Betriebssysteme, welche

nur im Hauptspeicher laufen, sind nicht mehr vor Angriffen sicher, in einer Demo konnte das

BIOS-Rootkit LightEater sogar unbemerkt einen privaten Schlüssel kopieren.

In der vorliegenden Arbeit gehen wir näher auf die Funktionsweise diese Rootkits ein, lernen

verstehen, dass die Arbeitsweise von x86 Prozessoren die eigentliche Grundlage für

LightEater darstellt und überlegen, wie man dieser nicht zu unterschätzenden Gefährdung

technisch und organisatorisch begegnen kann.

3

Inhaltsverzeichnis

1 Einleitung ............................................................................................................... 4

2 Technische Analyse ............................................................................................... 5

2.1 Benötigtes Vorwissen ............................................................................................ 5

2.1.1 Bootvorgang .......................................................................................................... 5

2.1.2 BIOS vs. UEFI ....................................................................................................... 8

2.1.3 x86-Prozessor Betriebsmodi und Schutz ............................................................... 9

2.1.4 System Management Mode ..................................................................................11

2.1.5 Rootkits .................................................................................................................13

2.2 LightEater – How it works .....................................................................................15

2.2.1 Der Angriff – Schritt für Schritt ...............................................................................15

2.2.2 UEFI erlaubt einfachere Rootkit-Entwicklung ........................................................17

2.2.3 UEFI-Monokultur sorgt für die Verbreitung von Vulnerabilities ..............................17

2.2.4 Eine Flut an UEFI Vulnerabilities ...........................................................................18

2.2.5 Fehler im UEFI-Design selbst ...............................................................................18

2.3 Technische Gegenmaßnahmen ............................................................................19

2.3.1 Maßnahmen die nichts nützen ..............................................................................19

2.3.2 Wirkungsvolle Maßnahmen seitens der Hersteller ................................................24

2.3.3 Wirkungsvolle Maßnahmen seitens der Anwender ................................................25

3 Konsequenzen für Unternehmen ..........................................................................26

3.1 Auswirkungen .......................................................................................................26

3.2 Organisatorische Gegenmaßnahmen & Kosten ....................................................27

4 Fazit ......................................................................................................................29

Literaturverzeichnis ..............................................................................................................30

Abbildungsverzeichnis ..........................................................................................................36

Tabellenverzeichnis ..............................................................................................................36

4

1 Einleitung

In den Sicherheitsmeldungen zu LightEater, wie zum Beispiel auch derjenigen auf Heise

Security [1] wird kurz beschrieben, dass es diesem BIOS Rootkit gelingt, Tails Linux [2],eine

auf Sicherheit optimierte und nur im RAM laufende Distribution, so zu unterwandern, dass

ein im laufenden Betrieb vorübergehend von einem externen Medium geladener GPG-

Schlüssel kopiert und an den Angreifer übermittelt werden kann.

Dieser Meldung liegt ein auf der CanSecWest 2015 [3] gehaltenen Vortrag „How Many

Million BIOSes Would you Like to Infect?“ zugrunde, zu dem es nicht nur die

Präsentationsunterlagen [4] sondern auch ein Whitepaper [5] gibt. Besonders interessant ist

natürlich auch die Demo selbst, die als Video [6] im YouTube Channel [7] von LegbaCore [8],

zu finden ist, wo es auch noch weitere LightEater Demos [9] gibt, auf die in den Unterlagen

verwiesen wird. LegbaCore ist dabei das mittlerweile von den beiden Vortragenden

gegründeten Unternehmen, das sich auf BIOS Security spezialisiert hat und nach dem

Voodoo Heiligen Papa Legba [10] genannt wurde.

Der Vortrag ging wie ein Lauffeuer durch die Medien und wurde auch in manchen

Diskussionsrunden [11] eifrig diskutiert. Das ist umso bemerkenswerter, als es in den

vergangenen Jahren bereits zahlreiche andere ähnliche Vorträge gab, deren Brisanz aber

offenbar nicht so wahrgenommen wurde, wie in diesem Fall. Zu nennen wären hier etwa

„Attacks on UEFI Security“ [12] [13] und „Extreme Privilege Escalation“ [14] [15] auf der

DEFCON [16].

Dabei war auch der Inhalt des Vortrages selbst wesentlich weiter gefasst und mindestens

ebenso erschütternd, wie die eigentliche Demo zu LightEater. Es wurde nämlich gezeigt, wie

die Ablösung des herkömmlichen BIOS durch UEFI neben allen damit verbundenen

Vorzügen doch auch zu einer Software-Monokultur führt und dass es zahlreiche Design-

Fehler und Bugs gibt, die nun plötzlich fast alle in den letzten Jahren auf den Markt

gekommenen Systeme betreffen.

Während viele Hersteller unzureichend darauf reagieren können Angreifer nun aber

Automatismen zur Auffindung und Ausnützung solcher UEFI Verwundbarkeiten einsetzen.

Dabei ist ihnen ein wahrlich durchschlagender Erfolg gewiss, da auch die allermeisten

Anwender sich nicht um Updates des UEFI/BIOS ihrer Systeme kümmern, selbst wenn

solche vom Hersteller angeboten werden.

5

2 Technische Analyse

BIOS Rootkits gehören wohl zu den komplexesten Formen von Malware. Dabei kann man

sie jedenfalls zu der Klasse der „Advanced Persistent Threats“ (APT) [17], zählen, das ist

Malware, die sehr fortgeschritten ist und damit nur schwer entdeckt werden kann.

Gleichzeitig nistet sie sich tief in die befallenen Systeme ein und ist kaum mehr zu entfernen.

Meist wird in Zusammenhang mit APTs darauf hingewiesen, dass es sich hier um

maßgeschneiderte Schadsoftware handelt, die wegen ihrer zielgerichteten aber geringen

Verbreitung schwer zu entdecken ist und deshalb lange unbemerkt operieren kann. Dennoch

sehen wir keine Widerspruch darin, auch ein BIOS Rootkit wie LightEater als APT zu

bezeichnen, selbst wenn es prinzipiell eine sehr weite Verbreitung finden kann.

Denn seine prinzipielle Unentdeckbarkeit durch herkömmliche Verfahren der Malware-Suche

und seine wahrhafte Persistenz im Flash-Memory des UEFI/BIOS sorgen dafür, dass auch

eine massenhafte Verbreitung gepaart mit sorglosem Verhalten von Herstellern und

Anwendern zu nicht weniger drastischen Konsequenzen führen, als andere APTs dies tun.

2.1 Benötigtes Vorwissen

Bevor wir uns LightEater näher ansehen, soll zuerst noch das dafür benötigte Grundwissen

über die Technologien vermittelt oder aufgefrischt werden, welche von diesem „BIOS-

Rootkit“ ausgenutzt werden.

Dabei beschränken wir uns auf den Kontext dieser Arbeit und versuchen im Text nicht zu

sehr in die Tiefe zu gehen, ermöglichen dem Leser dies aber durch entsprechend zahlreiche

Literaturverweise.

2.1.1 Bootvorgang

Wird ein Computer neu eingeschaltet, so ist eine Initialisierung und schrittweise

Inbetriebnahme aller seiner Komponenten notwendig. Dabei ist es zu diesem Zeitpunkt noch

nicht möglich, etwa auf eine Festplatte zuzugreifen, um von dort weitere Programme zu

laden, weil ja auch noch keine Steuerprogramme für die Festplatte laufen. Damit diese aber

laufen können, müssen sie im Speicher stehen, der ist zu diesem Zeitpunkt aber noch je

nach Typ mit mehr oder weniger zufälligen Werten gefüllt und es läuft noch kein Programm,

welchen ihn auf einen anfänglichen Ausgangswert setzt und in der Folge verwaltet.

Man erkennt also recht schnell, dass anfänglich eine bestimmte Abfolge einzelner Schritte

notwendig ist, um einen Computer in Betrieb zu bringen, wobei jeder dieser Schirtte durch

ein entsprechendes Programm umgesetzt wird, das dann die Grundlage bereitet für den

nächsten darauf aufbauenden Schritt bzw. die Ausführung des zugehörigen Programms.

6

Dieses „sich selbst hochziehen“ wird im Englischen „bootstrapping“ genannt, oder kurz

„booting“ [18] oder „Bootvorgang“. Dabei muss nun aber das allererste Programm bereits

startbereit im Speicher stehen, weil es ja wie oben erläutert, noch von keinem

Peripheriegerät geladen werden kann, und deshalb verwendet man hier ROM Speicher,

welcher das Programm fix und nicht überschreibbar enthält und auch im stromlosen Zustand

nicht verliert.

An dieser Stelle sei darauf hingewiesen, dass wir uns hier auf Computersysteme der x86 und

x86-64 Architektur beziehen und andere Architekturen in ihrem Bootvorgang deutlich davon

abweichen können!

BIOS

Dieses allererste Programm wurde BIOS [19] genannt, was für „Basic Input Output System“

steht und wir werden uns im nächsten Abschnitt näher damit auseinandersetzen. Für den

Moment aber genügt es zu wissen, dass es alle Hardware-Komponenten des

Computersystems, die für das weitere booting notwendig sind initialisiert und danach den

Code des nachfolgenden „BootLoader“ genannten Programmes in den Hauptspeicher lädt

und von dort startet.

BootLoader

Damit das BIOS den Programmcode des BootLoaders einfach finden kann, steht dieser

immer an einer ganz bestimmten Stelle des verwendeten Speichermediums, nämlich

entweder im Master Boot Record (MBR) [20], einem Abschnitt ganz am Anfang des Medium

oder bei neueren Systemen am Beginn einer Partition [21], also eines Speicherabschnittes

auf dem Medium, deren Position wiederum in einer Tabelle gespeichert ist, entweder im

MBR oder bei neueren Systeme als GUID Partition Table [22] daran anschließend.

Die Aufgabe des BootLoaders ist es in jedem Fall, das eigentliche Betriebssystem in Gang

zu setzen, und daher ist er in der Regel bereits spezifisch für das jeweilige Betriebssystem.

Linux [23] [24] verwendet hier LILO [25] oder die später entwickelte Alternative GRUB [26]

als BootLoader, welche beide selbst wieder in verschiedenen „stages“ ihre Aufgaben erfüllen

und sich vor allem darin unterscheiden, dass GRUB seine Konfigurationsdaten bereits aus

gängigen Dateisystemen lesen kann, wohingegen LILO auf die Daten aus dem MBR

beschränkt ist.

Unter Windows [27] wurde mit NT der BootLoader NTLDR [28] eingeführt, der in seinen

Aufgaben noch ziemlich genau den BootLoadern unter Linux entspricht. Später dann mit

Vista [29] wurde der Bootvorgang in Vorbereitung auf die Einführung von UEFI neu

strukturiert und ein „Windows Boot Manager“ eingeführt, der eine Reihe neuer Möglichkeiten

7

zum Debugging und Reparieren während des Bootvorgangs bietet, und der dann erst den

eigentlichen Betriebssystem-BootLoader aufruft.

Abbildung 1: Abfolge von Prozessen bei Inbetriebnahme eines Systems

Betriebssystem-Kernel

Zuerst startet der BootLoader nun den sogenannten Kernel, wie der Name schon andeutet

den Kern des Betriebssystems, der sich um Ein- und Ausgabe, Speichermanagement,

Prozessverwaltung und Interprozesskommunikation kümmert. Auch gilt es verschiedenste

Geräte über spezielle Treiber-Programme anzusteuern. Schließlich ist es dann endlich

möglich und auch an der Zeit, die „eigentlichen Programme“ zu starten, die der Benutzer

dann auch als solche wahrnimmt.

Betriebssystem Dienstprogramme

Dafür verantwortlich ist ein erster Prozess, welcher dann alle weiteren startet und als „init“

bezeichnet wird; unter Linux findet man ihn entsprechend als /sbin/init, unter Windows

als wininit.exe.

Von diesem nun werden die System-Dienstprogramme gestartet, unter Linux „deamons“ und

unter Windows „services“ genannt. Diese Programme laufen in der Regel bereits im

sogenannten „userspace“, d.h. sie verfügen über geringere Privilegien als die eigentlichen

Prozesse des kernels.

Ist das Betriebssystem soweit am Laufen, startet es typischerweise ein Programm, das es

dann Benutzern erlaubt, sich mit dem System zu verbinden, nennen wir es hier „Shell“ [30],

unabhängig davon, ob es als graphische Benutzeroberfläche oder text-orientierte

Kommandozeile implementiert ist. Von dieser Shell aus, können Benutzer nun eigene

Anwendungsprogramme auszuführen.

8

Anwendungsprogramme

Diese stellen für den Benutzer vordergründig den meisten Nutzen dar und ermöglichen ihm,

seine Arbeit zu erledigen. Da alle diese Programme mit den geringsten Berechtigungen

laufen und keinen direkten Zugriff mehr auf Speicher und andere Geräte haben, müssen sie

entsprechende Aufgaben an das Betriebssystem delegieren, welches umgekehrt dafür sorgt,

dass viele solcher Anwendungsprogramme nebeneinander ablaufen können, ohne einander

zu stören, zu blockieren oder sich Ressourcen wegzunehmen.

Beim Herunterfahren eines Systems werden die meisten der genannten Schritte in

umgekehrter Richtung durchlaufen: Zuerst werden alle laufenden Anwendungsprogramme

beendet, dann die laufenden Shells beendet und damit die Benutzer vom System getrennt.

Als nächstes werden die Dienstprogramme beendet, danach führt der Betriebssystem-Kernel

noch abschließende Aufräumarbeiten aus, wie etwa das Zurückschreiben

zwischengespeicherter Daten auf die jeweiligen Datenträger. Ganz zum Schluss wird durch

einen entsprechenden Aufruf von in der Firmware hinterlegten Routinen zur

Energieversorgung eine Abschaltung der Stromzufuhr erreicht oder der Benutzer

aufgefordert, dies selbst vorzunehmen.

Nun aber kehren wir nochmals ganz an den Anfang zurück, und sehen uns das BIOS und

dessen Nachfolger UEFI näher an.

2.1.2 BIOS vs. UEFI

Wir haben das BIOS eingangs als die Software kennengelernt, die gleich nach dem

Einschalten des Systems aktiv wird, alle für den Bootvorgang benötigten Komponenten

initialisiert und dann den BootLoader aufruft und so in weiterer Folge das Betriebssystem in

Gang bringt. Nun sind hier noch zwei Ergänzungen wichtig:

Das BIOS wurde nur ganz zu Beginn wirklich in ROM abgelegt. Dies hat sich auf die Dauer

nicht wirklich bewährt, da man jedes Mal den zugehörigen Baustein auswechseln musste,

um ein Update durchzuführen. Daher ging man später dazu über, Flash-Speicher [31] zu

verwenden, welcher seine Inhalte im stromlosen Zustand ebenfalls behält, aber im

Gegensatz zu ROM überschrieben werden kann, was es leicht machte, BIOS updates rein

per Software durchzuführen, gleichzeitig aber auch die Geburtsstunde von BIOS Rootkits

markiert.

Weiter ist anzumerken, dass jede Weiterentwicklung von Prozessoren, Speichern,

Bussystemen und sonstiger auf dem Motherboard untergebrachter Komponenten eine

Änderung der dafür verantwortlichen Programmteile des BIOS nach sich zogen, was dazu

führte, dass jedes BIOS individuell auf dieses jeweilige „Chipset“ [32] zugeschnitten werden

musste und die Hersteller meist nur die erste Zeit nach Neueinführung eines solchen auch

9

Updates des zugehörigen BIOS bereitstellten, dann aber rasch das Interesse daran verloren

hier weiter Fehler zu beheben und Schwachstellen zu korrigieren, sobald das System

einigermaßen stabil lief und sich wie üblich lieber dem nächsten neuen Produkt zuwandten.

Mit der Zeit wurde so immer mehr Funktionalität in eine unüberschaubare Vielfalt an

verschiedenen BIOS-Varianten und Versionen gesteckt, welche ursprünglich fast alle, meist

durch Reengineering, aus einem einzigen von Intel entwickelten Ur-BIOS hervorgegangen

waren. Auch sind im BIOS einige Einschränkungen etwa bezüglich Anzahl und Größe von

Partitionen gegeben, die nicht mehr dem Stand der Technik entsprechen.

Um nun einen sauberen Neustart zu schaffen und einen Nachfolger für das in die Jahre

gekommene BIOS zu (er)finden, war es wiederum Intel, die mit der Entwicklung eines

Extensible Firmware Interface (EFI) begannen. Diese Spezifikation wurde später als Unified

EFI (UEFI) [33] in ein Konsortium führender Hardware- und BIOS-Hersteller eingebracht,

welches seither als UEFI Forum [34] die Entwicklung vorantreibt.

Heute sind die überwiegende Mehrzahl aller neu auf den Markt gebrachten Systeme mit

UEFI ausgestattet, mit Version 8 ist dieses für Windows sogar obligatorisch. Auch alle

anderen gängigen Betriebssysteme sind mittlerweile mit UEFI zu betreiben.

Zu den konkreten Unterschieden zwischen BIOS und UEFI gibt es zahlreiche Quellen [35]

[36] [37] [38], daher sei hier nur auf die für diese Arbeit wichtigsten verwiesen:

UEFI stellt, wie es der Name schon sagt, primär eine Schnittstelle zwischen Hardware-

spezifischer Firmware und dem Betriebssystem dar. Dabei kann es das BIOS vollständig

ersetzen, aber auch mit einem solchen koexistieren, indem es dieses quasi kapselt.

Darüber hinaus bieten UEFI-Systeme noch eine BIOS-Emulation, welche sich Compatibility

Support Module (CSM) nennt.

UEFI bringt bereits einen BootManager mit, den Betriebssysteme nur noch zu nutzen

brauchen, und der mit dem alten Problem aufräumt, dass bei der Installation mehrerer

Betriebssysteme die verschiedenen mitinstallierten BootLoader einander überschreiben.

Damit reduzieren sich diese nun auf reine Betriebssystem-Loader wie zuvor bei der

Beschreibung des Boot Prozesses ab Windows Vista bereits erwähnt. UEFI bietet darüber

hinaus auch Sicherheitsfeatures wie „Secure Boot“ [39] [36], wobei vor dem Bootvorgang

geprüft wird, ob es sich um vertrauenswürdigen, entsprechend signierten Code handelt.

2.1.3 x86-Prozessor Betriebsmodi und Schutz

Die Prozessoren der x86 Familie wurden im Verlauf ihrer Weiterentwicklung mit immer

neuen Funktionen ausgestattet, mussten aber gleichzeitig abwärtskompatibel bleiben. Daher

10

kennen sie verschiedene Betriebsmodi, welche sie beim Bootvorgang durchlaufen und

zwischen denen sie dann auch später im laufenden Betrieb hin und her wechseln können,

um verschiedene Aufgaben zu erfüllen.

Hier die für das Verständnis dieser Arbeit wichtigsten Betriebsmodi:

Real Mode

Hierbei [40] handelt es sich um den Betriebsmodus des ursprünglichen 8086 Prozessors, der

noch unbeschränkten direkten Zugriff auf den gesamten adressierbaren Speicher- und I/O-

Adressen sowie alle Peripheriegeräte besitzt.

Protected Mode

Ab dem 80286 Prozessor eingeführt bietet dieser [41] Betriebsmodus Unterstützung für

sicheres Multitasking an, indem er u.a. die Adressierung virtuellen Speichers und damit die

saubere Trennung einzelner Prozesse voneinander erlaubt.

Zusätzlich wurden „Protection Ring“ [42] genannte Sicherheitsstufen für Prozesse eingeführt,

welche diese hinsichtlich verwendbarer Befehle und benutzbarer Speicherbereiche

einschränken.

Abbildung 2: Betriebsmodi und Schutzring-Konzept der x86er Prozessoren

Der Kernel des Betriebssystems läuft im innersten Ring 0, die zugehörigen Prozesse dürfen

quasi alles tun. Die nachfolgenden beiden Ringe 1 und 2 sind vor allem für andere

Betriebssystem-Prozesse sowie Treiber vorgesehen und schränken die Privilegien bereits

ein. Gewöhnliche Anwendungsprogramme laufen entsprechend im äußersten Ring 3 mit den

geringsten Berechtigungen.

11

Die Idee dabei ist, dass Prozesse ohne entsprechende eigene Privilegien beim

Betriebssystem anfragen müssen, um bestimmte Aufgaben, wie etwa Zugriffe auf

Peripheriegeräte, zu erledigen, und damit diesem allein die Kontrolle über die Zuteilung

dieser Ressourcen obliegt.

Long Mode und Compatibility Mode

Mit der Erweiterung der x86 Architektur auf 64-bit ermöglichen diese Modi ein

Nebeneinander von 64-bit Programmen (long mode) und 32/16-bit Programmen

(compatibility mode). [43]

Hardware-Virtualisierung

Neben diesen eigentlichen Betriebsmodi weisen die x86 Prozessoren auch diverse

Erweiterungen zur Unterstützung von Hardware-Virtualisierung auf, auf die hier aber nicht

näher eingegangen werden soll. [44]

Einen Modus haben wir bei obiger Auflistung bewusst übersprungen und hier an den Schluss

gestellt, obwohl er serienmäßig bereits mit dem 80486 eingeführt wurde und von zentraler

Bedeutung für das Verständnis der in dieser Arbeit dargestellten Ideen ist.

2.1.4 System Management Mode

Der SMM [45] [46] ist ein Betriebsmodus zur Erledigung spezieller Funktionen wie etwa

Energiemanagement und Hardware-Steuerung. Dabei unterbricht der Prozessor die

Ausführung aller laufenden Prozesse in anderen Modi, führt vorübergehend Programme für

diese speziellen Funktionen aus und setzt dann die unterbrochenen Prozesse wieder fort.

Dies geschieht auf völlig transparente Weise, die Prozesse können gar nicht feststellen, dass

sie unterbrochen wurden. Auch sind ihre Privilegien hierbei unbedeutend, der SMM

unterbricht sowohl normale Anwendungsprozesse wie auch höchstprivilegierte

Betriebssystem-Prozesse.

Der Übergang in den System Management Mode wird durch eine System Management

Interrupt (SMI) ausgelöst, dieser kann nicht maskiert d.h. ignoriert werden, und es gibt 3

Arten ihn auszulösen:

1. direkt auf der Hardware über einen eigenen Pin des Prozessors

2. indirekt per Software durch Zugriffe auf bestimmte privilegierte Ports

3. indirekt per Software durch Lese- oder Schreibzugriffe auf Adressen, welche die

Firmware zur Auslösung eines SMI gekennzeichnet hat

Nach Auslösen eines SMI stoppt der Prozessor sofort die Ausführung weiterer Instruktionen

auf allen Cores und wartet bis alle noch laufenden abgeschlossen sind, schließlich können

diese ja verschieden viele CPU Zyklen lang dauern Dann werden die Inhalte aller Prozessor-

12

Register in einen speziellen Bereich im RAM, das sogenannte System Management RAM

(SMRAM) [47] kopiert und dort aufbewahrt. Zugriffe auf das SMRAM erfolgen über ein

eigenes nur im SMM verfügbares Register, damit ist es für alle anderen Betriebsmodi

unsichtbar.

Abbildung 3: Ausführen von Software im SMM

Nun wird der Instruction Pointer auf den Beginn des SMI-Handler Codes im SMRAM gesetzt

und in den SMM umgeschaltet. Damit startet diese 16 Bit-Software und wird auf nur einem

Core ausgeführt, kümmert sich um Temperatur- oder Energiemanagement oder tut

irgendetwas anderes, von dem nichts sie abhalten kann, ausgenommen eine Unterbrechung

der Stromzufuhr. Dabei verfügt der SMI-Handler über allerhöchste Privilegien, die sogar

diejenigen des Betriebssystem-Kernels auf Ring 0 übertreffen, kann alle Befehle ausführen

und auf den gesamten physischen Speicher sowie auch weiterhin auf das SMRAM

zugreifen.

Befindet sich der Prozessor im SMM, so kann dieser nicht unterbrochen werden, weder

durch einen weiteren SMI noch durch irgendeinen anderen Interrupt. Erst wenn der SMI-

Handler am Ende seines Treibens angelangt ist und den Prozessor durch die nur dafür

gedachte Instruktion RSM explizit wieder freigibt, wird der SMM verlassen, der

Prozessorstatus aus dem SMRAM wiederhergestellt und damit die Ausführung der zuvor

unterbrochenen Prozesse wieder so fortgesetzt, als wäre nichts geschehen.

Tatsächlich gibt es aber doch Möglichkeiten für die in anderen Betriebsmodi laufenden

Prozesse, festzustellen, dass der SMM aktiv war.

In einem eigenen Register wird bei jedem SMI ein Zähler [48] hochgezählt, sodass daraus

die Anzahl dieser Interrupts ermittelt werden kann. Dieses Register kann vom SMM aus aber

geschrieben werden, und damit ist nicht sichergestellt, dass es nicht manipuliert ist.

13

Ein anderer Ansatz besteht darin, die vom SMM „gestohlenen“ Prozessorzyklen durch

Vergleich der von allen laufenden Prozessen verbrauchten Zyklen mit der auf der Echtzeituhr

vergangenen Zeit zu ermitteln. Auch verrät sich der SMM selbst durch Anomalien im

Stromverbrauch des Prozessors, vorzeitiges Zurückschreiben von Caches andere

unabsichtlich ausgelöste Nebeneffekte [49].

Abbildung 4: Unterbrechung beliebiger Prozesse durch den SMM

Soweit vorerst zum allmächtigen SMM, wir werden später noch sehen, was damit alles

möglich wird.

2.1.5 Rootkits

Unter einem „Rootkit“ [50] versteht man Software, welche auf einem System unbemerkt

bestimmte Dateien und laufende Prozesse versteckt, und damit auch sich selbst tarnt.

Meist erfolgt die Installation nach einem Einbruch in ein Computersystem, um auch nach

einem Neustart oder Änderung der Zugangsdaten weiterhin eine Hintertür („Backdoor“ [51])

zum erneuten unbefugten und unbemerkten Zugang offenzulassen oder um Schad-

programme („Malware“ [52]) einzuschleusen und vor Gegenmaßnahmen zu schützen.

Es sind in der Vergangenheit aber auch schon einzelne Fälle [53] [54] bekannt geworden, in

denen von bekannten Unternehmen Rootkit-ähnliche Techniken für DRM [55] und andere

Kopierschutz-Verfahren verwendet wurden.

Je nachdem, auf welcher Systemebene ein Rootkit platziert wird, kann man grob etwa diese

fünf Typen voneinander unterscheiden.

Application-Rootkits: Hierbei ersetzt das Rootkit einzelne Dateien eines Anwendungs-

programms oder verändert dessen Verhalten, indem es eigenen Programm-Code darin

einfügt, welcher bei der Ausführung der Anwendung dann sein Werk verrichtet.

14

Library- oder Userland-Rootkits: Diese nisten sich in Programmbibliotheken ein, die von

mehreren Anwendungen oder gar Dienstprogrammen verwendet werden, und erhöhen damit

die Wahrscheinlichkeit, zur Ausführung zu gelangen. Wenn solche Wirtsprogramme dann

auch noch mit höheren Privilegien auf dem System operieren, kann damit auch das Rootkit

davon Gebrauch machen.

Kernel-Rootkits: Gelingt es ein Rootkit im Betriebssystem-Kernel selbst oder in einem von

diesem meist ohne weitere Sicherheitsmechanismen angesprochenen Gerätetreiber zu

verankern, so hat dieses natürlich maximale Möglichkeiten sich zu tarnen und die ihm

zugedachten Aufgaben durchzuführen. Aus dieser Position heraus kann es andere laufende

Programme kontrollieren und deren Funktionsfähigkeit beeinträchtigen.

Virtual(ising) Rootkits: Hier schafft es das Rootkit, sich in den Bootprozess einzuklinken

(dann oft auch „Bootkit“ genannt) und aktiv zu werden, bevor das Betriebssystem geladen

wird. Das Rootkit übernimmt dann die Rolle eines Hypervisors [56] und startet das

eigentliche Betriebssystem in einer virtuellen Maschine, womit es über dieses und alle darauf

ausgeführten Anwendungen volle Kontrolle erhält. [57] [58]

Alle bisher genannten Typen von Rootkits können aber mit geeigneter Software zur Laufzeit

erkannt werden und es können Maßnahmen ergriffen werden, ein solches Rootkit

vergleichsweise einfach wieder zu entfernen. Bei Application- und Userland-Rootkits kann

hierbei das Betriebssystem entsprechende Schutzmechanismen implementieren und mit

Antivirensoftware können diese in der Regel aufgespürt und deaktiviert werden.

Auch Kernel-Rootkits kann das Einnisten deutlich erschwert werden, indem man die

unautorisierte Veränderung sogenannter „hooks“ [59] verhindert, also sicherstellt, dass

Systemaufrufe direkt durchgeführt werden und sich keine fremde Software wie etwa ein

Rootkit „dazwischendrängen“ kann. Einen solchen Ansatz verwendet etwa HookSafe [60].

Bootkits und damit Hypervisor-Rootkits können vor allem durch Absicherung des Boot-

Prozesses unterbunden werden, hier spielt u.a. der Einsatz von TPM [61] und UEFI Secure

Boot [39] eine große Rolle.

Ganz anders sieht das aber nun beim fünften Typ aus, der sich in der Firmware eines

Computersystems ansiedeln kann und in zwei Subtypen anzutreffen ist:

Firmware-Rootkits im engeren Sinne, das sind solche bei denen das Betriebssystem und

die die Anwendungssoftware gleichsam als Firmware realisiert ist, wie etwa bei Embedded

Devices oder Appliances wie Firewalls. Damit liegt hier eigentlich eine in der Firmware

persistierte Variante eines Kernel-Rootkits vor. Besonders verdient gemacht um die

15

Entwicklung solcher Firmware Rootkits hat sich hierbei die NSA, welche vor allem auf

Hardware-Firewalls abgezielt [62] [63].

BIOS-Rootkits eigentlich besser „SMM-Rootkits“, das sind solche, die sich im BIOS oder

UEFI(-BIOS) eines x86 Computersystems verstecken und damit im System Management

Mode ausgeführt werden, was sie nicht nur perfekt tarnt, sondern ihnen vor allem vollen

Zugriff auf das gesamte System gewährleistet. Rootkits dieses Typs wurden in den letzten

10 Jahren mehrfach vorgestellt [64] [65] [66], auch hier hat die NSA wieder ihren Beitrag [67]

geleistet.

Die dieser Arbeit zugrundeliegende Sicherheitsmeldung nun zeigt, wozu ein solches Rootkit

imstande ist und wie die Ignoranz auf Hersteller- wie auch Benutzerseite dazu führt, dass

unzählige Systeme gefährdet sind und wohl auch bleiben werden.

2.2 LightEater – How it works

Nach diesem allgemein gehaltenen Teil können wir uns nun ansehen, wie ein BIOS Rootkit,

in diesem Fall LightEater, funktioniert und warum es sich so tief auf einem System einnisten

kann.

2.2.1 Der Angriff – Schritt für Schritt

Die eingangs geschilderte Demo von LightEater, wie man sie auf eine Video [6] sehen kann,

läuft im Wesentlichen in folgenden Schritten ab:

1. auf das Zielsystem verbinden und dort Administrator-

Rechte erlangen. In der Demo wird hier eine offene

Windows Session per RDP übernommen.

2. Ausführen eines Programmers, welcher das mit

LightEater infizierte BIOS Image ins Flash des

angegriffenen Systems schreibt.

Anmerkung zu den Schritten 1 und 2: Voraussetzung für die Infektion mit

LightEater ist in jedem Fall, dass auf dem System bereits Administratorrechte erlangt

wurden. Das kann zuvor durch andere Malware geschehen sein. Nur dann können

ein Flash-Programmer gestartet werden, oder UEFI-Mechanismen und

Schwachstellen(!) zum Update des BIOS verwendet werden.

Abbildung 4a

16

3. Angreifer trennt die Verbindung wieder und öffnet ein

Terminal, welches auf eine serielle Verbindung

wartet.

4. Solange das Zielsystem weiterläuft, ist das Rootkit

noch nicht aktiv. Irgendwann jedoch wird es neu

gestartet und bei der erstmaligen Ausführung des

BIOS wird auch der Code von LightEater mit

ausgeführt und eine Serial-over-LAN [68] Verbindung

zum Terminal des Angreifers aufgebaut.

Anmerkung zu den Schritten 3 und 4: Das SoL Protokoll wurde gewählt, weil es

nicht einmal von WireShark [69] erkannt und analysiert wird, ebenso wenig wie von

den gängigen IDS [70] und damit einen idealen Weg darstellt, um Datenpakete

unerkannt über das LAN zu übertragen. Alternativ könnte das Rootkit aber auch den

Schlüssel auf dem System verstecken und später im normalen Windows-Betrieb

anderweitig exfiltrieren.

5. Das Zielsystem bootet nun Tails Linux von einem USB Stick. LightEater ist die ganze

Zeit aktiv und lauert.

6. Ist das System am Laufen, wird irgendwann ein

zusätzlicher USB-Stick mit dem Private Key des

Benutzers angesteckt, und um den dann etwa zum

Entschlüsseln von Emails oder Dateien verwenden

zu können, muss er durch Import in den KeyRing auf

das System gebracht werden.

7. Jetzt schlägt LightEater zu, kopiert sich den

Schlüssel aus dem Speicher und überträgt ihn

zurück zum Angreifer. Ziel erreicht!

Anmerkung zu den Schritten 6 und 7: LightEater läuft ja im System Management

Mode, damit hat das Betriebssystem keine Chance Daten vor ihm zu verstecken.

Auch der sorgsame Umgang mit Datenresten im Hauptspeicher, den Tails pflegt,

nützt gar nichts!

Voraussetzung für diesen Angriff ist es aber immer noch, dass das BIOS entsprechend

verändert und Code eingeschleust werden kann. Ein „heißer Tipp“ diesbezüglich ist nach wie

vor VU#552286 [71], welche es erlaubt, durch bloßes Überschreiben einer UEFI-

Systemvariable ein Update des UEFI/BIOS zu erzwingen.

Abbildung 4c

Abbildung 4b

17

2.2.2 UEFI erlaubt einfachere Rootkit-Entwicklung

Wurden in früheren Jahren von vielen verschiedenen Herstellern eigene proprietäre BIOS

Varianten weiterentwickelt, so mussten auch Angriffe auf das BIOS durch sehr aufwändiges

Reverse Engineering erfolgen und waren zudem auf einzelne Hersteller beschränkt.

Mit UEFI wurde ab etwa 2006 nun ein neuer Weg beschritten. Ziel war es, eine einheitliche,

von Betriebssystem und BIOS-Hersteller unabhängige Spezifikation für die Funktionsweise

eines BIOS bereitzustellen. Gleichzeitig wurde auch ein Programmier-Framework entwickelt,

das es den Herstellern fortan erlaubt, nur noch ihre eigenen spezifischen Programmteile

einfügen zu müssen, und so zu einem lauffähigen UEFI/BIOS zu kommen.

Man kann diesen sauberen Schritt hin zu einem ordentlichen Software Engineering durchaus

begrüßen. Leider erlaubt er es aber nun auch Angreifern diese Methoden zu verwenden und

mit ebenfalls von UEFI bereitgestellten Tools [72] [73], einfach nachträglich lauffähige BIOS-

Images abzuändern und eigenen Code einzuschleusen.

2.2.3 UEFI-Monokultur sorgt für die Verbreitung von Vulnerabilities

Gleichzeitig kann online automatisiert und sehr effizient nach verwundbaren UEFI/BIOS

Updates gesucht werden, die auf den Websites der Hersteller angeboten werden. Die Idee

dabei: Finde bestimmte Muster in den Funktionsaufrufen im UEFI-Framework, die auf

bekannte verwundbare Module verweisen und suche nach diesen „Signaturen“. Teddy Reed

hat in seinem Vortrag [74] [75] gezeigt, wie man das hoch-skalierbar tun kann, indem er

dafür eine eigene UEFI Spider [76] entwickelt hat. Diese findet UEFI Updates und leitet sie

an einen UEFI Firmware Parser [77] weiter, der aus dem binären Daten, den lauffähigen

Code rekonstruiert. Eine automatische Analyse [78] kann dann nach solchen Signaturen

suchen.

Das Ergebnis ist erschreckend: Von 2158 analysierten BIOS Images, wiesen nur 7 keine der

3 vorgegebenen Signaturen auf. Bei einer ähnlichen, später mit anderen Signaturen von

LegbaCore durchgeführten Suche waren es nur 5 von 1003 Images, die keine

Verwundbarkeiten aufwiesen. Das bedeutet in beiden Untersuchungen deutlich weniger als

1% der untersuchten BIOS Images sind nicht verwundbar – und das schon nur hinsichtlich

dieser nur 3 Schwachstellen!

18

2.2.4 Eine Flut an UEFI Vulnerabilities

Dabei steigt seit Jahren die Zahl der neu entdeckten Vulnerabilities stetig an, wie folgende

Auswahl zeigt:

Jahr CERT.org VU# Nickname Verweis

2008 VU#127284

2012 VU#255726 „The Sicilian“

2013

VU#758382 „Setup bug“ [79]

VU#291102 „Charizard“

2014

VU#552286 „King & Queen’s Gambit“ [71]

VU#533140 „noname“ [80]

VU#766164 „Speed Racer“ [81]

VU#912156 „Ruy Lopez” [82]

VU#976132 „Venamis“ [83]

2015 VU#577140 „Snorlax“

VU#631788

Tabelle 1: UEFI Vulnerabilities

Dabei sind die kursiv gehaltenen Vulnerabilities nicht veröffentlicht worden. Und es gibt noch

deren viele, welche bislang keine VU# bekommen haben oder die wohl gar nicht erst

gemeldet wurden.

Die Presse berichtet zwar immer wieder von neuen Schwachstellen [84] [85] [86] [87],

trotzdem bleibt der Eindruck, als würde das seitens mancher BIOS-Hersteller nicht ernst

genug genommen, gerade wenn man deren Reaktionszeiten mit denen von Betriebssystem-

Herstellern vergleicht.

2.2.5 Fehler im UEFI-Design selbst

Es sind aber nicht nur Bugs, die hier angeführt sind, sondern auch Schwachstellen und

grundsätzliche Fehler im Design des UEFI Frameworks.

So etwa auch Vulnerability Note VU#631788 vom 20.3.2015 mit dem Titel „Multiple BIOS

implementations permit unsafe SMM function calls to memory locations outside of SMRAM“

[88].

Und tatsächlich: In UEFI gibt es ein Schnittstelle, über die man mittels Software einen SMI

auslösen kann. Praktischerweise lässt sich diese auch noch entsprechend parametrisieren

und sorgt dafür, dass der vom ausgelösten SMI aufgerufenen Handler dann eine

Speicherstelle im ACPI RAM ausliest und an die dort angeführte Adresse verzweigt.

19

Dieses ACPI RAM befindet sich aber im ungeschützten Speicher, darauf kann also von

normalen Prozessen aus zugegriffen werden und die Sprungadresse so abgeändert werden,

dass dann im System Management Mode beliebiger Code anderswo im ungeschützten

Speicher ausgeführt wird!

Abbildung 5: UEFI SwSMI Interface

Auf Systemen mit dieser Lücke braucht man also das UEFI/BIOS gar nicht erst zu flashen.

2.3 Technische Gegenmaßnahmen

Dieses Kapitel behandelt die technischen Auswirkungen und Gegenmaßnahmen und

schließt somit unsere technische Betrachtung ab. Die organisatorischen Maßnahmen

werden gesondert in Kapitel 3 behandelt.

Primäres Ziel bei der Bekämpfung von Rootkits muss es stets sein, eine Infektion zu

verhindern, denn ein späteres Erkennen und Entfernen ist schwieriger als bei anderen Arten

von Malware, oder vom System selbst aus gar nicht möglich, so wie eben bei BIOS-Rootkits.

Da wir etwa auch in der LightEater Demo wieder gesehen haben, dass die eigentliche

Infektion durch andere Malware vorbereitet wurde, die eben erst die Ausführung mit

Administrator-Rechten erlaubt hat, sind herkömmlich Maßnahmen gegen herkömmliche

Malware durchaus sinnvoll ...

2.3.1 Maßnahmen die nichts nützen

... können gegen ein BIOS Rootkit in der Regel aber nicht viel ausrichten. Hier einige

Beispiele für solche Maßnahmen und Begründungen für deren Wirkungslosigkeit.

20

Betriebssystem von externem Medium starten

Es gibt sogenannte Live-Betriebssysteme (auch Live-Systeme genannt) die direkt, ohne

vorherige Installation, von einer DVD oder einem USB-Stick gebootet werden können und

nur im Arbeitsspeicher des Host-PCs ausgeführt werden. Dadurch wird einerseits das, auf

dem Host-PC installierte, Betriebssystem inklusive aller installierten Programme nicht

ausgeführt und es werden auf dem Arbeitsrechner keinerlei Spuren hinterlassen. Weiters ist

dadurch auch eine Ausführung des Live-Systems möglich, ohne dass der Rechner eine

funktionsfähige Festplatte oder ein funktionsfähiges Betriebssystem installiert hat.

Diese Features sind aus mehreren verschiedenen Gründen interessant und finden zum

Beispiel folgende Anwendungszwecke:

• Testen eines alternativen Betriebssystems

• Erstellen eines kompletten Speicherabbildes (Image) der Festplatte für einen

Systemumzug oder als Backup

• Hardware Diagnose (z.B.: Inquisitor [89])

• Fehlerbehebung & Reparatur

• Datenrettung (z.B.: Parted Magic [90])

• Malware-Entfernung (z.B.: Desinfec’t [91], Kaspersky Rescue Disk)

• Digitale Forensik (DEFT Linux [92])

• Media-Center für Audio- & Videodateien (z.B.: Kodi/XBMC [93] )

• Sicheres surfen auf fremden PCs (z.B.: Lightweight Portable Security [94])

• Sicheres E-Banking (auch am eigenen PC, z.B.: Bankix [95])

• Schutz der Privatsphäre und Anonymität (z.B.: Tails [2])

Mittlerweile gibt es schon bei sehr vielen Linux-Distributionen die Möglichkeit das

Betriebssystem gleich direkt vom Datenträger als Live-System zu starten. Wie in der Liste

oberhalb ersichtlich gibt es aber auch eine Vielzahl an Live-Systemen, die für einen

speziellen Zweck erstellt wurden (z.B.: Malware-Entfernung). Eine gute Übersicht über Live-

Systeme bietet der entsprechende Wikipedia-Artikel [96].

Nun stellt sich vielleicht für den ein oder anderen Leser die berechtigte Frage: „Was haben

Live-Systeme mit LightEater zu tun?“

Die Antwort darauf ist einfach: Da eine LightEater Malware sich im BIOS-Flash einnistet, wird

sie immer mit dem Start des Computers ausgeführt und läuft im System Management Mode,

egal ob danach das Betriebssystem von der Festplatte oder von einer Live-DVD gestartet

wird. Daher hat LightEater auch einen Vollzugriff auf den Arbeitsspeicher und kann auf

jegliche Daten zugreifen, egal wie sicher das Betriebssystem konzipiert wurde. Zusätzlich

kann LightEater jegliche Daten unbemerkt auf die Festplatte schreiben oder gar über das

21

Netzwerk (SoL oder Internet) an einen Server weitergeben, ohne dass der Benutzer etwas

davon merken könnte.

Die Konsequenzen davon sind weitreichend: Kein Live-System der Welt kann auf einen

LightEater infizierten PC ausgeführt werden, ohne dass LightEater Vollzugriff auf das System

hat. Das heißt Live-Systeme können unter anderem folgende Aufgaben nicht mehr

erwartungsgemäß erbringen:

(1) Malware-Entfernung & Datensicherung

Lässt sich ein System nach einem Malwarebefall nicht mehr oder nur eingeschränkt

starten oder wird vermutet, dass sich ein Rootkit eingeschlichen hat, welches

wichtige Systemdateien so verändert hat, dass ein Antivirus, welcher zur Laufzeit des

befallenen Betriebssystems ausgeführt wird, die Malware nicht mehr detektieren

kann, so kommen häufig Live-Systeme zur Entfernung der Malware oder zur

Datensicherung zum Einsatz.

Da LightEater Vollzugriff auf das gesamte System hat und außerhalb des

Betriebssystem läuft, ist es für jegliche Art von Anti-Malware Programmen, die am

Betriebssystem (egal ob installiert oder Live) ausgeführt werden, verborgen und kann

von diesen weder entdeckt noch gelöscht werden. Es kann maximal die ur-

sprüngliche Malware gefunden werden, die zu einer LightEater Infizierung geführt

hat, da diese ja initial am Betriebssystem mit Administrator-Rechten ausgeführt

werden musste um LightEater installieren zu können (sofern der Angreifer nicht

ohnehin einen Vollzugriff aufs System hatte). Doch selbst wenn diese entfernt wird,

so bleibt LightEater noch immer voll funktionsfähig im Biosflash und kann beim

nächsten Systemstart jede beliebige „normale“ Betriebssystem-Malware wieder am

System installieren.

Des Weiteren könnte eine LightEater-Malware jeden Datenrettungsversuch so

manipulieren, dass die Daten fehlerhaft oder erneut mit Malware infiziert vom

befallenen Quellsystem kopiert werden.

(2) Privatsphäre, Anonymität & Vertraulichkeit

Wie schon erwähnt werden Live-Systeme sehr häufig zum Schutz der Privatsphäre,

zum Anonymen surfen und kommunizieren im Internet und fürs sichere Online-

Banking verwendet. Beispiele für solche Live-Systeme sind Tails und LPS. Vor allem

Tails wird sehr häufig und gerne verwendet, da es in Verbindung mit der vorinstal-

lierten Software Tor den Benutzer sehr gut im Internet anonymisiert. Das ist vor allem

für Menschen in den Ländern wichtig, in denen politische Verfolgung und Zensur

noch zur Tagesordnung gehört.

22

Tails funktionierte bis jetzt ausgesprochen gut, denn auch wenn das Host-

Betriebssystem von Malware infiziert ist, so kann durch das Starten des Live-Systems

die Malware nicht ausgeführt werden und ein ausspionieren der Tätigkeiten des

Benutzers wird somit verhindert. Und selbst wenn sich der Benutzer während der

Benutzung des Live-Systems eine Malware einfängt, so ist er maximal für die aktuelle

Session infiziert, da Tails ja jeglichen Zugriff auf die Festplatte blockiert und sich die

Malware somit nicht persistieren kann.

LightEater verändert die Situation drastisch. Denn LightEater wird auch ausgeführt,

wenn ein Live-System gestartet wird und kann daher jegliche Daten abgreifen. Der

Angreifer kann also nachvollziehen was der Benutzer am PC gemacht hat, kann

seine Passwörter und Secret-Keys auslesen und andere Daten stehlen. [2]

Wir sehen also, dass die Entdeckung von LightEater weitreichende Konsequenzen hat, was

Live-Systeme anbelangt und dass die Verwendung eines solchen keinen Schutz vor

LightEater bieten kann.

Rootkit-Scanner von CD oder OS

Auch dieser kann von einem entsprechend programmierten Rootkit getäuscht werden, indem

es etwa Zugriffe auf die eigenen Speicherbereiche auf andere, harmlose umleitet.

UEFI Secure Boot

Mit der Einführung von UEFI, welches z.B. ab Windows 8 verfügbar ist, gibt es eine

Möglichkeit Bootkits auf einem Windows System mit Hilfe von Secure & Measured Boot zu

entdecken. Denn bei UEFI mit aktiviertem Secure Boot, startet die Firmware den Bootloader

nur, wenn dieser eine gültige Bootloader Signatur, die von einer der Zertifizierungsstellen

erstellt wurde, deren Zertifikat in der UEFI Datenbank abliegt, vorweisen kann.

Durch diese Maßnahme ist es einem Bootkit nicht mehr so einfach möglich den MBR zu

überschreiben ohne dass das Ganze unentdeckt bleibt.

Da LightEater es ermöglicht das UEFI selbst zu modifizieren, schafft der Secure Boot

Prozess in diesem Fall keine Entdeckungsmöglichkeit. LightEater bleibt weiterhin verborgen.

[97]

TPM

Das Trusted Platform Module ist ein Device wie jedes andere. Damit ist es jedenfalls für

Man-in-the-Middle Angriffe durch ein BIOS Rootkit anfällig oder kann im Extremfall sogar von

diesem deaktiviert werden.

23

BIOS Integrity Checks

Diese müssten von einem externen, garantiert sauberen System, durchgeführt werden, denn

andernfalls kann im SMM jede Berechnung von Prüfsummen beliebig beeinflusst werden.

IDS

Ein solches könnte vielleicht Spuren von Daten-Ausschleusung entdecken. Erfolgt diese

aber etwas raffinierter, wird es wahrscheinlich zu keinen Warnungen diesbezüglich mehr

kommen.

Festplatte formatieren oder tauschen

Das Rootkit sitzt im UEFI/BIOS Flash-Speicher, nicht auf der Festplatte.

Normalerweise nisten sich herkömmliche Bootkits auf der Festplatte ein, manipulieren den

Master Boot Record (MBR) und verschlüsseln ihren Code. Dadurch laufen sie außerhalb des

Betriebssystems und ein Antivirus kann das Bootkit nicht detektieren, da sämtliche

Komponenten sich außerhalb des Standard-Dateisystems befinden.

Dadurch haben normale Bootkits einerseits keine Auswirkungen auf Live-Systeme (auf die

Festplatte und somit den MBR wird gar nicht zugegriffen, wenn das Live-System gestartet

wird) und andererseits können Bootkits durch spezielle Software wie den TDSSKiller [98]

oder durch eine vollständige und sichere Formatierung der Festplatte inklusive des MBR und

den infizierten Bootsektor entfernt werden. Eine Neuinstallation des Betriebssystems oder

eine Formatierung der Partitionen, so wie sie normalerweise von vielen herkömmlichen Tools

zur Verfügung gestellt wird, überlebt ein Bootkit normalerweise. [99]

Da sich LightEater im Bios Flash einnistet, lässt ihn die vollständige und sichere

Formatierung der Festplatte ziemlich kalt. Selbst ein Tausch der Festplatte bringt nichts. In

beiden Fällen wird wenn, dann nur die Malware entfernt, die für die ursprüngliche Infizierung

mit LightEater zuständig war. Wie schon erwähnt könnte LightEater diese beim nächsten

Systemstart problemlos erneut installieren.

BIOS Update nach einer Infektion

Wie vorhin der integrity check müsste auch ein Überschreiben von einem sauberen System

aus erfolgen, andernfalls kann das Rootkit das ganz sicher verhindern. Doch dafür ist die

gängige Hardware nicht konzipiert, Eingriffe sind schon auf elektrotechnischer Ebene zum

Scheitern verurteilt, weil Bauteile fix verlötetet und Anschluss-Pins und Leiterbahnen durch

mehrschichtige Bauweise und hochpräzise Montage nicht mehr zugängig sind.

24

Weder die Verwendung eines Live-Systems oder von UEFI Secure Boot, noch das

Austauschen der Festplatte schaffen also Abhilfe gegen LightEater. Es bleibt noch eine

Möglichkeit um die Malware loszuwerden: Das Bios mit einer als sicher bekannten Firmware

neu zu flashen. Dabei wird im Normalfall die aktuelle Firmware im Biosflash überschrieben

und somit sollte auch LightEater entfernt werden können.

Problem dabei: Wie flashe ich das Bios neu, ohne dass LightEater dies erkennt und mir den

Flashvorgang manipuliert? Denn der Updatevorgang selbst wird ja auch wieder über das

Betriebssystem angestoßen. Wir haben hier noch keine vernünftige Antwort auf diese Frage

gefunden und es wird sehr wahrscheinlich gar nicht ohne großen Aufwand möglich sein.

Theoretisch kann LightEater den Flashvorgang manipulieren, die Installation blockieren und

im Nachhinein dennoch eine erfolgreiche Installation ans Betriebssystem zurückmelden.

Die einzige Möglichkeit ist also eine präventive Maßnahme zu treffen. Und zwar ein

Bios/UEFI Update durchzuführen, bevor man infiziert wird. Inzwischen haben einige

namhafte Hersteller wie DELL, HP und Lenovo bereits zugesichert spezielle Patches für die

Schwachstellen herauszugeben, die LightEater ausnutzt. Und auch ein Update auf die

aktuellste BIOS Version (ohne die speziellen Patches) bringt schon eine Verbesserung, da

LightEater auch viele alte Bios Schwachstellen ausnutzt und dadurch einfacher aufs System

gelangen kann.

2.3.2 Wirkungsvolle Maßnahmen seitens der Hersteller

Aktuell überlegen sowohl Computerhersteller als auch Sicherheitsexperten und die

Community über Maßnahmen um Angriffe wie LightEater verhindern zu können. Hier ist zu

allererst die aktive Fehlersuche und Bereitstellung von Patches zu nennen. Nur damit lassen

sich Software-seitig Verbesserungen erreichen. Aber es gibt auch andere Ideen, wie man

BIOS-Rootkits hintanhalten kann.

Behebung der Schwächen im UEFI Design

Verwundbarkeiten, wie die im Abschnitt 2.2.5 angeführte, können nur durch eine

grundlegende Überholung des UEFI Frameworks entfernt werden.

Hardware-Schutz vor unbeabsichtigtem Flashen

Hersteller von Mainboards könnten wieder Hardwareschalter einführen, die beim

Startvorgang gedrückt gehalten werden müssen, damit ein Flashen ausgeführt wird.

Hardware-Virtualisierung des SMM

Seitens der beiden großen Prozessorhersteller Intel und AMD gibt es Pläne, dem System

Management Mode nicht mehr volle Gewalt über den Prozessor zu geben, sondern ihn

25

mittels Hardware-Virtualisierung an die Leine zu legen. Dann würde er in einer Virtuellen

Maschine laufen und jedenfalls dem Hypervisor unterworfen sein, daher auch kein Zugriff auf

fremden Speicher aus dem SMM heraus mehr möglich und auch Angriffe erkannt werden.

[100]

Intel Boot Guard

Diese neue Technologie [101] [102] macht den Prozessor selbst zum „root of trust“. Dabei

stammen die ersten Instruktionen, die ausgeführt werden, nicht gleich aus dem womöglich

manipulierten BIOS, sondern aus einem Speicher im Prozessor selbst. Damit könnte erreicht

werden, dass dieser nicht manipulierbare Code eine erste Integritätsprüfung von TPM und

BIOS durchführen kann, ohne von einem Rootkit getäuscht zu werden. IN diesem

Zusammenhang interessant ist auch die

Früherer Einsatz des TPM

Wird bereits von der „Intel Trusted Execution Technology“ [103] [104] umgesetzt.

2.3.3 Wirkungsvolle Maßnahmen seitens der Anwender

Hier ist derzeit in erster Linie das Einspielen verfügbarer BIOS-Updates zu nennen, wobei

die Verwendung einer sicheren Verbindung beim Herunterladen sowie das Überprüfen

angegebener Signaturwerte der einzuspielenden Images selbstverständlich sein sollten!

BIOS Update Management

Im Unternehmens-Kontext wäre die adäquate Maßnahme dazu, die Eingliederung von BIOS-

Updates in den Update Management Prozess sowie eine entsprechenden Unterstützung

durch Software bei der praktischen Durchführung.

26

3 Konsequenzen für Unternehmen

Nachdem wir im vorherigen Abschnitt die technischen Gegenmaßnahmen, ihre Wirksamkeit

und die technischen Auswirkungen erläutert haben, folgt in diesem Kapitel erneut eine

Analyse der Auswirkungen von LightEater, wobei das Augenmerk nun auf den

Konsequenzen aus Sicht der Unternehmen liegt.

3.1 Auswirkungen

Wie schon erläutert, gibt es aktuell keine Host-basierten Entdeckungsmöglichkeiten um

LightEater detektieren zu können. Damit haben wir eine ähnliche Situation in Unternehmen

wie vor der Einführung von Windows 8 (welches sehr viele Unternehmen noch nicht

verwenden). Denn für ältere Versionen des Microsoft Betriebssystems bieten zwar schon ein

paar Antiviren-Hersteller wie Kaspersky einen integrierten Rootkit und Bootkit Schutz, jedoch

ist dieser nicht immer zuverlässig.

Kommt es zu den typischen Anzeichen, wie zum Beispiel dass das Intrusion Detection

System im Netzwerk selbst nach einer Neuinstallation des Betriebssystems auf einem PC,

noch immer verdächtige Kommunikation von diesem protokolliert, dann werden spezielle

Anti-Bootkit Tools vom Systemadministrator ausgeführt (Kaspersky TDSSKiller, Avast

aswMBR.exe, GMER mbr.exe, MBRCheck.exe). Liefern diese Tools auch keine

verdächtigen Anzeichen, so bleibt dem Admin nur mehr ein Austausch des gesamten

Rechners übrig. [105]

Im Falle einer LightEater-Infektion könnte der Admin aktuell in keinen Fall verlässlich

feststellen, ob er infiziert wurde. Die Infektion selbst kann nur durch auffälliges Verhalten des

Rechners (z.B.: Verschlüsselung von Dateien, Spam-Einblendung auf Webseiten,

verdächtige Kommunikation im Netzwerk) und wenn die üblichen Analysen keine Ergebnisse

bringen, vermutet werden. Auch die Entfernung der Infektion, ist nicht zuverlässig möglich.

Daher bleibt in diesen Fall nur der Austausch des Rechners als einzige Option übrig.

Das ist für ein Unternehmen natürlich nicht wirkliche befriedigend, denn es bleibt immer die

Frage und große Sorge: Wurden wir Opfer eines gezielten Angriffs? Wenn ja, auf was haben

es die Eindringlinge abgesehen?

Doch diese Fragen stellen sich auch bei „herkömmlichen“ Advanced Persistent Thread

(APT) Angriffen, bei denen der Angreifer die Angriffsmethode und die verwendete Malware

spezifisch auf das Ziel abstimmt und verschleiert. Auch in diesen Fällen helfen herkömmliche

Antiviren-Programme nicht bei der Detektion und die Malware bleibt für gewöhnlich lange

unentdeckt und kann nur durch netzwerkbasierte Monitoring-Software wie zum Beispiel

Intrusion Detection Systeme an Tageslicht gebracht werden.

27

Vor allem bei hoch-innovativen Unternehmen, staatlichen Einrichtungen (Militär, Polizei, …)

oder auch Einrichtungen mit kritischer Infrastruktur (Energieversorger, Wasserkraftwerke, …)

muss spätestens seit dem Bekanntwerden von LightEater auch genau analysiert werden von

welchem Hersteller und Händler die Computer-Hardware bezogen wird. Denn wer oder was

hindert zum Beispiel andere Staaten oder Geheimdienste daran gezielt schon vor der

Auslieferung der Computer und Server, diese mit LightEater-Malware zu infizieren? Die

Malware kann dann einige Jahre als „Schläfer“ deaktiviert im Biosflash verweilen. Und nur für

den Fall der Fälle (z.B.: in wirtschaftliche Notlagen oder Krieg) hätte man so Zugriff auf die

kritische Infrastruktur des Wettstreiters oder Feindes und könnte diesen auf einfache Art und

Weise einen harten Treffer versetzten.

Doch auch schon bisher war solch ein Szenario denkbar, da es ja auch schon bisher für

Geheimdienste die Möglichkeit gab den Hersteller zu zwingen, eine Backdoor ins Bios

einzubauen oder dass der Geheimdienst selbst vor Auslieferung der Geräte das Bios

manipuliert. Und auch aus den Enthüllungsdokumenten von Edward Snowden geht hervor,

dass die NSA und der GSHQ solche Techniken verwenden und an ähnlichen Ansätzen wie

LightEater forschen. [1]

Mit der Veröffentlichung von LightEater wurde hier nur noch verdeutlicht und bestätigt, dass

das Ganze einerseits keine Fiktion ist und andererseits auch tatsächlich mittels Angriff über

das Internet durchgeführt werden kann.

Aus Sicht der Autoren sind also die Auswirkungen von LightEater in Summe zwar kritisch,

jedoch aus Unternehmenssicht eröffnen sich für Unternehmen keine Angriffsvektoren, die es

nicht auch schon vor LightEater gab und bei der Etablierung der Sicherheitsstrategie

berücksichtigt werden mussten.

3.2 Organisatorische Gegenmaßnahmen & Kosten

Für Unternehmen schlagen wir folgende präventive Gegenmaßnahmen vor (falls diese nicht

ohnehin schon durchgeführt werden):

• Durchführen von regelmäßigen BIOS/UEFI Updates

Ein LightEater-Angriff ist umso einfacher, desto mehr BIOS-Schwachstellen dafür

ausgenutzt werden können. Bisher gibt es zwar noch von keinem Hersteller Patches,

die einen Angriff wirklich sicher verhindern können, jedoch ist Schließen alter BIOS-

Bugs durch Updates durchaus möglich. Daher empfehlen wir Unternehmen die

Verwendung von zentralen Softwareverteilungs-Systemen, welche es auch

ermöglichen BIOS/UEFI Updates durchzuführen.

28

• Zurückgeben / Austausch von PCs von Mitarbeitern, die das Unternehmen

verlassen

Ein frustrierter oder entlassener Mitarbeiter bzw. Praktikant könnte sehr einfach auf

seinem eigenen Rechner LightEater installieren und darauf warten, bis er das

Unternehmen verlassen und sein PC einem anderen Mitarbeiter zugeteilt wird. Um

solch ein Szenario zu verhindern reicht es nicht die Festplatte zu formatieren oder zu

löschen, sondern der PC muss entsorgt werden. Diese Maßnahme erzeugt daher

erhebliche Kosten für das Unternehmen, welche jedoch im Vergleich zu einem

tatsächlichen Angriff wahrscheinlich vertretbar sein werden.

• Deaktivieren von USB-Massenspeichermedien im Betriebssystem

USB-Sticks sind schon seit langem gefährliche Angriffsvektoren für Unternehmen.

Jeder kennt die Geschichte vom „am Parkplatz gefundenen USB-Stick, den ein

Mitarbeiter an seinem Unternehmens-Rechner anschließt um zu sehen was sich

darauf befindet“. Wir empfehlen eine generelle Deaktivierung der Möglichkeit USB-

Sticks an den Rechnern der Mitarbeiter anzustecken (von Betriebssystemseite her).

Zum Datenaustausch können gemeinsam genutzte Serverlaufwerke, Cloud-

Lösungen und Emailaustausch verwendet werden.

• Deaktivieren der Bootmöglichkeit von externen Medien (wie USB oder DVD)

Auch der Bootvorgang von externen Medien sollte deaktiviert werden. Meist gibt es

diese Option im BIOS eines Rechners und die Einstellungen können per Passwort

geschützt werden. Dadurch wäre es einen internen Angreifer (Reinigungskraft,

Mitarbeiter, Einbrecher) nicht mehr möglich bei einem ausgeschalteten Rechner ein

Live-System zu starten und über dieses LightEater aufs System zu bringen.

• Mitarbeitern privilegierte Rechte entziehen

Mitarbeiter sollten auf keinen Fall Administrator-Rechte besitzen, da dadurch auch

jegliche Malware, die das System infiziert Admin-Rechte besitzt und somit in der

Lage ist LightEater am System zu installieren.

Wir empfehlen zwei geschulte Mitarbeiter pro Abteilung solche Rechte zu verleihen,

sodass diese notwendige Installationen oder sonstige Aufgaben durchführen können,

die Administratorrechte verlangen.

• Laptops über Nacht im Schrank versperren

Dadurch wird es erschwert Rechner in irgendeiner Form zu manipulieren und zu

infizieren.

29

• Download von ausführbaren Dateien blockieren

Dateien wie .exe, .jar, .bat, usw. sollten direkt vom IDS blockiert werden um zu

verhindern, dass Malware aufs System gelangt. Zusätzlich muss dann aber auch den

Mitarbeiter die Möglichkeit gegeben werden, an zentraler Stelle einspeisen zu

können, wenn diese unbedingt eine solche Aktion durchführen müssen. Dann kann

die verantwortliche Person entscheiden ob die Datei heruntergeladen werden darf.

• PC-Kauf/Leasing nur von vertrauenswürdigen (europäischen) Herstellern

Um nicht der Gefahr zu laufen, schon von vorneherein ausspioniert zu werden, richtet

sich diese Maßnahme. Wir wissen jedoch, dass es nicht so einfach ist diese

umzusetzen. Es sollte trotzdem eine Analyse der Hersteller durchgeführt werden und

dann eine begründete Entscheidung für einen dieser Hersteller getroffen werden.

• Windows 8 verwenden

Windows 8 bietet einige neue Sicherheitsfeatures, wie zum Beispiel Secure Boot,

welche zwar LightEater nicht wirklich stoppen können, jedoch Bootkits.

• Mitarbeiter schulen

Es ist immer eine gute Idee Awareness und Verständnis für Security-Themen bei

seinen Mitarbeitern zu schaffen!

Wie schon erwähnt sind alle die Maßnahmen präventiv und erschweren es dem Angreifer

nur LightEater aufs System zu bringen. Auch wurde hier vorausgesetzt, dass herkömmliche

Maßnahmen wie Firewalls, IDS, IPS und Antivirensoftware bereits eingesetzt werden.

4 Fazit

LightEater hat für einiges an Aufregung und Aufmerksamkeit gesorgt. Ebenso haben sich die

Vermutungen, dass Geheimdienste solche Techniken einsetzen, noch weiter bestätigt.

In jedem Fall kann LightEater als Basis für einen Advanced Persistent Threat Angriff

verwendet werden, da es so gut wie unmöglich ist eine erfolgreiche LightEater-Installation zu

detektieren. Daher ist es sehr wahrscheinlich, dass in naher Zukunft auch nicht-staatliche

Hacker, welche es auf sensible und geheime Unternehmensdaten abgesehen haben,

LightEater-Techniken für ihre Zwecke verwenden werden.

Aus diesem Grund sollten sich Unternehmen bereits jetzt so gut es geht mit präventiven

Maßnahmen schützen und sich der weiterhin bestehenden Gefahr bewusst sein. Denn bis

sich die PC-Hersteller auf wirksame Gegenmaßnahmen geeinigt haben wird sicherlich noch

einiges an Zeit vergehen.

30

Literaturverzeichnis [1] “BIOS-Rootkit LightEater: In den dunklen Ecken abseits des Betriebssystems,” heise

Security. [Online]. Available: http://www.heise.de/security/meldung/BIOS-Rootkit-LightEater-In-den-dunklen-Ecken-abseits-des-Betriebssystems-2582782.html. [Accessed: 11-Jun-2015].

[2] “Tails Linux.” [Online]. Available: https://tails.boum.org/. [Accessed: 19-Jun-2015]. [3] “CanSecWest Applied Security Conference: Vancouver, British Columbia, Canada.”

[Online]. Available: https://cansecwest.com/agenda.html. [Accessed: 11-Jun-2015]. [4] Corey Kallenberg and Xeno Kovah, “How Many Million BIOSes Would you Like to

Infect?,” 20-Mar-2015. [Online]. Available: http://legbacore.com/Research_files/HowManyMillionBIOSWouldYouLikeToInfect_Full.pdf. [Accessed: 11-Jun-2015].

[5] Corey Kallenberg and Xeno Kovah, “How Many Million BIOSes Would you Like to Infect?,” CanSecWest Vancouver 2015, 20-Mar-2015. [Online]. Available: http://www.legbacore.com/News_files/HowManyMillionBIOSesWouldYouLikeToInfect_Whitepaper_v1.pdf. [Accessed: 11-Jun-2015].

[6] “LightEater Demo: Stealing GPG keys/emails in Tails via remote firmware infection,” YouTube, 05-Jun-2015. [Online]. Available: https://www.youtube.com/watch?v=sNYsfUNegEA.

[7] “LegbaCore - Channel,” YouTube. [Online]. Available: https://www.youtube.com/channel/UCpHRO5NFtnKm2sg3yRTVASg. [Accessed: 11-Jun-2015].

[8] “LegbaCore.” [Online]. Available: http://legbacore.com/. [Accessed: 14-Jun-2015]. [9] “LightEater Demo: Remote ASUS BIOS infection using the Venamis vulnerability,”

YouTube. [Online]. Available: https://www.youtube.com/watch?v=ZkBTABqSMT8. [10] “Papa Legba,” Wikipedia, 16-May-2015. [Online]. Available:

https://en.wikipedia.org/w/index.php?title=Papa_Legba&oldid=662652457. [Accessed: 14-Jun-2015].

[11] “LightEater Malware - AT&T ThreatTraq #136 (3 of 6),” YouTube, 30-Mar-2015. [Online]. Available: https://www.youtube.com/watch?v=RxpBiSVCbW4.

[12] Rafal Wojtczuk and Corey Kallenberg, “Attacks on UEFI Security,” CanSecWest Vancouver 2015, 20-Mar-2015. [Online]. Available: https://bromiumlabs.files.wordpress.com/2015/01/attacksonuefi_slides.pdf. [Accessed: 11-Jun-2015].

[13] “Attacks on UEFI security, inspired by Darth Venamis’s misery and Speed Racer,” Chaos Computer Club. [Online]. Available: http://media.ccc.de/browse/congress/2014/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg.html#video. [Accessed: 11-Jun-2015].

[14] C. Kallenberg, X. Kovah, J. Butterworth, and S. Cornwell, “Extreme Privilege Escalation On Windows 8/UEFI Systems,” The MITRE Corporation. [Online]. Available: http://www.mitre.org/publications/technical-papers/extreme-privilege-escalation-on-windows-8uefi-systems. [Accessed: 11-Jun-2015].

[15] “Extreme Privilege Escalation: Gefährliche Sicherheitslücken in UEFI-Firmware,” heise Security. [Online]. Available: http://www.heise.de/security/meldung/Extreme-Privilege-Escalation-Gefaehrliche-Sicherheitsluecken-in-UEFI-Firmware-2429297.html. [Accessed: 11-Jun-2015].

[16] “DEF CON 22 - Extreme Privilege Escalation On Windows 8/UEFI Systems,” YouTube. [Online]. Available: https://www.youtube.com/watch?v=d6VCri6sPnY.

31

[17] “Advanced persistent threat,” Wikipedia, 18-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Advanced_persistent_threat&oldid=667433314. [Accessed: 19-Jun-2015].

[18] “Booting,” Wikipedia, 11-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Booting&oldid=666448749. [Accessed: 12-Jun-2015].

[19] “BIOS,” Wikipedia, 12-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=BIOS&oldid=666605212. [Accessed: 12-Jun-2015].

[20] “Master boot record,” Wikipedia, 23-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Master_boot_record&oldid=663683786. [Accessed: 12-Jun-2015].

[21] “Disk partitioning,” Wikipedia, 16-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Disk_partitioning&oldid=662663295. [Accessed: 12-Jun-2015].

[22] “GUID Partition Table,” Wikipedia, 31-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=GUID_Partition_Table&oldid=664851387. [Accessed: 12-Jun-2015].

[23] “Linux startup process,” Wikipedia, 04-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Linux_startup_process&oldid=660765108. [Accessed: 12-Jun-2015].

[24] “Linux Booting Process: A step by step tutorial for understanding Linux boot sequence,” slashroot.in. [Online]. Available: http://www.slashroot.in/linux-booting-process-step-step-tutorial-understanding-linux-boot-sequence. [Accessed: 12-Jun-2015].

[25] “LILO (boot loader),” Wikipedia, 02-Apr-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=LILO_(boot_loader)&oldid=654608327. [Accessed: 12-Jun-2015].

[26] “GNU GRUB,” Wikipedia, 31-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=GNU_GRUB&oldid=664921308. [Accessed: 12-Jun-2015].

[27] “Windows startup process,” Wikipedia, 02-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Windows_startup_process&oldid=665112811. [Accessed: 12-Jun-2015].

[28] “NTLDR,” Wikipedia, 19-Feb-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=NTLDR&oldid=647850514. [Accessed: 12-Jun-2015].

[29] “Windows Vista startup process,” Wikipedia, 10-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Windows_Vista_startup_process&oldid=666283413. [Accessed: 12-Jun-2015].

[30] “Shell (computing),” Wikipedia, 30-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Shell_(computing)&oldid=664677641. [Accessed: 14-Jun-2015].

[31] “Flash memory,” Wikipedia, 08-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Flash_memory&oldid=666050115. [Accessed: 12-Jun-2015].

[32] “Chipset,” Wikipedia, 30-Apr-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Chipset&oldid=660051570. [Accessed: 12-Jun-2015].

[33] “Unified Extensible Firmware Interface,” Wikipedia, 27-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Unified_Extensible_Firmware_Interface&oldid=664198064. [Accessed: 12-Jun-2015].

[34] “UEFI Forum.” [Online]. Available: http://www.uefi.org/. [Accessed: 12-Jun-2015].

32

[35] “UEFI – der BIOS-Nachfolger: Grundlagen und Hilfestellung,” WinTotal.de. [Online]. Available: http://www.wintotal.de/uefi-der-bios-nachfolger-grundlagen-und-hilfestellung/. [Accessed: 12-Jun-2015].

[36] c’t, “BIOS, UEFI und Secure Boot,” c’t. [Online]. Available: http://www.heise.de/ct/hotline/BIOS-UEFI-und-Secure-Boot-2056492.html. [Accessed: 11-Jun-2015].

[37] J. J. in 10 Things, O. 19, and 2011, “10 things you should know about UEFI,” TechRepublic. [Online]. Available: http://www.techrepublic.com/blog/10-things/10-things-you-should-know-about-uefi/. [Accessed: 12-Jun-2015].

[38] “Differences Between UEFI and BIOS,” Make Tech Easier. [Online]. Available: http://www.maketecheasier.com/differences-between-uefi-and-bios/. [Accessed: 12-Jun-2015].

[39] “UEFI Secure Boot,” Thomas-Krenn-Wiki. [Online]. Available: https://www.thomas-krenn.com/de/wiki/UEFI_Secure_Boot. [Accessed: 14-Jun-2015].

[40] “Real mode,” Wikipedia, 11-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Real_mode&oldid=666467631. [Accessed: 12-Jun-2015].

[41] “Protected mode,” Wikipedia, 24-Nov-2014. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Protected_mode&oldid=635247115. [Accessed: 12-Jun-2015].

[42] “Protection ring,” Wikipedia, 19-Apr-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Protection_ring&oldid=657128325. [Accessed: 12-Jun-2015].

[43] “Long mode,” Wikipedia, 29-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Long_mode&oldid=664575942. [Accessed: 12-Jun-2015].

[44] “x86 virtualization,” Wikipedia, 31-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=X86_virtualization&oldid=664906810. [Accessed: 12-Jun-2015].

[45] “System Management Mode,” Wikipedia, 23-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=System_Management_Mode&oldid=663611437. [Accessed: 12-Jun-2015].

[46] “SMM,” Ivanlef0u’s Blog. [Online]. Available: http://www.ivanlef0u.tuxfamily.org/?p=138. [Accessed: 12-Jun-2015].

[47] Loïc Duflot, Olivier Levillain, Benjamin Morin, and Olivier Grumelard, “Getting into the SMRAM: SMM Reloaded.” [Online]. Available: https://cansecwest.com/csw09/csw09-duflot.pdf. [Accessed: 12-Jun-2015].

[48] C. I. King, “Detecting System Management Interrupts,” A Smackerel of Opinion. . [49] Brian Delgado and Karen L. Karavanic, “Performance Implications of System

Management Mode.” [Online]. Available: http://web.cecs.pdx.edu/~karavan/research/SMM_IISWC_preprint.pdf. [Accessed: 14-Jun-2015].

[50] “Rootkit,” Wikipedia, 28-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Rootkit&oldid=664346868. [Accessed: 14-Jun-2015].

[51] “Backdoor,” Wikipedia, 01-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Backdoor_(computing)&oldid=664992455. [Accessed: 14-Jun-2015].

[52] “Malware,” Wikipedia, 13-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Malware&oldid=666710986. [Accessed: 14-Jun-2015].

33

[53] “Sony BMGs Kopierschutz mit Rootkit-Funktionen,” heise online. [Online]. Available: http://www.heise.de/newsticker/meldung/Sony-BMGs-Kopierschutz-mit-Rootkit-Funktionen-143366.html. [Accessed: 14-Jun-2015].

[54] “Spore: Ärger über Kopierschutz,” heise online. [Online]. Available: http://www.heise.de/newsticker/meldung/Spore-aerger-ueber-Kopierschutz-Update-204887.html. [Accessed: 14-Jun-2015].

[55] “Digital rights management,” Wikipedia, 08-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Digital_rights_management&oldid=666017528. [Accessed: 14-Jun-2015].

[56] “Hypervisor,” Wikipedia, 27-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Hypervisor&oldid=664269248. [Accessed: 14-Jun-2015].

[57] J. Rutkowska, “Introducing Blue Pill,” The Invisible Things Lab’s blog. . [58] Samuel T. King and Peter M. Chen, “SubVirt: Implementing Malware with Virtual

Machines.” [Online]. Available: http://www.cse.psu.edu/~pdm12/cse544/slides/cse544-subvirt-sawani.pdf. [Accessed: 14-Jun-2015].

[59] “Hooking,” Wikipedia, 05-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Hooking&oldid=660953860. [Accessed: 14-Jun-2015].

[60] Z. Wang, X. Jiang, W. Cui, and P. Ning, “Countering Kernel Rootkits with Lightweight Hook Protection,” in Proceedings of the 16th ACM Conference on Computer and Communications Security, New York, NY, USA, 2009, pp. 545–554.

[61] “Trusted Platform Module,” Wikipedia, 12-Jun-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Trusted_Platform_Module&oldid=666666879. [Accessed: 14-Jun-2015].

[62] “SOUFFLETROUGH: NSA Exploit of the Day,” Schneier on Security. [Online]. Available: https://www.schneier.com/blog/archives/2014/01/souffletrough_n.html. [Accessed: 14-Jun-2015].

[63] “SCHOOLMONTANA: NSA Exploit of the Day,” Schneier on Security, 14-Jan-2014. [Online]. Available: https://www.schneier.com/blog/archives/2014/01/schoolmontana_n.html. [Accessed: 14-Jun-2015].

[64] John Heasman, “Implementing and Detecting an ACPI BIOS Rootkit.” [Online]. Available: https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf. [Accessed: 14-Jun-2015].

[65] “Mebromi: the first BIOS rootkit in the wild,” Webroot Threat Blog. [Online]. Available: http://www.webroot.com/blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/. [Accessed: 14-Jun-2015].

[66] Shawn Embleton, Sherri Sparks, and Cliff Zou, “SMM Rootkits: A New Breed of OS Independent Malware.” [Online]. Available: http://www.eecs.ucf.edu/~czou/research/SMM-Rootkits-Securecom08.pdf. [Accessed: 14-Jun-2015].

[67] “IRONCHEF: NSA Exploit of the Day,” Schneier on Security, 03-Jan-2014. [Online]. Available: https://www.schneier.com/blog/archives/2014/01/nsa_exploit_of_1.html. [Accessed: 14-Jun-2015].

[68] “Serial over LAN,” Thomas-Krenn-Wiki. [Online]. Available: https://www.thomas-krenn.com/de/wiki/IPMI_Serial_over_LAN_(SOL). [Accessed: 15-Jun-2015].

[69] “Wireshark.” [Online]. Available: https://www.wireshark.org/. [Accessed: 19-Jun-2015]. [70] “Intrusion detection system,” Wikipedia, the free encyclopedia, 18-Jun-2015. [Online].

Available: https://en.wikipedia.org/w/index.php?title=Intrusion_detection_system&oldid=667436623. [Accessed: 19-Jun-2015].

34

[71] “Vulnerability Note VU#552286 - UEFI EDK2 Capsule Update vulnerabilities,” CERT.org, 07-Aug-2014. [Online]. Available: https://www.kb.cert.org/vuls/id/552286. [Accessed: 15-Jun-2015].

[72] Visualge Vis, “How does UEFI Fault Tolerant Write protocol work on Variable reclaiming process?,” Count Chu. [Online]. Available: http://countchu.blogspot.co.at/2014/08/how-uefi-fault-tolerant-write-protocol.html. [Accessed: 12-Jun-2015].

[73] Brian Richardson and Alex Hung, “UEFI Test Tools for Linux Developers.” [Online]. Available: http://www.uefi.org/sites/default/files/resources/S3_LinuxTestTools_UEFILinuxCon_FINAL_Aug.%2021.pdf. [Accessed: 12-Jun-2015].

[74] Teddy Reed, “Analytics, And Scalability, and UEFI Exploitation! Oh My!,” Vimeo. [Online]. Available: https://vimeo.com/98240782. [Accessed: 15-Jun-2015].

[75] Teddy Reed, “Analytics, And Scalability, and UEFI Exploitation! Oh My!” [Online]. Available: http://prosauce.org/storage/slides/Infiltrate2014-Analytics-Scalability-UEFI-Exploitation.pdf. [Accessed: 15-Jun-2015].

[76] “UEFI Spider,” GitHub. [Online]. Available: https://github.com/theopolis/uefi-spider. [Accessed: 15-Jun-2015].

[77] “UEFI Firmware Parser.” [Online]. Available: https://github.com/theopolis/uefi-firmware-parser. [Accessed: 15-Jun-2015].

[78] “Subzero UEFI Firmware Analyzer.” [Online]. Available: https://github.com/theopolis/subzero. [Accessed: 15-Jun-2015].

[79] “Vulnerability Note VU#758382 - Unauthorized modification of UEFI variables in UEFI systems,” CERT.org, 15-Aug-2013. [Online]. Available: https://www.kb.cert.org/vuls/id/758382. [Accessed: 15-Jun-2015].

[80] “Vulnerability Note VU#533140 - Tianocore UEFI implementation reclaim function vulnerable to buffer overflow,” CERT.org, 09-Jun-2014. [Online]. Available: https://www.kb.cert.org/vuls/id/533140. [Accessed: 15-Jun-2015].

[81] “Vulnerability Note VU#766164 - Intel BIOS locking mechanism contains race condition that enables write protection bypass,” CERT.org, 05-Jan-2015. [Online]. Available: https://www.kb.cert.org/vuls/id/766164. [Accessed: 15-Jun-2015].

[82] “Vulnerability Note VU#912156 - Dell BIOS in some Latitude laptops and Precision Mobile Workstations vulnerable to buffer overflow,” CERT.org, 09-Jun-2014. [Online]. Available: https://www.kb.cert.org/vuls/id/912156. [Accessed: 15-Jun-2015].

[83] “Vulnerability Note VU#976132 - Some UEFI systems do not properly secure the EFI S3 Resume Boot Path boot script,” CERT.org, 09-Jun-2014. [Online]. Available: https://www.kb.cert.org/vuls/id/976132. [Accessed: 15-Jun-2015].

[84] zafirt, “Malicious malware in BIOS again?,” Oversite Sentry. [Online]. Available: http://oversitesentry.com/malicious-malware-in-bios-again/. [Accessed: 12-Jun-2015].

[85] Christof Windeck, “Kommentar zur UEFI-Lücke: Sie lernen es einfach nicht,” heise online, 23-Oct-2015. [Online]. Available: http://www.heise.de/newsticker/meldung/Kommentar-zur-UEFI-Luecke-Sie-lernen-es-einfach-nicht-2430455.html. [Accessed: 11-Jun-2015].

[86] “Mehr Updates gegen die UEFI-Sicherheitslücke (3. Update),” heise Security, 05-Nov-2014. [Online]. Available: http://www.heise.de/security/meldung/Mehr-Updates-gegen-die-UEFI-Sicherheitsluecke-3-Update-2442775.html. [Accessed: 11-Jun-2015].

[87] “US-Cert warnt vor weiteren UEFI-BIOS-Lücken,” heise Security, 07-Jan-2015. [Online]. Available: http://www.heise.de/security/meldung/US-Cert-warnt-vor-weiteren-UEFI-BIOS-Luecken-2512913.html. [Accessed: 11-Jun-2015].

[88] “Vulnerability Note VU#631788 - Multiple BIOS implementations permit unsafe SMM function calls to memory locations outside of SMRAM.” [Online]. Available: https://www.kb.cert.org/vuls/id/631788. [Accessed: 12-Jun-2015].

[89] “Inquisitor hardware testing platform.” [Online]. Available: http://www.inquisitor.ru. [Accessed: 21-Jun-2015].

35

[90] “PartedMagic.” [Online]. Available: https://partedmagic.com/. [Accessed: 21-Jun-2015]. [91] c’t, “Desinfec’t,” c’t. [Online]. Available: http://www.heise.de/ct/projekte/Desinfec-t-

1213110.html. [Accessed: 21-Jun-2015]. [92] “DEFT Linux - Computer Forensics live CD.” [Online]. Available:

http://www.deftlinux.net/. [Accessed: 21-Jun-2015]. [93] “Kodi - Open Source Home Theatre Software.” [Online]. Available: http://kodi.tv/.

[Accessed: 21-Jun-2015]. [94] “Lightweight Portable Security.” [Online]. Available: http://www.spi.dod.mil/lipose.htm.

[Accessed: 21-Jun-2015]. [95] c’t, “Bankix,” c’t. [Online]. Available: http://www.heise.de/ct/projekte/Sicheres-Online-

Banking-mit-Bankix-284099.html. [Accessed: 21-Jun-2015]. [96] “Live-System,” Wikipedia, 26-Feb-2015. [Online]. Available:

https://de.wikipedia.org/w/index.php?title=Live-System&oldid=139238021. [Accessed: 21-Jun-2015].

[97] “Windows 8 Security Overview,” Microsoft TechNet. [Online]. Available: https://technet.microsoft.com/en-us/library/dn283963.aspx. [Accessed: 21-Jun-2015].

[98] “Anti-rootkit utility TDSSKiller.” [Online]. Available: http://support.kaspersky.com/viruses/disinfection/5350. [Accessed: 21-Jun-2015].

[99] “How to remove a bootkit,” Kaspersky Support. [Online]. Available: http://support.kaspersky.com/viruses/solutions/2727. [Accessed: 21-Jun-2015].

[100] Pete Markowsky, “Containerizing Malicious SMM.” [Online]. Available: http://www.vodun.org/papers/ShmooCon2010/markowsky-shmoocon2010-containerizing_malicious_smm.pdf. [Accessed: 21-Jun-2015].

[101] “New Microarchitecture for 4th Gen Intel Core Processor Platforms,” Intel. [Online]. Available: http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/4th-gen-core-family-mobile-brief.pdf. [Accessed: 19-Jun-2015].

[102] “Intel Boot Guard,” Personal Rambling. [Online]. Available: http://patrick.georgi-clan.de/2015/02/17/intel-boot-guard/. [Accessed: 19-Jun-2015].

[103] “Trusted Execution Technology,” Wikipedia, 24-May-2015. [Online]. Available: https://en.wikipedia.org/w/index.php?title=Trusted_Execution_Technology&oldid=663797464. [Accessed: 19-Jun-2015].

[104] “How does the TPM perform integrity measurements on a system?,” Information Security Stack Exchange. [Online]. Available: http://security.stackexchange.com/questions/39329/how-does-the-tpm-perform-integrity-measurements-on-a-system. [Accessed: 19-Jun-2015].

[105] Roy, “How To Check For And Fix MBR Virus Infection,” TechLogon Technology News. [Online]. Available: http://techlogon.com/2012/01/15/how-to-check-for-and-fix-mbr-virus-infection/. [Accessed: 21-Jun-2015].

36

Abbildungsverzeichnis

Abbildung 1 Abfolge von Prozessen bei Inbetriebnahme eines Systems

angefertigt von den Autoren in Anlehnung an eine Abbildung in [73]

Abbildung 2 Betriebsmodi und Schutzring-Konzept der x86er Prozessoren

angefertigt von den Autoren nach Abbildungen in [100] und [42]

Abbildung 3 Ausführen von Software im SMM

angefertigt von den Autoren

Abbildung 4 Unterbrechung beliebiger Prozesse durch den SMM

angefertigt von den Autoren in Anlehnung an eine Abbildung in [73]

Abbildungen 4a-c LightEater Demo

angefertigt von den Autoren in Anlehnung an Video [6]

Abbildung 5 UEFI SwSMI Interface

angefertigt von den Autoren in Anlehnung an eine Abbildung in [4]

Tabellenverzeichnis

Tabelle 1 UEFI Vulnerabilities

angefertigt von den Autoren nach einer Aufzählung in [4]