0.13b CSI MacMark: Thunderstrike Bootkit Inhaltsverzeichnis

Auf dem 31C3 stellt Trammell Hudson sein Projekt Thunderstrike vor. Ich hatte beim Lesen der Beschreibung sofort ein Déjà-Vu, denn fast genau dieses Thema wurde schon in 2012 von Snare behandelt und von mir in einem entprechendem Artikel gewürdigt, der auch für den aktuellen Fall immer noch die grundlegenden Informationen bietet. Ich habe im Vorfeld des Vortrages schon mal bei Snare und Trammell ein paar Dinge nachgefragt, die mir aufgefallen sind. Es sind übrigens beides sehr nette Zeitgenossen.

Einleitung

Vorträge über Angriffsmöglichkeiten auf (U)EFI häufen sich im Moment. In Attacks on UEFI security wurden erstmal alle UEFI-Implementierungen auf allen Sorten von PCs (Nicht-Macs) geknackt. Und in dem Vortrag von Trammell werden dann – ausgleichende Gerechtigkeit – die Macs mit ihrer Implementierung von EFI angegangen. Der offenbar einzige Unterschied zur Snares Version von 2012 besteht darin, daß Snare unter anderem die Datei /System/Library/CoreServices/boot.efi (das ist der OS X Bootloader) manipuliert hat, um Persistenz zu erreichen, während Trammell den EFI-Speicher mit eigenem Code überschreibt, also auf noch tiefere Ebene die Infektion persistiert.

Trammells zusätzliche Leistung besteht darin, daß er die Signatur-Prüfung, die bei EFI-Updates stattfindet, durch einen Hack umgehen kann. Beide Security-Hacker benutzen das Option-ROM eines externen PCI-Express- oder Thunderbolt-Gerätes für ihren Angriff.

Das grundlegende Problem ist, daß durch Thunderbolt PCIe-Geräte außerhalb des Rechners angeschlossen werden können. Früher mußte man den Rechner öffnen und einen der PCI-Slots mit einer Karte bestücken, was denselben Effekt hat, als wenn man ein Thunderbolt-Gerät verwendet, nur umständlicher.

Der Angriff erfolgt bevor das Betriebssystem und sein Kernel überhaupt gestartet sind in einer frühen Phase des Boot-Prozesses, in der die Firmware noch die Kontrolle hat.

Option-ROMs gibt es zwar schon sehr lange und manch einer unterliegt dem Trugschluß, was alt ist, müßte auch obsolet oder zumindest veraltet sein, aber das ist nicht der Fall, denn Option-ROMs stellen der Firmwware unter anderem Treiber zur Verfügung, ohne die sie mit dem Gerät nicht arbeiten könnte. Siehe dazu auch meinen vorherigen Artikel.

Apples EFI

Da das PC-BIOS in vieler Hinsicht sehr beschränkt (also wirklich "basic" input output system) ist, zum Beispiel was die Unterstützung von Volumes größer als 2 TB angeht oder die auf vier limitierte Anzahl bootfähiger Partitionen oder die eigene Begrenzung auf 1 MB Memory, bei dem nochmal 384 K für Shared Video Memory abgezogen werden müssen, und Apple beim Wechsel von PowerPC auf Intel einen Ersatz für OpenFirmware brauchte, landete man bei Intels EFI.

EFI ist ein Interface und bietet im Gegensatz zum BIOS eine komplette Laufzeitumgebung, die weit mehr Möglichkeiten hat während des Boot-Prozesses und auch danach. Apple verwendet zur Zeit (2014) eine mit EFI-Version 1.10 kompatibele Version, die allerdings Teile vom offenen Standard UEFI 2.3.1 übernommen hat. Apples Implementierung ist Closed Source und wenig dokumentiert und ist halt ein Zwitter aus EFI 1.10 und UEFI 2.3.1.

Die Firmware, die das EFI-Interface implementiert, liegt in einem EEPROM, also einem Electrically Erasable Programmable Read-Only Memory. Das ist ein Speichermodul, das normalerweise nur gelesen werden kann, aber unter bestimmten Bedingungen auch gelöscht und mit neuem Programm-Code beschrieben werden kann. Ein Update ersetzt also zwangsläufig den kompletten Inhalt.

