 Hallo, danke. Ich bin Trevor Hudson. Ich nehme gern Dinge auseinander. In diesem Talk rede ich über Apple Thunderstrike. Das ist eine EFI-Rootkit für Apple MacBook. Der Talk hat mehrere Teile. Der erste Teil geht darum, wie ich das zurückingeniert habe. Der zweite Teil geht darüber, wie ich die Thunderstrike-Bootraum-Verwundbarkeit entwickelt habe. Und der dritte Teil geht darum, wie man damit umgeht, dass man das besser löst. Reverse Engineering ist mein Hobby. Eines meiner bedeutenden Projekte ist die Firmware von einer Canon GL-Kamera zu arbeiten. Ich genieße auch sehr mit alter Computer-Hardware, um zu spielen und zu sehen, was für Teile enthalten waren. Zum Beispiel dieser Mac SC, der hat und auch in einem Fotos von allen Leuten, die daran gearbeitet haben, in der Firmware enthalten. Ich arbeite für Two Sigma, ein High-Tech Hedge Fund in New York City. Und die haben mich dabei unterstützt, das zu veröffentlichen und zu entwickeln. Ich möchte mich besonders bedanken bei den Leuten, die auf der Folie stehen. Warum ist ein Hedge Fund interessiert daran, eine Verwundbarkeit für ein MacBook zu entwickeln? Wir haben große Sorge um unsere Sicherheit und wir haben gehört, dass es Verwundbarkeiten gibt beim MacBook, dass es Attacken darauf gibt. Und ich sollte meine Reverse Engineering Skills nutzen, um zu verifizieren, ob diese Attacken realistisch sind. Dann habe ich angefangen, mich darüber einzulesen und Präsentationen darüber zu lesen. Es gibt wirklich eine unglaubliche Menge an schon gehaltenen Vorträgen darüber. Und die, die ich jetzt abbilde, sind viele von denen, die mir geholfen haben, das anzugehen. Viele von denen haben sich von der Intel Windows Seite genähert. Und nur sehr wenige haben auf der EVI oder Thunderbolt Seite angesetzt. Die erste Interessante war die Black Hat Präsentation, die hat mich auf die Idee gebracht. Das erste, was du machen musst, ist, du musst erst mal in das System rankommen, um zu sehen, was da ist. Und Apple benutzt diese neuen Pentalobe-Schrauben, die sind wirklich sehr hart, um ranzukommen. Ich habe es auf die alte Methode gemacht und habe ziemlich unordnungen angerichtet. Man kann aber auch einfach einen anständigen Schraubenzieher dafür kaufen. Wenn man dann drin ist, dann sieht man, wie schön Apple das wirklich gelehrt hat. Und die haben wirklich sehr viel Wert auf die Ästhetik dabei gelegt. Und die, das leert uns selbst. Sie sehen hier das V-Vifi, den Rahmen, die CPU. Beim Bootprozess wird dann am Schluss, ich möchte mich über das Bootraum unterhalten. Das ist der Attack-Vector, den ich benutze. Hier habe ich einfach reingesun. Wir sehen hier die Teilnummer, die haben wir dann das Datenschieter für finden. Das ist ein 64-Mbit-seriales Flash-Rom, ein EE-Prom mit Flash-Memory. SPI bedeutet, dass es für Schimpter-Ganäle hat. Es hat Daten in und raus und eine Schreibfin und eine Stromversorgung. Aber viele andere Leute, die das untersucht haben, benutzen den Pass-Pirate. Das ist ein Logic-Analyser, der häufig benutzt wird. Man benutzt diese Test-Clips, um ihn anzuschließen. Aber das Problem ist, dass der Bus-Pirat sehr langsam ist. Es dauert Stunden, bis der Rom ausgelesen wird oder reingeschrieben wird. Und weil ich viel damit gearbeitet habe oder damit arbeiten, habe ich einen SPI-Flash-Reader entwickelt. Der benutzt ein Arduino-ähnliches Gerät und die ganzen Quellcode ist Quellen offen und kann heruntergeladen werden. Der kann in 1,5 Sekunden den Rom auslesen oder in wenigen Minuten inschreiben. Etwas, was wichtig ist, bis die Batterie entfernt, bevor man den externen Programmierer darin setzt. Sonst können unterschiedliche Spannungen auf den Stromlinien liegen. Das ist oft keine gute Idee. Vor zwei Jahren, als er seine Arbeit gemacht hat, hat er gesehen, wenn er den Rom irgendwie verändert, dann startet es nicht. Er vermutet, dass irgendwas eine Signatur auf dem Boot-Rom überprüft. Das hat mich sehr interessant gemacht. Es hat die Maschine zerstört. Es konnte nicht mehr geöffnet starten, es hat keine Geräusche mehr gemacht. Es kam von außen keiner Geräusche. Aber wir hatten den Unterseite aber und haben ihn umgedreht. Und wenn man ihn startet, dann hat die Kühler kurz aufgetreten. Und wenigstens später schalten sie sich wieder aus. Und das bedeutet, dass irgendwas den Arbeitraum überprüft. Das könnte ein externes Datei. Hat er sein oder es könnte auch nur im Boot-Rom selber eine kleine Software sein? Und die Frage ist nur, wer hat sie überprüft? Wenn es sich umgedreht hat, dann hat die Kühler kurz aufgetreten. Und die Frage ist nur, wer hat sie überprüft? Wenn es nur die Software ist, dann können wir das vielleicht umgehen. Und der einfachste Weg, das auszukriegen, ist die ersten Ausdruck, der ausgeführt wird, zu überprüfen. Und auszukriegen, was das ist, müssen wir nochmal zurückgehen in die späten 70er oder die frühen 80er, in den 88 Prozessor. Und wenn ein moderner Prozessor startet, dann arbeitet er im 16-Bit-Modus und benutzt ihn in größte physikalische Adresse und springt dann woanders hin, um die Initialisierung zu verenden. Okay, den Bus-Pilot verendet. Dann kann man anschauen, was in dem Teil des Arbeitsspeichers ist und wir finden, dass wirklich ein Cash-Pilot springt. Das, wo eine andere Situation stelle im Arbeitsspeichern, um dort was zu machen. Okay, welche Adresse springt es zu? Wir lassen es einfach einen endlosen Schleife dort machen und dann dreht sich das im Kreis. Und als ich das auf den Raum draufgeschlägt habe, gibt es zwei Möglichkeiten. Die Kühler könnten wieder starten und wieder stoppen und dann würde irgendwas externes den Arbeitsspeich überprüfen oder der Kühler bleiben einfach am Drehen und dann wird das ein reiner Software-Check sein. Ich bin hier und darum ist es keine große Überraschung, was passiert ist. Die Kühler sind angeblieben. Also ein Bit Ausgabe ist und wir wissen jetzt, dass ein Signal gibt, was passiert und diese unendlichen Schleifen sind sehr üblich zum Reverse-Engineering. Wenn wir jetzt irgendwo in den Code einbaut und wenn der Code dann aufhängt, dann bedeutet, dass unser Code läuft. Und das bedeutet auch, dass es keine externe Hardware gibt. Hardware hatte früher ein Trusted-Platform-Modul auf ihren Platinen, aber sie haben es nie benutzt und haben es inzwischen entfernt. Okay, kurze Wiederholung. Wir können den Arbeitsspeich im Raum neu programmieren und wir wissen, dass keine externe Hardware ist, die überprüft, ob der Raum funktioniert ist. Irgendwas im Raum wird überprüft in den Raum und zu schauen, wie der Raum organisiert ist, kann man auf die IFI-Spezifikation von Intel für diesen Firmware-Block schauen. Und dort gibt es ein Feld, das sich Signaturen nennt. Aber es ist sehr einfach. Es sind nur vier Charaktere. Unterstrich F, V, H, und dann ist irgendwo eine Check-Summe, aber die ist nur für den Header. Und das andere Interessante ist in dieser Sektion ist dieser Zero-Vektor, der überhaupt nicht wirklich definiert ist, wofür der benutzt wird. Also, wir kommen darauf später nochmal zurück. Wenn ich ein Hextump, und es werden jetzt ein paar Hextumps in dieser Präsentation sein, wenn wir ein Hextump der ganzen ersten Segment des Roms machen und es 64 Kilobytes machen, dann finden wir dieses Anlassrohr FVH Signaturen sehr einfach und dieses Check-Summe für diesen Header. Und der Zero-Vektor dort oben ist nicht null, es ist irgendwas drin. Diese vier ersten acht bytes sind gleich, egal in welchem Firmware-Bereich, aber die letzten bytes verändern sich zwischen den unterschiedlichen Firmware-Versionen. Und das ist irgendwie interessant. Um rauszufinden, wo wir verschiedene Dinge im Raum finden, haben wir jetzt angefangen nach Strings zu suchen, mit dem Strings-Programm selbst. Wir haben Sachen gefunden wie halt diese FVH Signaturen und dann gab es weiter unten einen String, der hieß ROM Integrity. Das ging gut. Also ich benutze jetzt Hopper, einen interaktiven Disassembler, um zu sehen, was in dieser Sektion im Rahmen steht. Ich muss mich dahin schuldigen, es ist ein bisschen klein. Ich gebe die Snides folder frei, dann könnt ihr euch die anschauen. Wir sehen hier die Prüfsumme. Weiter unten sehen wir, macht das etwas ein Offset A in den Null-Vector hinein. Eine Sache, die Hopper machen kann, ist, dass man Sudo-Code kriegt für die Stelle, die man anschaut. Und das hier sieht aus wie ein Funktions-Move auf den Datenpart des ROMs. Dann vergleicht es diesen Teil des Null-Vectors mit diese Funktion, das also sicher beteiligt an der Überprüfung der Validität dieser Signature. Und jetzt benutzen wir Hopper, um in diese Funktion reinzusteppen und stellen fest, dass sie iteriert. Es greift dabei auf eine Tabelle zu. Rudolf hat vor ein paar Tagen vorgeschlagen, dass wenn man in diese zufälligen Hex-Werte sieht, einfach mal in Google reinhauen oder in eine andere Suchmaschine, und man stellt fest, oh, diese Konstanten tauchen alle auf in eine Datei, die wir gefunden haben. Jetzt können wir schon raten, dass diese Funktion da CRC32 ist. Und jetzt können wir einen Ein-Byte-Änderung in der Firmware machen und hoffen, dass wir die Prüfzumme danach wieder ausrechnen und es drauf flaschen, dass es dann funktioniert. Jetzt haben wir einen neuen Punkt auf dieser Folie. Es gibt also nur ein CRC32 Check, kein kryptografischen Überprüfung. Das ist nur dafür da, dass man nicht zufällig eine Programmierfehler hat oder eine zufällige Änderung. Das heißt, man kann, wenn man will, den Raum ändern. Aber warum ist da eigentlich kein kryptografischer Check zur Bootzeit? Andere Forscher haben sich das angeschaut und haben gemeint am Schluss, flashbasierte Roms werden nur überprüft, wenn sie geupdatet werden und nie wieder danach. Ein möglicher Grund dafür ist, dass es einfach eine Performance-Wage ist, dass man schneller booten kann. Aber man muss da sowieso den ganzen Raum lesen. Insofern macht das keinen wirklichen Sinn. Das Problem ist, wenn man wirklich eine bösartige Software hätte, dann könnte sie einfach diese Überprüfung auslassen und einfach nur durch immer Wah-Ersetzen zum Beispiel durch einen vorgenerierten Hash. Nur wenn man wirklich spezielle Hardware hat, würde es Sinn machen, auf diesem Level das zu überprüfen. So, wo sind jetzt all diese Strings, die wir suchen? In den ganzen 8 MB dieses Roms sind nur wirklich sehr wenige Teile, die sinnvolle Menschen lesen bei Strings in Hilton und die waren relativ weit vorne. Das ist relativ interessant, dass diese weit vorne waren hier. Diese Region, wo keine Intrepi war, da ist nichts und im restlichen Bereich ist sehr hohe Intrepität und das bedeutet entweder, dass es verschlüsselt oder komprimiert ist. Also, wenn wir uns den Raum anschauen und welcher Teil davon anzuschauen ist, dann gibt es diesen Flash-Beschreibungsregion. Flash-Rom bedeutet, dass die BIOS von dieser Funktion bis zu der anderen Funktion ist. Schauen wir mal, was in der BIOS-Region gespeichert ist. Also, wir gehen zurück und sagen Hex-Dump und es sieht so aus als sei ein Firmware-Image, ein Firmware-Image-Datei-Sektion. Das heißt, es gibt drei Bites für den Link. Der nächste Bite ist den Sektionstyp, zum Beispiel eine Boot-Kompress-Sektion mit das, was wir gedacht haben. Und dann schauen wir zu der kompressierten Sektion-Dokument in der Spezifikation und den nächsten vier Bites sind die unkomprimierten Link. Dann das nächste Bite ist der Kompassionstyp und wenn der Typ zwei ist, dann ist das irgendwie nicht definiert in der Spezifikation. Okay, das ist ein kleines Problem. Aber was die Leute gesehen haben, ist, dass die nächsten vier Bites in allen Firmware-Sektionen gleich ist. Okay, also, wenn wir irgendwas so sehen, wir packen es mal in die Suchmaschine und wir haben einen super Tipp für die LZMA-File-Format gefunden. Um das zu verifizieren, kann man ein Tool wie DDN benutzen, um die kompressierten Bites, die ersten 9 Bites überspringen, durch LZCAD-Dekompressieren und kein Problem von dem Dekompressieren und Software. Die Feilgröße ist richtig mit dem im Header und es sind wirklich menschlich lehensbare Strings. Die sind Gold wert, wenn man sucht, insbesondere Print-Text-Strings wie Zero-D und so weiter. Die erzählen ein, wie die Sachen innerhalb des Guards funktionieren. Wenn man sowas hat, ist es relativ einfach, rauszufinden, was passiert. So, wir wissen jetzt, wie die Firmware-Voluteil komprimiert sind. Wir können ein neues Datei draufflaschen nach einer neuen Komprimierung. Ich bin nicht der erste, der das herausgefunden hat. Aber ich habe es noch nie in zwei sonst hingeschrieben gesehen. Jetzt ist es da draußen, sodass andere Leute sich auch diese Firmware-Voluteils anschauen können. Vielen Dank. Also, warum können wir nicht einfach ein Bootrom-Flash mit Software schreiben? Warum müssen wir diesen Hardware-Programmar benutzen? Es stellt sich raus, dass der Flash-Shap nicht direkt mit der CPU verbunden ist. Er hängt eigentlich an dem Platform-Controller-Hub und Zugriff wird über die Management-Engine geregelt. Wenn das System bootet, dann empfiehlt das UEFI Forum, dass all diese Regionen so weit wie möglich gelockt werden. Diese Lockdown verhindert Zugriff auf Konfigurationen dieser Dinge und man braucht nur durch ein Hardware-Viset entfernt werden. Das heißt, man kann auf diese Teile des Roms nicht geschrieben werden. Aber wir wissen ja, dass Apple selber das schreiben kann. Die bringen ja regelmäßig neue Firmware-Versionen heraus und die werden ja auch geschrieben. Es gibt diese Netegui dafür, die sicherstellt, dass es die richtige Version für dein System ist. Aber es stellt sich raus, dass es ein Command-Landtool gibt. Das heißt, Blast. Es nimmt das S-CAP-Fall, das in dem Image, was man runtergeladen hat, enthalten ist und schreibt es auf die System-Phalzition und setzt die UEFI Variable und das sagt dem UEFI, dass es in einem Recovery Mode Boot gehen muss. Was steht jetzt da drin? Jetzt haben wir einen weiteren Blob, von dem wir herausfinden müssen, was da drin steht. Hexdumps wurden inzwischen viel zu sehr Teil meines Lebens, dass sich da einfach draufstarrt den ganzen Tag, um zu lernen, was in der Maschine vor sich geht. Und wir können sofort sehen, dass da wieder Unterstrich-Fall-Volume FVH ist. Und jetzt stehen aber noch 50 Bytes vorne dran. Aber ganz am Anfang steht auch ein 50-byte Wert. Und die Volumengröße sieht man aber weiter an anderer Stelle. Und es gibt noch einen ähnlichen Wert, woanders sind Header. Das ist die totale Größe, also die Gesamtgröße inklusive dem zugefügten Header. Was macht man, wenn man sowas sucht? Jetzt gibt es diese 16 Bytes ganz am Anfang. Dies ist eine GUI, also ein global eindeutiger Identifizierer. Die werde ich jetzt auch wieder einfach in die Suchmaschine hauen. Und wir haben mal wieder einen exakten Übereinstimmung in der Spezifikation von dem EFI Header. Da stehen auch wieder verschiedene sinnvolle Werte drin, unter anderem die Headergröße und die Milchgröße. Aber jetzt sind extra 32 Bytes am Ende des Hexfalls, die nicht da sein durften. Schauen wir uns die mal genauer an. Das ist eine ziemlich hohe Introbi. Nichts menschlich lesbares, alles zufällige Werte. Aber möglicherweise ist das hier eine weitere GUI, die also wieder ein eindeutiger Identifizierer wie Google ist. Und es gibt genau einen Treffer. Das ist ein Mailing List Host von vor zwei Monaten. Ich wünschte, ich hätte den viel, viel früher gefunden. Der hätte mir viel geholfen. Und es beschreibt RSA 2048 Shah Hash. Und dabei wird eine C-Struktur beschrieben, die relativ stark übereinstimmt mit dem, was wir gesehen haben. Also haben wir jetzt gerade eine ziemlich gute Idee, was eigentlich passiert. Aber mein nächster Schritt wird jetzt einfach sein, das zu überprüfen, ob das stimmt. Das ist jetzt ein Pearl-Programm geschrieben. Mir ist klar, dass das viele Leute schrecklicher finden als Assembler. Aber hey, das hier liest einfach das SCAP, die SCAP-Datei, die wir haben, extrahiert das Firmware-Volumen, den RSA Public Key und die RSA Signature. Und es benutzt dabei den default RSA-Exponenten. Vielen, vielen Dank an meinen Kollegen Victor de Kovni, der vorgeschlagen hat, die Beidorder umzutauschen in Big Indien. Als wir das fertig hatten, haben wir angefangen, haben das Image gebaut und die Signatur war okay. Also wir haben herausgefunden, wie etwa sind diese Signaturen erstellt dafür. Jetzt wissen wir nicht nur, wie sie signiert werden, sondern wir haben auch schon realisiert, dass Blast die Signatur gar nicht überprüft. Es muss also irgendwas im Bootvorgang selber sein. Und jetzt als Warnung an euch, wenn man mit Blast einen nicht gültigen Datei signiert und das dann auf seinem System spielt, dann gebrutet die Maschine nicht mehr. Man muss dann einen vollen V-Set machen, um wieder an die Maschine überhaupt dran zu kommen. Wo werden die Signaturen also wirklich überprüft? Es muss irgendwo in diesem Update-Prozess sein. Es könnte Hardware sein, klar. Es könnte die Management Engine oder es könnte doch wieder Software sein. Also machen wir einen binären Grab, das ist den Suchtvorgang, und finden eine Datei im komprimierten Raum und wir sehen, dass es übereinstimmt mit allen drei, und wir schauen uns den Code an, der damit arbeitet. Und wir stellen fest, dass es den eindeutigen Identifizierer überprüft, dass es die Dateigröße überprüft. Und dann wiederum finden wir eine Referenz auf die andere eindeutigen Identifizierer in eine Tabelle. Das ist interessant. Wenn wir jetzt weiter unten gucken im Code, dann sehen wir, dass es diese Firmware-Volume übergibt und den Inhalt als Funktionspointer mit dem Offset Hacks 89 übergibt. Um das jetzt wieder herauszufinden, was das macht, gehen wir wieder in die Spezifikation und die geben uns keinen Offset, aber wir können einfach durchzählen und stellen fest, dass es etwas ist. Das heißt Process Firmware-Volume. Das nimmt die komprimierte Variante von diesem Firmware und im Prinzip mountet es einfach in der Teilsystem und macht das andere Funktionen zur Verfügung gestellt. Und jetzt haben wir noch eine weitere Funktion gefunden. Das ist Hex E. Das ist ein Dispatch. Das führt einfach den Code aus, den es in diesem Image findet. Okay, lassen Sie es einfach in Solo-Code übersetzen. Okay, es überprüft am Anfang die eindeutigen Identifizierer. Dann verifiziert es die SKAP Signatur. Dann führt es das aus und mountet das Image und führt die Funktion darin aus. Und springt dann in diesen Flasche rein, der in dem SKAP Fall ist. Nachdem, was wir jetzt schon wissen, wissen wir jetzt, wie wir Änderungen an dem Rom machen können, um herauszufinden, wie man das genau machen muss. Eine Frage, die ich jetzt hatte war, ist der RSA-Überprüfung der einzige Stelle, wo man dann noch was überprüft wird oder gibt es noch zusätzliche Hardware-Checks eventuell oder andere Software-Checks? Ich habe es jetzt einfach mal auskommentiert. Dann hat er ein non-sense SKAP-File generiert. Das ist keine valide SKAP-Datei-Signatur. Wenn ich das jetzt mit BLESS bearbeite und die Maschine blockt dann, dann wissen wir, dass es wieder ein Hardware-Komponente ist, die das überprüft. Und wenn es dann trotzdem das Image drüber schreibt, dann wissen wir, dass es ein Software-Check war. Ihr könnt schon wissen daran, dass sich jetzt die Vortragheit ja was wirklich passiert. Und das ist jetzt schon ziemlich besorgniserregend. Das heißt, alles, was überprüft wird, wird durch Software überprüft. Es gibt keine Hardware-Verifizierung. Die Frage ist, können wir jetzt da irgendeine Änderung machen, ohne dass wir das System intern mit der Maschine öffnen und in den Arbeitsspeicher gehen und den anschauen, aber mit dem, was wir bisher gemacht haben, mit dem Thunderbolt-Port können wir das vielleicht machen. Thunderbolt bringt den internen PCIe-Bus zu der Außenwelt. Wenn der System startet und irgendwelche Memory-Geräte auf dem haben, schauen die, ob sie irgendwelche Options-Arbeitsraums haben, die ausgeführt werden sollen. Das ist ein altes Feature, das zu dem ersten IBM PC zurückzuführen ist mit einem Intel 880. Das BIOS war ein maskierter ROM und dann waren andere Personen, wo weitere ROMs sind, wo Basic oder Geräte treibbar sind. Und der ISA-Expansionsbus konnten auch ihre eigenen ROMs haben, die auch geladen werden mussten, das BIOS. Und das ist ein Legacy-Feature, das sehr alt ist. Und wenn man das als Angriffsvektor macht, dann ist es nicht etwas, was eine neue Idee. John Heathman hat in 2007 bei Blackhead gezeigt, wie man über ein Erweiterungskart angreifen kann. Und die PCIe, die war als Expansion-Rom, ist sehr toll. Dann könnte man den OS X-Kernel eine Hintertür einbauen. Das wurde 2012 gemacht. Und das ist immer noch drin. Wenn man seinen Thunderbolt-Adapter hat, mit Option-Rom-Explor drauf und den System startet, dann kann man ein Firewalls-Passwort machen. Ich habe es seitdem geändert zu einem Password 1. Das ist viel sicherer. Das Problem ist, dass die Options-Rom nicht auf den Flash speichern kann, weil sie in der DXI-Phase gesputzt geladen werden. Und der Flash wurde in der PII-Phase blockiert. Aber außer dem Boot-Rom-Firmware-Updates, dann ist der Flash nicht blockiert. Und wir haben gesehen, dass der Flascher, das Flash die Kürde wie 64 kMitmode, in der DXI-Phase geladen ist, zusammen mit den Upload-State-Roms, sind Option-Roms auch dieser Firmware-Updates-Phase geladen. Und mich das ausprobieren wollte, ich könnte durchgehen und reverse-engineering sich einen Grund machen, aber das ist zu viel Aufwand. Ich bin nicht in den Infiniten Loop-Track gemacht. Ich bin in den Arbeit-Option-Rom gemacht, der einen endlosen Kreis, den man so schleifen macht. Und die EFI-Firmware ist nur ein Thread, und das hält die Maschine einfach an. Und wenn ich jetzt den Thunderbolt mit dem Infinit Loop-Option-Rom anschließe und die Maschine starte und nachdem der Teil kommt, und wenn es in Firmware-Updates geht, dann ist das Option-Rom nicht geladen und ausgeführt, aber wenn die Ventilatoren einfach drehen und die Maschine kaputt erscheinen, dann werden die Option-Roms geladen und ausgeführt. Ihr wisst, was die Antwort ist. Ja, Option-Roms werden geladen während der es in dem speziellen Start-Modus ist. Aber nach der PI 32-Bit-Mut-Signature-Check auch für das ESCAP-Datei, bevor der Option-Rom ausgeführt wird. Okay. Gibt es eine Möglichkeit, diesen Check zu umgehen? Okay. Wir haben jetzt den Pseudekort noch mal anschauten von dem Flasher-Figration. Process-Firmware-Volume wird gerufen über einen Funktionspointer, der in Arbeitsspeicher ist, nicht im Raum. Das heißt, das Option-Rom könnte diesen Funktionspointer umspringen. In einem Prozess, der nennt sich Hooking. Wir können den Option-Rom modifizieren, diesen Process-Firmware-Volume zu hooken und mit seiner eigenen zu ersetzen und den alten zu speichern, das man später wieder benutzen kann. Wenn man jetzt einen ausreichend großen Option-Rom hat und den ganzen Firmware-Exploit da drin hat, dann ist es fertig. Aber den Adapter, den wir benutzen, den Gigabit-Ethernet-Adapter, dann ist da nicht genug Platz drin. Also, wir können keine acht Megabytes-Rom da reinschreiben. Aber was wir uns ausgedacht haben, ist noch interessanter. Wir können anstelle dessen ein RSA-Publickey, den wir unterstützen und den Process-Firmware-Volume-Function sucht nach Apple's öffentlichen Schlüssel und dann kopiert unseren öffentlichen Schlüssel an seine Stelle und dann macht man den RSI zu R30 und macht die alte Process-Firmware-Volume auf das neue modifizierte Abbild. Wenn wir jetzt die Maschine starten mit dem Thunderbolt-Device eingesteckt und jetzt hätten wir ThunderStrike aus-Exploit, weil all das ist heute zu der genommen haben muss, dann starten wir die Maschine und hier ist der Exploritschritt, der läuft in diesem speziellen Start und wir schauen, können wir uns nicht darüber, ob das geheim ist und hier ist die normale Firmware-Update-Routine auf den Bootraum, auf dem Mainboard und jetzt ist das unser System entwickeln, was auch immer ein Flash wir darauf machen können mit der Benutzung von Apple's eigenen Flash-Tools. Also alle modernen Explorits brauchen natürlich Logos und Theme Songs heutzutage. Wir wissen jetzt also, wie man um die komplette Flash-Sicherheit drumherum kommt und dadurch, dass wir diesen Schlüssel ersetzt haben, kann man dieses Image gar nicht mehr ersetzen durch Software, weil wir jetzt kontrollieren, was funktioniert und was nicht. So wie würde man das jetzt im Ernstfall einsetzen, wenn man das wirklich benutzen will? Also so was Ähnliches wie die NSA vielleicht. Die fangen einfach hardware ab, machen kleine Änderungen und schicken es dann weiter. Die andere Attacke ist die Evil-Made-Attack. Man geht zum Beispiel auf einer Konferenz, man geht im Hotel zum Frühstück und der Room Service kommt und macht das Bett und verpackt deine Backdoor in deinem Laptop und bringt dir neue Handschücher. Oder wenn man zum Beispiel internationale Grenzen überquert. Also zum Beispiel haben amerikanische Gerichte bestätigt, dass es keinen Schutz für Bürger oder auch Nichtbürger der USA gibt, dass man deren Elektronik schützen müsste. Imgiblich sind Laptops das gefährlichste Schmuggelgut, was es geben kann und es gibt keinerlei Erwartungen, dass das privat sein sollte. Diese Verwundbarkeit ist in so ziemlich jedem MacBook seit 2011 ungefähr seit Vanderbolt das erste Mal aufgetaucht ist. Die Geräte vor Vanderbolt sind alle nicht betroffen. Die haben auch maskierte Rooms in Sofans, die sowieso etwas schwieriger. Ihr habt vielleicht auch schon von Stuxnet gehört. Das wurde über geteilt USB-Medien verbreitet und hat es wirklich geschafft, in die vom Netz genommenen Scala-Systeme verbreitet und es stellt sich raus, dass diese Vanderbolt-Devices von dem Bootcode überschrieben werden können. Sag mal mal, du hast ein Vanderbolt-Internet-Gerät, das du mit den Maschinen in der Arbeit teilst. Dann kann das wirklich auch über Geräte hinweg überspringen. Also alle MacBooks, modernen MacBooks sind infizierbar und es kann sich viral fortbreiten. Ich habe jetzt mit Apple geredet und sie haben inzwischen auf den neuen Maschinen, die Mac Mini zum Beispiel und all Mac Multenar, laden keine Option Rooms mehr beim Upgrade-Prozess. Aber sie laden immer noch Option Rooms durch den normalen Bootprozess und Snare-Attacke von 2012 funktioniert immer noch. Man kann immer noch den Kernel infizieren im Prinzip damit. Man kann eine Downgrade-Attacke auch fahren, dass man eine alte SCAP-File einspielt und dann von da aus weiter arbeitet. Thunder Strike 2 benutzt eine sogenannte Attacke, die heißt Dark Jedi Sleep. Gestern wurde die vorgestellt. Das ist von Rafa und Quori. Was sie machen ist, bei einem ACPI S3 Schlaf werden alle Lockdown-Bits auf Null gesetzt. Das heißt, es ist komplett offen. Während dieser Zeit kann man alles machen, im Prinzip. Alles läuft auf Ring Null. Es gibt keine Checks. Ich habe gestern Abend versucht, das noch zu machen, aber ich hatte nicht genug Clubmaht, um es durchzuziehen. Also, wartet auf ein Paper. Wenn Apple wirklich anfangen würde und wieder TPM Hardware bei den MacBooks einbauen würde, würde das immer noch nicht zwingend helfen. Sie müssten die Treiber auch signieren. Das ist in Zukunft auch vorgeschrieben, aber heute in der jetzt verwendeten Version ist das immer noch nicht. Es ist alles so ein bisschen vageformuliert. Man sieht hier die Implementierung. Es stellt sich raus, dass dieser Point nie Null sein kann. Es verifiziert immer jedes Rom, was ihm vorgesetzt wird und bringt also überhaupt keine mehr an Sicherheit. Also, meine Geräte brauchen alle keine Thunderbolt-Option-Roms. Insofern habe ich alle meine Macs so modifiziert, dass er diese Funktion auslässt und gar nicht mehr tut. Das heißt, interessanterweise kann man Thunderstrike jetzt gar nicht mehr benutzen, um Thunderstrike zu entfernen. Das heißt, die Tour haben wir hinter uns zugeschlagen. Aber jetzt ein Lockdown auf dem Option-Rom zu machen, ist vielleicht gar nicht genug. Wie viele von euch hier haben sich schon mal mit dem Projektor verbunden hier und auch verifiziert, was das ist. Es gab auf der Black Hat ein Vios der hieß Eloy Viper und der ist ein Fake-Adapter, der sich über einen richtigen VGA-Adapter mit dem Rechner verbindet und hängt dann direkt am PCI-Bus. Dadurch können sie eine Thunderstrike-Attacke direkt auf der Maschine fahren. Ich glaube, wir brauchen eine Wege, um PCIe komplett abzuschalten auf Thunderbolt. Wenn man einfach nur was darstellen will, über Video oder so, dann sollte man eigentlich sich dieser Gefahr nicht aussuchen. Das wäre eine Sache, die Apple in der Konfiguration erinnern könnten. Genau wie jetzt, dass man jetzt zum Beispiel nicht von externen Medien buten muss. Und es sollte möglich sein, dass man einen Option-Rom so allen stellt, dass man diese PCIe einfach ausschaltet. Jetzt ist es mal, wo der ausprobiert, manche Pins einfach auszulöten. Und es wurde überlegt, wie man ein Thinkpad dadurch stabiler gegen externe Angriffe macht. Und wenn man soweit geht, dann könnte man auch vielleicht eine temperateffidentes Füllung machen. Zum Beispiel, wenn man diesen Nagelack drauf macht, dann kann man sehen, ob irgendjemand die Maschine geöffnet hat. Der auch beim letzten Nagelack, beim 30. C3 gemacht. Okay. Wie du, Lim, könnte so ein Thunderstrike-Bootkit sein? Okay. Niemand schaut nach Firmware-Rootkits an OS X. Es wäre von Anfang an im Kontrolle des Systems, es könnte alles machen, was man mit dem Computer macht. Es kann nicht mehr Software entfernt werden. Weil dieser auch die RSA und die Update-Routine kontrolliert. Man kann OS X neu installieren. Und das ist immer noch klar sein. Man kann die SSD austauschen. Man könnte den kompletten Laptop austauschen. Und es könnte immer noch ein Thunderbolt-Griffin hier drauf kommen. Es kann sich hier verstecken durch Virtualisation oder Management-Funktion. Und es kann viral über verteilte Thunderbolt-Geräte ausspringen. Und es ist problemat für alle Modelle das Intel MacBooks mit einem Thunderbolt. Und es wäre nicht sonderlich kompliziert, das in einen wirklichen Angriff zu machen. Und ich glaube, dass man das sogar entfernt installieren kann. Wenn man das mit dem DeepJetai-Commerce und mit Options-Roms innerhalb eines Systems baut, dann könnte man das möglicherweise nur mit einem Rootexploit installieren. Auf dieser guten Note nehme ich jetzt ein paar Fragen. Und außerdem haben wir einen HDC um 19.45 Uhr und die Firmen beim Bodule reinzuschauen. Kurz nach der Präsentation. Gibt es Fragen aus dem Internet? Ja, es gibt eine Frage aus dem Internet. Wie viele Max wurden für diese Präsentation zerstört? Ich war sehr glücklich sowohl in der amerikischen Laterna als auch mit dieser Maschine. Ich habe keine Geräte zerstört. Ihr könnt euch auch hinter den Mikros aufstellen, wenn ihr eine Frage habt. Zweite Frage aus dem Internet. Doch keine zweite Frage, anderes Mikro, bitte. Sehr coole Präsentation. Vielen Dank. Wenn man von Thunderstrike betroffen wurde und man eine andere Firmware versucht zu installieren, das kommt zerstören. Aber man könnte das auch umgehen. Wenn man zum Beispiel die Firmware umschreibt, dass es von einem Apple signierter Datei ist, kann man das einfach umschreiben. Man hat komplette Kontrolle über den Update-Prozess. Man könnte sogar sagen, dass das Update durchgeführt wird. Danach wird es wieder ausgepatcht. Das ist sicher. Man könnte auch nur sagen, dass man das so tut, als sei das Update ausgeführt. Man hat komplette Kontrolle. So wie ich es verstehe, muss man ein UEFI-Upgrade auslösen während der Thunderbolt dabei ist, oder reicht es nicht ab einem Einstieg? Der Optionsarbeitsspeicher kann keinen UEFI-Update machen. Aber alles, was der Colonel machen kann, kann man machen. Man muss einfach anhängen, oder muss es in der Bootphase dran sein? Mit dem passiven Gerät, wie den PCIe-Iseernet-Adaptor, muss es während der Bootphase sein. Ich muss es wirklich neu booten. Wenn es gebootet ist, kann man das Problem arm an einem neuen Bildschirm anschließen. Aber es ist selten, dass Max ein Fidder haben. Es kann auch sein, dass man es nicht abmacht, wenn er das am Monitor hängt. Also diese Sache könnte sich verhindern lassen, wenn man Option-Rom-Siming macht, oder? Ja klar. Ich glaube so. Microphone Nr. 5? Hi, thanks for your talk. Danke für den Talk. Könntest du dir nicht vorstellen, dass es auch auf anderen Laptops funktioniert? Also mit PCI Option-Roms? Auch auf nicht-Apple-Laptops? Ja, der hat PCIe-Angriff mit einem programmierbaren Option-Rom über verschiedene Scatter-Controllers und es sind möglicherweise Probleme, aber Evil-Made-Angriffe über ein Makebook, über Thunderbolt ist deutlich einfacher, als ein Laptop aufzumachen und ein neues Teil einbauen zu müssen. Microphone Nr. 1? Das würde also auch bei anderen Maschinen mit Thunderbolt funktionieren. Zum Beispiel die neuen Lenovo. Und wenn man das TPM ausmacht, wäre man dann verwundbar oder wenn jemand den privaten Schlüssel hat und es damit signiert, wäre man dann verwundbar? Ja, genau. Und wie es dir gesagt hat, wenn man ein Secure Boot hat, die Option-Roms wirklich ordentlich signiert, dann funktioniert das natürlich nicht. Aber ein Geld mit Thunderbolt könnte trotzdem noch über ein Storz-Creamer machen können, was ein aktives PCI Evil-Made-Gerät ist. Noch eine Internetfrage? Danke. Ich habe noch zwei Fragen. Die erste wäre, könnte man auch eine reine Software-Lösung und die zweite ist, gibt es einen Weg rauszufinden, ob man ob das Rom beschädigt wurde bzw. damit Spindler getrieben wurde? Okay, also es ist möglich, dass man eine Software schreiben kann, die Bars-Updates machen kann, aber die Anzahl von Präsentationen, die Softwarefehler finden, insbesondere in Bars-Updates, ich glaube, das ist ordentlich. Und das ist nochmal die zweite Frage? Gibt es eine Möglichkeit rauszufinden, ob das Rom noch okay ist? In meinem Proof-Concept ist es sehr einfach. Wenn es fehler ist, dann ist es einfach ein neues Logo. Aber wenn man eine Waffenversion davon nimmt, dann könnte es sehr kompliziert sein. Wenn man in einem kann man schauen, in bestimmten Modus schaut, ob man da was zu schreiben kann oder man kann das Gerät in virtuelle Maschine geboten und man könnte einen anderen Control-Rom schauen, der ordentlich ausseht. Wie kurz war? Fehlen in irgendwelche Features, wenn man das ausmacht, dass man Option-Rom lädt? Nein, es gibt die Internet-Adapter, der ist von Anfang an studiert, das heißt, der Option-Rom ist inzwischen weitestgehend benötigt. Zwei kurze Fragen. Sie haben gesagt, dass man diese Bläs benutzen muss um die Firmware zu machen. Das heißt, ich muss immer mein Passwort setzen bevor ich ... Nein, das Firmware-Passwort wird überprüft nach dem Option-Rom geladen werden. Das heißt, dass man einfach einen Griff in Option-Rom kann, ganz einfach das Firmware-Passwort überschreiben. Und den anderen Punkt, eine Frage, der zu unserem Rom nicht wirklich aus 10 Boutons ist. Man kann eine Variable setzen und ein Recovery-Reboot machen. Man kann da beliebig Gesachen mitmachen. Ich glaube, dass eine Open-Source-Lösung dafür gefunden werden kann. Würde dieses Problem eventuell verbessern oder lösen, haben Sie schon mal Richtung Core-Boot geschaut oder ... Ich glaube nämlich, dass das nicht gegen diese Attacke verbundbar wäre. Ich weiß es nicht. Aber generell ... Lassen wir uns noch mal reden darüber. Wir sollten darüber reden. Aber ich glaube, dass Open-Source für den frühen Bootstraat sehr wichtig ist, sowohl zu überprüfen, ob man das System macht, was wir denken, dass es macht. Darum bin ich sehr freu, wie das über Bunny-Slaptop, wo alle Sachen in Quellen offen ist, dass er verstehen können, wie alles funktioniert. Ich komme ein bisschen aus der Zeit. Bitte die Fragen und Antworten. Sie haben gezeigt, dass das Firmware-Update nicht nur die Signatur, sondern auch den öffentlichen Schlüssel enthält. Was passiert, wenn Sie den öffentlichen Schlüssel austauschen und eine andere Signatur stellen? Wie ist das ausprobiert? Ja, ich habe der Präsentation dann nicht geschaut. Ich habe ein Peppe geschrieben, dass es bald rauskommt, dass in viel mehr technische Details geht. Der öffentliche Schlüssel in der Signatur ist ignoriert. Da kann man reinschreiben, was man möchte. Es ist total egal. Der öffentliche Schlüssel ist im Bootraum gespeichert. Es gibt fünf Publikis da drinnen, aber nur ein Schlüssel wird überhaupt geleit. Nur dieser Schlüssel wird benutzt, um die Signatur zu überprüfen. Haben Sie schon mal andere Angriffswektoren angesehen, außer Thunderbolt, die PCI Express Leaks öffnen? Nein, habe ich nicht. Aber ich habe eine Nehme bekommen, von jemandem, der mal reingeschaut hat. Kann ich diese Attacke über einen anderen Mac mit einem Thunderbolt-Kabel absetzen? Das ist eine interessante Frage. Ich habe dann nicht reingeschaut, ob man Target Drive Boot ficken kann. Möglicherweise? Das könnte billiger sein. Ich weiß es nicht. Ich habe dann auch nicht wirklich reingeschaut in den Teil der Firma. Sie haben gesagt, dass mit Ihrer Verwundbarkeit könnte man auch die Tür hinter sich zuschlagen. Das kann man nicht nutzen, um alle Macbooks sicherzumachen. Wenn irgendjemand ein Thunderbolt-Adapter ausleihen möchte, im Moment meine Proof-of-Konzept hat ein paar Sachen, die noch nicht ordentlich funktionieren. Ich habe überprüft, dass der Exploit funktioniert gegen andere, aber ich habe nur einen Macbook implementiert. Das heißt, wenn Sie einen von dieser Version haben, können wir das mal ausprobieren. Ich wundere mich, nachdem die Option-Rom nur beim Boot geladen wird und man kann nachher das mit Firmware-Passwort verhindern. Sie haben gesagt, man kann das Option-Rom trotzdem noch schreiben. Früher im Bootprozess. Haben Sie schon mal versucht, herauszufinden, ob das vorher passiert? Wirklicherweise? Wahrscheinlich, wenn man ein lauberes System hat, dann könnten wir den Option-Rom rauslesen und ob der Exploit drauf ist. Aber, sobald das System infiziert ist und es ausreichend geheim ist, dann könntest du diesen Versuch, das auszulesen erkennen. Das war eine zweite Frage. Es gibt viel interessante Arbeit mit Thunderbolts und DME-A-Angriffen. Wie gut funktioniert VTT bei dem und es ist nicht klar, dass es so viel Verteidigung bietet, wie man sich vorher gedacht hat. Es geht irgendwie um Virtualisierung. Bitte vergeben Sie, wenn das jetzt eine dumme Frage ist. Aber könnte ein Hersteller uns schützen gegen diese Attacke durch Zeit, timing-basierte Signature-Tests, dass man die Zeit festhält, dass man die misst beim Buten und das dann vergleicht? So, dass wenn ein Angreifer seine Firmware hoch lädt, dass er dann auch den Sidestell mit emulieren muss. Zum ersten Teil der Frage glaube ich nicht. Der braucht man wirklich ein Tick zu sein und das konnte diese Funktion umgehen. Und andererseits kriegt man das System zum Beispiel virtualisiert starten oder man könnte den Timestamp-Counter verändern. Ich meine, es ist in Ring 0, da kann man alles machen. Danke. Eine andere Frage von Nr. 4? Ein paar kurze Fragen. Der war zu veröffentlichen, dass die neuen iMacs und iMacs nicht betroffen sind und die neuen Macs werden wahrscheinlich nicht mehr haben. Ja. Apple hat einen Macs produziert und in der aktuellen Mac Macs und iMac Retinas gesendet. Das gegen diesen Proof-Konzept schützt. Aber es gibt immer noch ein großes Loch bei den Option-Rom. Und andererseits hat das Tradition gleich das Angreifen. Und die zweite Frage war Proprietäre TPM-Modules würden die proprietary TPM-Chips früher kritisiert dafür? Glauben Sie, dass die helfen würden oder ist da eine Nachzahl dabei oder glauben Sie, es ist besser einen TPM-Chip zu haben oder nicht? TPM ist vielleicht nicht das beste Wort dafür. Manche Systeme haben so eine Art von Co-Prozessoren oder Hardware-Geräte die Main-CPU immer wieder zurücksetzen, bis sie eine ordentliche Verifikation von einem Bootraum durchgeführt haben. Das ist wirklich notwendig, um diese Angriffe zu entdecken. Es gibt eine große Anzahl von Papiere, die wie mein TPM oder sicheren Boot umgehen. Aber ich bin mir insofern nicht sicher, wie gut proprietary TPM während irgendwelche Open Source werden. Letzte Frage ist nicht, dass ich meine Computer oder meine Thunderbolt-Devices nicht verlassen darf, oder? Ja, das ist ein großer Punkt. Man sollte die Thunderbolt-Geräte immer auch mit dabei haben, genauso für den Computer. Und, dass Sie mir das jetzt wissen, wäre es theoretisch möglich, dass wenn ich Code ausführen kann von dem Thunderbolt-Devices, könnte ich darüber auch Tests ausführen. Könnte ich ein Thunderbolt-Devices herstellen, dass das dann rausfindet? Ja, das ist möglich. Außer du wolltest schon gehen und dann wird der Option-Rom einfach nicht geladen. Alle von meinen Maschinen wurden dagegen geschältzt. Sie buten keine Option-Roms. Das ist ein der Sachen, die es wäre toll, wenn es eine Konfiguration-Option wäre. Macht das ja nicht. Wenn es nicht ausführt, dann weiß es ja nicht. Okay, wenn die Option jetzt eine Möglichkeit hat, dass es nicht ausführt wird. Okay, so, bitte gibt es noch ein Runde Applaus für ...