Suchen

Hacker im Luftverkehr Integrität der Firmware für Flugsicherheit sicherstellen

| Autor / Redakteur: David Kleidermacher * / Franz Graser

Eine Flugzeugentführung per Smartphone-Hacking ist der Alptraum jedes Passagiers. Im Frühjahr 2013 stellte ein Sicherheits-Consultant ein solches Szenario vor. Tatsächlich sind die Flight-Management-Systeme von Flugzeugen nicht immun gegen Angriffe – aber es gibt Schutzmechanismen.

Firmen zum Thema

Das Cockpit eines modernen Verkehrsflugzeugs (hier der DLR-Simulator in Braunschweig) – wie sicher sind die Flight-Management-Systeme gegen das Einschleusen bösartiger Software? Es gibt Lösungen, die sicherstellen, dass nur die Software auf den Rechnern läuft, die auch dort hingehört.
Das Cockpit eines modernen Verkehrsflugzeugs (hier der DLR-Simulator in Braunschweig) – wie sicher sind die Flight-Management-Systeme gegen das Einschleusen bösartiger Software? Es gibt Lösungen, die sicherstellen, dass nur die Software auf den Rechnern läuft, die auch dort hingehört.
( DLR (CC-BY 3.0))

Im April 2013 machte ein Sicherheitsberater Schlagzeilen, als er behauptete, er könne sich mit einem Android-Smartphone in Passagierflugzeuge hacken und diese kapern (Link). Der Smartphone-Hacker fügte mit Android über Funk bösartige Befehle in ein simuliertes Flug-Management-System (FMS) ein, was den simulierten Autopiloten des Flugzeugs dazu veranlasst hätte, die Flughöhe entsprechend zu ändern – fatale Konsequenzen nicht ausgeschlossen.

Zwei wesentliche Schwachstellen wurden dabei entdeckt. Zum einen werden Nachrichten an das FMS nicht kryptografisch authentifiziert. Zum anderen erlauben es Schwächen in der FMS-Software, dass nicht authentifizierte Befehle das Flugzeug tatsächlich kapern können.

Bald darauf beruhigten die Aufsichtsbehörden FAA und EASA und die Flugzeughersteller die Öffentlichkeit mit einer allgemeinen Stellungnahme, dass die Android-Hacker-Demo bei derzeitigen Passagierflugzeugen nicht möglich sei. Die Stellungnahme eines Herstellers war etwas spezifischer und erklärte, dass das simulierte FMS „nicht über die gleichen Schutzmaßnahmen gegen Überschreiben oder Korrumpieren verfügt wie unsere zertifizierte Flugsoftware.“

Abgesehen von der Sorge über nicht authentifizierte Nachrichten (für die es zahlreiche Lösungen auf Basis digitaler Signaturen gibt) sollte dieser Hack als ernste Warnung für alle Elektronikentwickler gelten, die Wichtigkeit des Integritätsschutzes kritischer Firmware/Software sehr ernst zu nehmen. Die meisten Computersysteme weltweit sind nicht mit solchen Schutzmaßnahmen ausgestattet, wie es die Rootkit-Problematik aufzeigt. Im Jahr 2011 bewies McAfee die Existenz von über 2 Mllionen Rootkits – und 1200 neue Rootkits werden jeden Tag neu entdeckt.

Wird sichergestellt, dass nur vertrauenswürdige Software auf einer Plattform läuft, können Angriffe, wie sie beim simulierten Flugzeug durchgeführt wurden, nicht mehr stattfinden oder bleiben zumindest nicht unentdeckt.

Es gibt zwei Möglichkeiten, die Firmware-Integrität zu beeinträchtigen: Erstens, können die Festplatten- oder Flash-Blöcke, die vertrauenswürde Software enthalten, modifiziert werden. Malware lässt sich entweder durch eine physikalische Attacke auf dem Speichersystem installieren oder über eine Schwachstelle im Betriebssystem besteht Laufzeit-Zugriff auf den Speicher. Dies wird als „Permanent Roots“ bezeichnet, da die Malware selbst nach einem Neustart (Reboot) weiter arbeitet. Die zweite Methode ist das „Einhaken“ (Hook) in die kritischen Ausführungspfade vertrauenswürdiger Software während der Laufzeit.