Signatur-Prüfung

Trammell und Snare haben in den Beschreibungen ihrer jeweiligen Hacks sich widersprechende Informationen veröffentlicht. Da ich mich ja damals schon ausführlich mit dem Thema beschäftigt hatte, fiel mir das auch prompt auf. Snare hatte geschrieben, daß die Signatur und die Integrität der Firmware beim Booten des Rechners durch ein spezielles Boot ROM geprüft würde.

Trammell hingegen schreibt, daß gar keine kryptographischen Checks der Firmware beim Booten des Rechners stattfinden. Ich hatte beide darauf angesprochen und letztendlich stellte sich heraus, daß es tatsächlich wohl keine Überprüfung der Firmware beim Rechnerstart gibt, sondern nur beim Update. Das genügt eigentlich auch, da die Original-Firmware von Apple mit dem Gerät ausgeliefert wird und jede Aktualisierung validiert wird. Schlägt die Prüfung des Updates fehl, wird das Update nicht installiert. Somit wäre die Firmware relativ sicher sauber. Allerdings hat Trammell einen Weg gefunden, die Prüfung zu kompromittieren.

Folgeschäden

Ansonsten sind alle Folgeschäden deckungsgleich mit dem, was ich damals beschrieben habe. Die originale Firmware fragt zum Beispiel das FileVault Paßwort ab. Eine manipulierte Firmware könnte mit dem Paßwort natürlich dann weiteren Unfug treiben, es weiterschicken oder so. Die manipulierte Firmware kann auch andere PCI-Express- oder Thunderbolt-Geräte mit Option-ROMs kompromittieren. Wenn die wiederum an andere Macs angeschlossen werden, könnten sie ihrerseits neue Infektionen an der Firmware dieser Macs vornehmen.

Angriffe über solche Wege erfordern physikalischen Zugriff und werden nicht flächendeckend mit der Gießkanne verbreitet, wie das mit Angriffen über Trojanische Pferde, Viren oder Würmer passieren kann. Das typische Szenario ist hier ein gezielter Angriff auf einzelne Personen.

Und natürlich überlebt die Firmware, sei sie nun manipuliert oder im Original-Zustand, einen Neustart oder eine komplette Neu-Installation des Betriebssystems oder einen Austausch aller Festplatten. Dafür ist die Firmware ja da. Und darum ist sie so ein interessantes Ziel.

Zur Zeit ist außer Trammells gutmütigem Proof-of-Concept namens Thunderstrike kein vergleichbarer Fall in freier Wildbahn bekannt. Und für die Veränderung des Mac-Start-Bildes benötigt man übrigens kein Firmware-Rootkit ;-)

Ergänzungen nach dem Vortrag

Ich habe mir den Vortrag inwzischen angesehen und ergänze nun darum diesen Artikel. Dasselbe Video auch auf YouTube. Von der deutschen Übersetzung muß ich allerdings abraten, da sie aufgrund ihrer Natur als Live-Übersetzung einige Details vermissen läßt. Es gibt auch Bilder der Vortragsfolien, die ich in diesem Artikel verwende.

Inzwischen gibt es auch eine schriftliche Zusammenfassung des Vortrages, die Trammell bereitgestellt hat. Allerdings ist sie nicht ganz deckungsgleich mit dem Text des Vortrages.

Das Entwickler-Team

Der Proof-of-Concept wurde nicht von einem schmierigen selbsternannten Hacker in schwarzer Matrix-Leder-Kluft am Wochenende entwickelt, wie mancher sich das vielleicht vorstellen mag, sondern von einem professionellem Team aus vier Leuten in Festanstellung. Im Auftrag ihrer New Yorker Firma haben sie die Verwundbarkeit der MacBook-Firmware untersucht, weil die Firma von Angriffsmöglichkeiten auf die Firmware dieser Geräte gehört hat. Da die Firma die MacBooks selbst einsetzen möchte und die Sicherheit der Geräte für sie sehr wichtig ist, haben sie die Untersuchung selbst vorgenommen.

Erkennen einer Infektion

Eine Erkennung über Software kann in diesem Fall nicht zuverlässig sein, weil sie auf Informationen aus tieferen Schichten, genauer gesagt aus der Hardware, aus dem Firmware-Speicher angewiesen ist. Die Firmware ist jedoch kompromittiert und sie kann Anfragen aus der Software absichtlich falsch beantworten. Ähnlich wie eine Infektion des Kernels nicht von darüberliegenden Programmen zuverlässig erkannt werden kann, kann eine Infektion der Hardware nicht verläßlich durch auf diese Hardware angewiesene Software untersucht werden.

Nur falls eine Malware keine geeigneten Maßnahmen ergreift, ihre Existenz zu verschleiern, kann eine Software in einer höheren Schicht des Systems eine Infektion aufdecken. Das ist übrigens der Grund, warum AV-Software immer als Root laufen muß, um überhaupt die technische Chance zu haben, das System zu untersuchen. Vergleiche dazu OS X: Antivirus-Nonsens – nutzlos und gefährlich.

Man kann eine Infektion der Firmware jedoch mit Hilfe externer Hardware prüfen, die den Speicher der Firmware direkt physikalisch ausliest. Also genau auf die Weise, wie Trammell auch die originale Firmware analysiert hat. Damit zieht man eine komplette Kopie der Firmware und vergleicht sie einfach mit einem sauberen Exemplar. Im Grunde genügt ein einfacher Hashwert, den man über beide Firmware-Inhalte berechnet, denn das geht schneller als ein Detail-Vergleich. Ist der Hashwert gleich, liegt keine Infektion vor.

Durch das Auslesen der Firmware direkt über die Hardware, kann die gegebenenfalls infizierte Software (Firmware) in dem Speicher nicht reagieren, denn Hardware liegt unter der Firmware. Und wer in der tieferen Schicht sitzt, kennt die Wahrheit. Die üblichen Web-News schreiben natürlich, daß dieses Rootkit unsichtbar wäre, aber das stimmt nur, wenn man von oben darauf schaut und das Rootkit die oberen Schichten belügen würde, was dieses Rootkit jedoch nicht tut, da es ein einfacher reiner Proof-of-Concept ohne Versteckfunktionen ist. Wäre eine Folge-Version bösartig und würde sie Antworten an Software-Abfragen fälschen, könnte man sie dennoch per Hardware ausfindig machen.

Das oben abgebildete Gerät kann man so kaufen, aber das Lesen und Schreiben der Firmware damit dauert ein paar Stunden, sagt Trammell. Da er viel mit (EEP)ROMs zu tun hat, hat er ein alternatives Gerät gebaut, das die Firmware in Sekunden lesen und in circa einer Minute schreiben kann.

Firmware-Check beim Start

Als Snare 2012 EFI untersucht hat, stellte er fest, daß der Rechner nicht mehr startet, wenn er die Firmware verändert. Er schloß daraus, daß irgendetwas die Firmware validiert beim Boot. Das stimmt. Was nicht stimmte, war seine Annahme, daß eine andere Hardware die Firmware überpüft.

Trammell stellte beim Nachvollziehen des Phänomens fest, daß der Rechner zwar tot ist, aber dennoch kurz die Lüfter anschaltet und wieder ausschaltet beim Booten. Um zu prüfen, ob die Validierung durch Soft- oder Hardware passiert, machte Trammell dann etwas sehr Cleveres: Er änderte die Firmware per Hardware-Zugriff so, daß sie in einer Endlosschleife laufen muß. Passiert die Prüfung nicht in der Firmware selbst, sondern vorher durch irgendeine Hardware, dann würde diese Prüfung aufgrund seiner Manipulation fehlschlagen und die Firmware nicht ausgeführt und darum die Lüfter wieder anhalten. Erfolgt die Prüfung nicht per Hardware, bevor die Firmware startet, dann käme die Firmware zur Ausführung und in die Endlosschleife und die Lüfter laufen immer weiter. Sie liefen tatsächlich immer weiter, was bedeutet, es gibt keine Hardware, die die Firmware vor ihrem Start prüft.

Seine weitere Analyse der Firmware ergab, daß sie einen CRC32-Check beim Boot macht, um sicherzustellen, daß es keine versehentlichen Änderungen gab. Solange man also auch jeweils die Prüfsumme für die geänderte Stelle anpaßt, kann man die Firmware gültig verändern.