Ein Großteil der Sicherheitsforschung rund um moderne Betriebssysteme konzentriert sich darauf, einer Malware den Zugang zu erschweren. Dabei wird die Betriebssystem-Ausführung verschleiert (etwa durch zufällige Belegung des Adressraums), und allgemeine Betriebssystem-Schwachstellen werden verringert.

Sicheres Booten und Integritätsüberprüfung

Bild 1: Sichere Boot-Sequenz
Bild 1: Sichere Boot-Sequenz
(Bild: Green Hills Software)

Sicheres Booten ist der einfachste und effektivste Weg, um Permanent Roots zu verhindern oder zumindest zu erkennen. Beim sicheren Booten soll gewährleistet werden, dass die gesamte Plattform einschließlich Hardware, Bootloader, Betriebssystem und kritische Anwendungen – also alles, was zu einem bekannten, vertrauenswürdigen Systemstatus beiträgt – überprüft und für authentisch befunden wird.

Verfügen die Hardware und der Bootloader über die Möglichkeit, die System-Firmware (Betriebssystem, Hypervisor, gesamte Trusted Computing Base – TCB) von einer anderen Einrichtung aus zu laden (etwa über USB) anstelle des beabsichtigten, vertrauenswürdigen Device (etwa Flash), kann ein Angreifer mit Zugriff auf das System ein böswilliges Betriebssystem booten. Dieses kann wie das vertrauenswürdige Betriebssystem agieren, allerdings mit böswilligem Verhalten. So können Netzwerkauthentifizierungsdienste deaktiviert oder Backdoor-Logins hinzugefügt werden.

Dies ist aber nur eine Möglichkeit, Systeme ohne sicheres Booten zu untergraben. Statt eines bösartigen Bootloaders oder Betriebssystems kann auch ein böswilliger Hypervisor gebootet werden. Dieser kann dann das vertrauenswürdige Betriebssystem innerhalb einer virtuellen Maschine starten. Der böswillige Hypervisor hat vollen Zugriff auf das RAM und kann so die vertrauenswürdige Umgebung im Verborgenen ausspionieren, Kryptografie-Schlüssel stehlen oder die Sicherheitsvorkehrungen des Systems verändern. In einem Beitrag von King u.a. wird ein Beispiel dieser Attacke beschrieben: mit SubVirt, einem Malware-Hypervisor. Ein weiterer berüchtigter Angriff, genannt BluePill, erweiterte den SubVirt-Ansatz: Ein permanentes Rootkit wird erstellt, das sich einfach während des Betriebs starten lässt und die Schwächen des ab Werk installierten Windows-Betriebssystems ausnutzt .

Die typische sichere Boot-Methode überprüft die Authentizität jeder Komponente innerhalb der Boot-Kette. Ist ein Glied in dieser Kette unterbrochen, wird der sichere Ausgangszustand beeinträchtigt. Der ROM-Loader in der ersten Stufe muss auch über einen hardwaregeschützten Kryptografie-Schlüssel verfügen, um die digitale Signatur des Bootloaders auf der nächsten Stufe zu überprüfen. Dieser Schlüssel kann in das ROM-Loader-Image selbst integriert werden – entweder über eine OTP-Sicherung (One-Time Programmable) oder er ist in einem lokalen TPM (Trusted Platform Module) gespeichert, das zusätzlichen Manipulationsschutz bietet.

Der Signaturschlüssel dient zur Authentizitätsüberprüfung der Komponenten in der zweiten Stufe der Boot-Kette. Der Entwickler hat die Möglichkeit, jedes authentische Image oder eine Reihe von bekannten (Known-Good) Images zu erlauben. Dabei müssen die Known-Good-Signaturen ebenfalls in der hardwaregeschützten Umgebung gespeichert werden. Die Überprüfung der Komponenten auf der zweiten Ebene deckt deren ausführbares Image als auch die Known-Good-Signatur und den Signatur-Verifikationsschlüssel der dritten Stufe ab (falls diese vorhanden ist). Die Überprüfungskette kann unendlich lang sein. Einige anspruchsvolle Computersysteme haben ausgesprochen lange Ketten oder sogar Bäume überprüfter Komponenten, die die TCB ausmachen. Bild 1 zeigt ein Beispiel einer sicheren Boot-Sequenz über drei Ebenen.

Der Vorteil beim sicheren Booten ist, dass die meisten universellen Mikroprozessoren einen integrierten Speicher für den Kryptografie-Schlüssel für diesen Root-of-Trust-Ansatz enthalten, ohne dafür weitere spezielle Hardware zu benötigen.