Wie oben bereits erwähnt, gibt es eine kryptographische Überprüfung der Firmware nur bei Updates und nicht bei jedem Rechnerstart. Und das ist nicht nur bei Apple so. Der Grund kann einerseits darin liegen, Boot-Zeit zu sparen, obwohl der CRC32-Check auch die ganze Firmware liest, und andererseits nützen Software-Checks nicht viel, weil eine Malware diese Prüfung deaktivieren könnte, wenn sie eh schon die Firmware manipuliert.

Trammell erwähnt noch kurz eine zweite Stelle, an der die Signatur geprüft wird. Das widerspricht jedoch seiner vorherigen Aussage, daß er nach dem Rauslöschen des Signatur-Checks im EEPROM ein Update mit ungültiger Signatur einspielen konnte. Ich habe ihn darauf angesprochen und er antwortete, daß mein Einwand korrekt ist. In seinen Notizen hat er den Signatur-Test in zwei Dateien beseitigt, um den Versuch mit ungültigem Update durchzuführen. Der Vortrag auf dem 31C3 war jedoch schon zu lang und er hat darum dieses Detail unter den Tisch fallen lassen. Solche Ungereimtheiten fallen halt nur auf, wenn man sich intensiv mit dem Angriff auseinandersetzt und ihn versteht. Offenbar haben das die News-Seiten draußen alle nicht getan.

In seiner weiteren Untersuchung fand Trammell heraus, daß die Firmware Volume-Dateien enthält, die komprimiert sind, wie es Intel in seiner Firmware Volume Spezifikation beschreibt. Die Kompressionsart ist LZMA mit Stufe -7.

Nützliche Teile des Firmware-Speichers sind kurz nach Beginn des Boot-Prozesses schreibgeschützt. Der Schreibschutz gilt natürlich nur softwareseitig und nicht für Hardware-Tools wie oben gezeigt. Firmware-Updates passieren per Software und daher bei einem Neustart in einem Recovery-Modus, bei dem die zuvor woanders gespeicherte neue Firmware hereinkopiert wird.

Apples Firmware-Updates kommen in einem SCAP-File, das ein Firmware-Volume enthält, den RSA-Public-Key von Apple und eine RSA-Signatur. Damit wird die Integrität der neuen Firmware überprüft bei einem Firmware-Update im Zuge eines Recovery-Boot. Die Überprüfung macht x86-Software im EEPROM der Firmware, keine Hardware. Wenn die Prüfung erfolgreich ist, installiert die Firmware dieses Update.

Und an dieser Stelle kommt Snares Arbeit Trammell zugute, denn Option ROMs werden auch während dieses Recovery Mode Boot geladen, der die Firmware aufspielt. Das passiert vor dem Prüfen der Signatur der neuen Daten und bevor diese Daten eingespielt werden. Dadurch kann der Angreifer das einzuspielende Update der Firmware manipulieren ohne aufzufallen, denn die Signatur wird danach kein weiteres Mal geprüft. Er muß nur dafür sorgen, daß er die CRC32 / Prüfsummen korrekt anpaßt, weil diese bei jedem Rechnerstart überprüft werden.

Bevor die Signatur-Prüfung des Updates passiert ist, werden also die Option ROMs geladen. Ein kompromittieres Gerät hält Code in seinem Option ROM, der die Funktion ProcessFirmwareVolume(), die die neue Firmware aufspielt, abfängt und die Änderungen vornimmt am Update, das sich in dem Moment im RAM befindet, und dann die originale (abgefangene) Funktion zum Einspielen startet.

Es war anfangs nicht so ganz klar, wann die Option ROMs tatsächlich geladen werden: Nach oder vor dem RSA_check()? Darum habe ich bei Trammell nochmal nachgefragt. Er antwortete, daß das Option ROM vor der Signatur-Prüfung, dem RSA_check(), geladen würde und daß da etwas Komisches vorgehen würde. Er hätte mit jemandem gesprochen, der etwas Einblick in Apples nicht-öffentlichen Firmware-Code hatte, und der sagte ihm, daß Trammell nicht die richtige Funktion abgefangen habe. Es stellte sich heraus, daß die Pre-EFI-Environment-Initialisierungs-Phase (das ist die Phase, vor der DXE Driver Execution Environment-Phase, in der die Option ROMs geladen werden) im EEPROM eine Prüfung der SCAP-Signatur macht und dann das SCAP-Image direkt startet. Das würde bedeuten, sagt Trammell, daß der DXE-Code vom SCAP File aus ausgeführt wird und nicht vom EEPROM. Und dieser Code macht ein Art Signatur-Check (möglicherweise über sich selbst) und ruft dann ProcessFirmwareVolume() auf. Trammell antwortete weiter, daß er ehrlich zugeben muß, nicht völlig sicher zu sein, was in dem Moment dort passiert. Klar wäre nur, daß eine Downgrade-Attacke mögliche wäre. Die verwendet ein altes Firmware-Update. Er habe das Apple demonstriert auf einem MBP101 mit einem B06 Firmware Image. Trammell hofft, daß jemand anderes sich diese Dateien genauer ansehen wird und herausbekommt, was wirklich passiert. Trammell hat aufgrund meiner Frage auch seine FAQs ergänzt.

Denkbar wäre auch, anstatt die originalen Update-Daten zu patchen, ein komplettes eigenes Update im Option ROM zu halten, wenn es groß genug wäre, was es normalerweise nicht ist. Dann würde man nicht einzelne Stellen verändern, sondern das Update am Stück. In beiden Fällen benötigt man jedoch ein Original-Firmware-Update, das erstmal durch die Signatur-Prüfung kommt, um es danach erst zu infizieren.

Die einzige Manipulation, die der vorgestellte Exploit vornimmt, ist jedoch die Ersetzung des Public Keys in dem Update und die entsprechende Angleichung der Prüfsummen der Firmware-Update-Datei und der CRC32-Werte im Firmware Volume, in dem sich die Datei befindet. Beim Einspielen des Updates wird auch der Public Key im EEPROM, mit dem die Signatur von Fimrware-Updates überprüft werden, aktualisiert, durch die Manipulation allerdings mit dem Public Key des Angreifers. Das bedeutet, daß zukünftig nur noch Firmware-Updates akzeptiert werden, die mit dem Private Key des Angreifers signiert worden sind. Apple ist damit nun außen vor.

Um sicherzugehen, habe ich Trammell auch dazu befragt: Warum wird der Key ersetzt? Der RSA_Check passiert doch schon vorher und es würde darum genügen, das Firmware-Update zu manipulieren und man wäre fertig mit dem Angriff. Trammell antwortete, daß sein Proof-of-Concept nicht genug Platz hatte, um einen vollen Exploit zu speichern, darum hat er den RSA-Key im EEPROM ersetzt, um bei einem dritten Neustart ein volles SCAP-File selbst signieren zu können mit dem zugehörigen Private Key, den er ja kontrolliert. In dem File befindet sich dann der größere Payload seines Angriffs.

Der Exploit deaktiviert auch das Laden von Option ROMs im Allgemeinen. Darum kann die Firmware auch nicht über denselben Option ROM Trick wieder gesäubert werden, sondern nur über ein Update, daß der Angreifer signiert oder über ein direktes Ändern des EEPROMs über Spezial-Hardware.

Grenzen

Was ein bißchen untergegangen ist in der Öffentlichkeit und auch bei der Präsentation, ist, daß dieser Angriff in der Praxis offensichtlich kaum einsetzbar ist. Es wurde der gegenteilige Eindruck erweckt, indem Trammell erzählte, das Reinigungs-Personal im Hotel könnte neben neuen Laken auf das Bett auch eben eine Backdoor auf den Laptop ziehen oder die NSA könne mal eben das Gerät beim Versand infizieren lassen. Warum geht das nicht so einfach?

• Dieser Angriff funktioniert nicht, indem man einfach nur ein Thunderbolt-Gerät mit dem Thunderstrike-Exploit anschließt.
• Dieser Angriff funktioniert nicht, indem man einfach nur ein Thunderbolt-Gerät mit dem Thunderstrike-Exploit anschließt und den Rechner neustartet.
• Dieser Angriff funktioniert nur, wenn ein Thunderbolt-Gerät mit dem Thunderstrike-Exploit am Rechner hängt, während der Rechner im Recovery Modus neustartet, weil er gerade ein originales Apple-Firmware-Update installieren möchte.
• Der vorgeführte Angriff benötigt, wie oben beschrieben, drei Neustarts.