Sicheres Booten allein verhindert keine böswilligen Identitätswechsel. So kann ein Smart Meter durch ein gleich aussehendes, böswilliges Gerät ersetzt werden, das aber heimlich private Informationen über den Energieverbrauch an eine böswillige Webseite sendet. Anwender und Versorger müssen sich also sicher sein, dass ein im Einsatz befindliches Produkt als Known-Good-TCB arbeitet.

Werden Embedded-Systeme mit Verwaltungsnetzwerken verbunden, kann die Identitätsüberprüfung (Remote Attestation) eine wichtige Sicherheitsfunktion übernehmen. Ein einfacher, hardware-unabhängiger Ansatz kann für jedes Computersystem verwendet werden, wenn eine gegenseitig authentifizierte Verbindung (etwa über IKE/IPsec oder Transport Layer Security – TLS) eingesetzt wird. Solange der statische private Schlüssel und die sichere Verbindungsprotokoll-Software des Systems in die TCB integriert sind, die während des sicheren Bootens überprüft wird, hat die Beglaubigungsinstanz die Gewissheit, dass das System unter Known-Good-Firmware läuft. Eine Verbesserung dieses Ansatzes wäre, wenn der Client den kompletten Satz an digitalen Signaturen entsprechend der TCB-Kette an die Beglaubigungsinstanz sendet, die den Known-Good-Satz an Signaturen lokal speichert.

Hyperhooking als Schutz gegen Manipulation

Sicheres Booten und Attestieren schützen nicht gegen Laufzeit-Subversion über einige Schwachstellen – der Methode, die beim simulierten Flugzeug-Hack verwendet wurde. Die Anbieter von Sicherheitssoftware versprechen viel mit ihren Lösungen, solche Malware ausfindig zu machen. Aber jeden Tag beginnt der Kampf von neuem und Rootkits bleiben an der Tagesordnung.

Bild 2: Hyperhooking: Hardware-Virtualisierungs-Hooks ermöglichen es einem vertrauenswürdigen Agenten, nach Malware zu suchen.
Bild 2: Hyperhooking: Hardware-Virtualisierungs-Hooks ermöglichen es einem vertrauenswürdigen Agenten, nach Malware zu suchen.
(Grafik: Green Hills Software)

Computersicherheits- und Betriebssystem-Anbieter kommen langsam zu der Einsicht, dass moderne, anspruchsvolle Betriebssysteme von innen heraus nicht ausreichend geschützt werden können, sondern einen äußeren (Out-of-Band) Schutzmechanismus erfordern. Aufgrund der zunehmenden Verfügbarkeit in Chipsets aller großen Embedded-Mikroprozessor-Architekturen entwickelt sich somit hardware-basierter Virtualisierungssupport zum bevorzugten Schutzmechanismus.

Hardware-Virtualisierungs-Hooks ermöglichen einem Stück Software, die Kontrolle über einen Computer während bestimmter sicherheitsrelevanter Rechenoperationen zu erlangen, etwa Betriebssystem-Ausnahmen und Interrupts, Supervisor-Mode-Befehle, Schreibzugriffe auf sensible Speicherstellen etc. Wir führen den Begriff Hyperhooking für diesen allgemeinen Sicherheitsansatz ein: die Hardware-Virtualisierungs-Hooks ermöglichen es einem vertrauenswürdigen Agenten, nach Malware zu suchen, indem der Systemstatus während dieser speziellen Operationen durchsucht wird (Bild 2). Dies sind die gleichen Hardware-Hooks, die kommerzielle Hypervisor verwenden, um Funktionen virtueller Maschinen bereitzustellen.

Die gleichen Hardware-Virtualisierungs-Hooks wurden in den oben erwähnten Hypervisor-Rootkit-Attacken verwendet. Sicheres Booten ist erforderlich, um zu gewährleisten, dass nur der vertrauenswürdige Agent installiert wird und imstande ist, diese Funktionen zu nutzen. Und auch der vertrauenswürdige Agent selbst muss gegen Angriffe sicher sein.