Man müßte also den Rechner erstmal normal hochfahren und ein Firmware-Update runterladen und den Update-Prozeß starten. Beziehungsweise sudo /usr/sbin/bless mit einer SCAP-Datei aufrufen, wodurch diese auf die EFI-System-Partition kopiert wird und – dies ist der wichtige Punkt – die EVI NVRAM-Variable "efi-apple-recovery" gesetzt wird. Der Rechner sieht diese Variable beim nächsten Boot und führt einen Recovery-Mode-Boot durch, der die Firmware nicht schreibschützt. Und genau dann kann das Option-ROM die nötigen Manipulationen vornehmen.

Man kann also nicht mal eben den Mac damit infizieren, sondern braucht deutlich mehr Zeit als erst vermutet und muß außerdem noch ein Admin-Paßwort (für sudo und Login) kennen oder einen Root-Exploit mitbringen. Oder man muß dafür sorgen, daß ein infiziertes Thunderbolt-Gerät möglichst immer am Ziel-Mac hängt, um im Firmware-Update-Moment zuschlagen zu können.

Auf jeden Fall muß ein Recovery-Boot ausgelöst werden, das ein originales Apple-Firmware-Update als Input verwendet, denn sonst kommt der Exploit im Option ROM erst gar nicht zur Ausführung, weil die Signatur-Prüfung, die vorher stattfindet, scheitert, und der ganze Update-Prozess abgebrochen wird.

Wenn ein Option ROM die Boot-Parameter so ändert, daß der nächste Neustart als Recovery-Boot durchgeführt wird, dann ist noch die Frage, wie es ein originales SCAP-File auf die Platte legen will, das den Signatur-Check besteht? Auf dem Option ROM selbst ist in der Regel zu wenig Platz. Soll es erst runtergeladen werden bei Apple? Dann funktioniert der Angriff nicht offline am Flughafen oder im Hotel.

Auch dazu habe ich Trammell gefragt. Und tatsächlich bestätigte er mir, daß für seinen Angriff ein Recovery-Reboot ausgelöst werden muß und, daß das Option ROM dafür selbst sorgen kann, und, daß es dann nachsehen könnte, ob SCAP-Dateien verfügbar sind. Den Root-Exploit, den ich oben angesprochen habe, sagte mir Trammell, könne man mit Code aus dem Option ROM erreichen. Ist aber auch nicht ganz so einfach, denn wenn die Platte verschlüsselt ist, muß man in einem ersten Schritt erstmal das Firmware-Paßwort abgreifen, was möglich ist. Das bedeutet jedoch, daß man nicht mal eben infizieren kann, sondern warten muß, bis der User seinen Rechner freischaltet.

Der Proof-of-Concept, so sagte mir Trammell, sollte nur die Angreifbarkeit des EEPROMs vorführen. Es ist kein automatisch komplett funktionierender Angriff. Dazu müßte noch etwas mehr implementiert werden. Der Code seines Exploits ist nicht veröffentlicht worden. Dieser Konzept-Angriff ist also nicht, wie viele Medien berichten, per se in einem realen Szenario voll funktionsfähig, weil er nur die rudimentäre Kern-Funktion demonstriert, und den Rest nicht umsetzt. Erst recht ist dieses Bootkit nicht freigelassen worden oder verfügbar.

Ehrlich gesagt ist man mit der Hardware-Methode, bei der man das Gerät aufschraubt und die Elektro-Klemmen an dem Firmware-Speicher anbringt, um die Firmware dann zu flashen, schneller. Die Thunderbolt-Variante sollte ja eigentlich den Angriff erleichtern und beschleunigen, aber das sehe ich nicht wirklich.

Ein Angriff über Hardware (In-System-Programming) könnte das EEPROM in einer Minute komplett nach Wunsch infizieren. Extra-Zeit würde nur das Auf- und Zuschrauben sowie das Anbringen der Klemmen kosten.