Ein kommerzielles Beispiel für Hyperhooking ist die DeepSAFE-Technologie (hardwarespezifisch unter dem Namen Intel VT bekannt) von McAfee – obwohl nur wenig darüber veröffentlicht wurde, was DeepSAFE wirklich tut. Ein weiteres kommerzielles Beispiel, das Intel VT nutzt, ist vSentry von Bromium. Hier lassen sich die Aktionen des Hyperhook-Agents je nach den Hardware-Traps konfigurieren. DeepSAFE und vSentry versuchen, Rootkit-Schutz für anspruchsvolle Betriebssysteme nachzurüsten. Wie auch bei anderen OS-Visors wie SELinux, ist die Komplexität in diesen Betriebssystemen aber zu hoch, um sie zu verwalten und zu kontrollieren. Das Nachrüsten erhöht die Schwelle für Angreifer nur temporär.

Im Jahr 2009 zeigte eine hervorragende wissenschaftliche Arbeit , wie Tausende von Linux-Steuerungsfunktionen mithilfe von Hyperhooking gegen Manipulation geschützt werden können. Die Forscher gaben jedoch zu, dass die Technik das Problem der Malware nicht behandelt, das dynamische Datenobjekte (im Gegensatz zur Ablaufsteuerung) daran hindert, ihren Zweck zu erfüllen. Selbst die geschützten Funktionen sind unvollständig; ein einziger verwundbarer Steuerungspunkt reicht aus, um das gesamte System zu beeinträchtigen. Laut den Forschern ist es eine „grundlegende Einschränkung ..., dass Hook-Zugriffsprofile mit dynamischer Analyse konstruiert werden, was zu Unvollständigkeiten führt.“ Die Forscher geben zu, dass die Bestimmung des kompletten Satzes nutzbarer Kernel-Hooks ein „interessantes Forschungsproblem“ ist, das noch keine bekannte Lösung hervorgebracht hat.

Hyperhosting – Verlegen kritischer Prozesse in virtuelle Maschinen

Anstatt Virtualisierungs-Hardware-Hooks für die Betriebssystem-Selbstprüfung zu verwenden, können diese zum Entfernen und Isolieren kritischer Funktionen des Betriebssystems eingesetzt werden, indem sie in separate virtuelle Maschinen oder Prozesse verlegt werden. Unabhängig davon, welche Malware erfolgreich in das Betriebssystem oder dessen Anwendungen und Dienste eingebracht wird, bleiben die Hypergehostete Komponenten davon unberührt.

Bild 3: Das Hyperhosting denkt den Hyperhooking-Ansatz einen Schritt weiter, da die Hooks dazu genutzt werden können, kritische Funktionen zu isolieren und in separate virtuelle Maschinen zu verlegen.
Bild 3: Das Hyperhosting denkt den Hyperhooking-Ansatz einen Schritt weiter, da die Hooks dazu genutzt werden können, kritische Funktionen zu isolieren und in separate virtuelle Maschinen zu verlegen.
(Grafik: Green Hills Software)

Der Umfang des Hyperhostings kann von einfachen Verschlüsselungsfunktionen, wie sie in Smartcards zu finden sind, bis hin zu vollständigen Sekundär-Betriebssystemumgebungen reichen. Der Integrity-Multivisor ist ein Beispiel eines Bare-Metal-Hypervisors, der auf ARM- oder Intel-Prozessoren läuft und Hyperhosting-Funktionen bietet. Im Gegensatz zu herkömmlichen Hypervisor-Lösungen kann Integrity-Multivisor auch einfache Prozesse hyperhosten, zusätzlich zu vollständig virtuellen Maschinen, die Gast-Betriebssysteme wie Linux enthalten. Diese Architektur (Bild 3) kann für Malware-Hyperhooking, Netzwerksicherheit, Datenverschlüsselung, Betriebssystem-Root-Erkennung, Systemüberwachung etc. verwendet werden. Der Hypervisor baut auf der Separationskernel-Technik auf, die zahlreiche Sicherheitszertifizierungen (einschließlich Flugsicherheit) erhalten hat.

Literaturhinweise:

[1] Samuel T. King, et al.; SubVirt: Implementing malware with virtual machines; IEEE Symposium on Security and Privacy; 2006

[2] Joanna Rutkowska; Subverting Vista™ Kernel for Fun And Profit; Black Hat Briefings 2006; August 3, 2006

[3] Zhi Wang, et al.; Countering Kernel Rootkits with Lightweight Hook Protection; 2009

* David Kleidermacher ist Chief Technology Officer (CTO) beim US-Softwarehersteller Green Hills Software.

(ID:42251896)