Abwehr-Maßnahmen

Man kann die Schrauben am Gerät unbrauchbar machen oder markieren oder versiegeln, um ein Aufschrauben zu verhindern bzw. zu erkennen.

Für die Thunderbolt-Variante wäre es nützlich, wenn Apple eine Möglichkeit anbieten würde, die PCI-Express-Funktionen in Thunderbolt nach Bedarf ab- und anzuschalten. Wenn man einen Projektor anschließt, benötigt man ja nicht die PCIe-Funktion von Thunderbolt, sondern nur den DisplayPort. Thunderbolt ist ja die Summe aus DisplayPort und PCIe. Denkbar wäre, PCIe in Thunderbolt durch Setzen des Firmware-Paßwortes abzuschalten. Damit wäre auch die Variante von Snare entschärft.

Erkennung

Die Infektion kann immer erkannt werden, indem man die Firmware per Hardware ausliest und vergleicht. Außerdem fällt in konkreten Fall dieses Exploits auf, daß keine Option ROMs mehr geladen werden können. Und darüber hinaus sollte auffallen, daß kein künftiges Firmware-Update von Apple mehr funktioniert.

Der neue Mac mini und der 5K iMac laden keine Option ROMs mehr während Firmware-Updates, so daß diese Geräte nicht mehr durch Thunderstrike verwundbar sind. Apple will ältere Macs ebenfalls bald ebenso aktualisieren. Damit sind jedoch nur die Angriffe über Thunderbolt geblockt, die wie Thunderstrike die Firmware ändern wollen.

Snares Variante

Apples Update bezüglich Thunderstrike hilft gegen Thunderbolt-Angriffe wie den von Snare 2012 jedoch nicht, denn dort möchte man nicht die Firmware während eines Updates manipulieren. Snare persistiert den Angriff gar nicht in der Firmware, sondern im Kernel oder im Bootloader, also der Datei boot.efi. Und dazu genügt ein normaler Start unter normalen Bedingungen mit angeschlossenem bösen Thunderbolt- (oder PCIe-) Gerät. Ein Start im Recovery-Boot-Modus wie für Thunderstrike ist bei Snares Variante nicht nötig. Und nur diesen Fall deckt Apples Fix ab.

Apple sichert Firmware gegen Option ROMs

Mit Apples Fix werden Option-ROMs nicht mehr geladen, während die Firmware schreibbar ist. Damit ist Apples Fix eine Abwehr gegen alle Thunderbolt-/PCIe-Attacken, die wie beispielsweise Thunderstrike die Firmware verändern wollen.

Es ist keine Abwehr gegen Thunderbolt-/PCIe-Attacken, die etwas anderes als die Firmware, beispielsweise den ungeladenen Kernel angreifen, so wie es Snare 2012 gezeigt hat. Diese ältere Klasse von Angriffen will erst gar nicht in das EEPROM der Firmware schreiben, sondern in den Kernel oder Bootloader oder die EFI-Partition der Platte et cetera. Das funktioniert weiterhin. Und das ist nicht mal eben zu fixen, weil man die Geräte von Drittherstellern nicht inkompatibel machen will, die bisher unsignierte Firmware-Treiber im OptionROM halten.

Im Januar 2015 hat Apple in einem Sicherheits-Update, das auch Teil von Yosemite 10.10.2 ist, offiziell beschrieben, daß ein bösartiges Thunderbolt-Gerät während eines Firmware-Updates Änderungen vornehmen könnte. Das wäre behoben worden, indem Option ROMs während EFI-Updates jetzt nicht mehr geladen würden.

Trammell ergänzt dazu, daß der Proof-of-Concept damit tatsächlich verhindert wird. Außerdem wird vermutet, daß dieses Update ein Downgrade auf verwundbare Firmware-Versionen verhindert.

Apples Fix schützt alles Maschinen, auf denen Yosemite 10.10.2 läuft. Ein evenutelles Update für ältere Geräte, die nicht mit Yosemite laufen, gibt es noch nicht.

Nachtrag

Ende 2016 gab es Neuerungen, die das Problem grundsätzlich lösen. Siehe Mac Boot-Prozeß: Option ROMs entschärft.

---