 Also willkommen unser nächster Vortrag bei Frédéric Rochon und eine große Runde Applaus. Hallo. Willkommen alles zusammen. Schön, dass ihr hier seid und ich werde heute über meine Research oder meine Forschung reden, die wir zusammen früher in diesem Jahr veröffentlicht haben und hat dazu geführt, dass wir einen UEFI Angriff gefunden haben. Ich bin Frédéric Rochon und ich suche nach Viren und ich arbeite daran schon in den letzten drei Jahren und in den letzten drei Jahren habe ich mich hauptsächlich darauf fokussiert, Probleme im Bootlevel und im UEFI zu finden. Schauen wir mal, worüber es geht. Zuerst möchte ich darüber reden, was setnet ist. Dann werde ich über Lowjack und eine Software in vergangenen Forschungsergebnisse. Darüber werden wir reden, weil der UEFI Rout-Kit dem sehr ähnlich wisst. Dann werden wir weitergehen und ich werde ein bisschen darüber reden, wie man Lowjack-Agenten komprimieren kann und dann werden wir zu allerletzt das Rout-Kit uns anschauen, wie das aufgebaut ist. Znet ist eine Spionagegruppe des frühen 2000ern und ist sehr bekannt als SINSIB-ATPD-28 und noch ein paar andere Namen. Vielleicht kennt ihr es unter denen und Znet ist etwas, was wir für sie benutzen. Sie sind auch als Trontium bekannt und sie wurde in den letzten Jahren sehr bekannt, weil sie durch ein paar sehr bekannten Hecks gearbeitet haben. Z.B. die DnC, der amerikanische Parteitag der Hecks-Vorte, der Anriff gegen die Welt-Doping-Agentur und das Fernseh-5-Welt von Frankreich, die W5-Mond. Aber wir werden über die Werknutzzeuge reden und die ganzen Kampagnen mit diesen Werkzeugen. Wir werden nicht darüber reden und wir werden auch nicht über die Menschen reden, die daran arbeiten an den Viren, weil wir die ganze Information nicht haben, um darüber bekannte Nachrichten zu reden. Aber in 2018 hat das US-Rechtsystem bestoßen, dass sie für den DnC-Angriff verantwortlich sind und die Werkzeuge, die wir benutzt haben, die Angriff-Werkzeuge, sind da drin aufgeführt und sie werden auch lenden, auch wer die Autoren von diesen unterschiedlichen Viren und Schadsoftware ist. Außerdem, ein bisschen später, im Oktober 2018, hat das Justizministerium gegen dieselben Leute eine weitere Anzeige erstattet mit einem anderen Hack. Wie Znet normalerweise ihre Ziele angreift, ist, dass sie eine Fishing-Email-Sendung senden. Das ist eine E-Mail, die so aussieht, als sei es etwas Wichtiges und hat einfach Angriffs-Links da drin, wo dann der Virus darunter geworden wird. Dann gehen wir mal kurz über Lautec und Computex, das ist die alte Name dafür. Vielleicht kennt ihr es unter dem Namen und das ist eine Software von absoluten Software. Die Lösung ist in vielen Laptops eingebaut. Die Software muss so gering wie möglich sein und sie muss im Betriebssystem überleben oder einen neuen Installieren des Betriebssystems oder einen neuen Installieren einer neuen Festplatte. Was die Software macht, sie haben ein Modul in den UEFI-Bios eingebaut und diese Lösung muss im Bio-Setup deaktiviert werden. In der Vergangenheit haben Sicherheitsforscher sich so etwas genau angeschaut, um Sicherheitslücken zu finden. Im Black Hat 2009 war ein Vortrag, wo die Architektur von dieser Lösung gezeigt und erklärt wurde und verschiedene Implementierungsprobleme in dem Agenten wurden aufgedeckt. Schauen wir uns mal an, wie Bluejack damals aufgebaut war. Zuerst haben wir hier dieses UEFI oder BIOS-Modul. Dieses Modul wird eine Datei in eine Windows Partition schreiben, in diese Auto-Check-Exe und der Job von diesem Auto-Check ist es. Am Anfang des Windows baut sich quasi einen kleinen Agent zu ersetzen und von dort wird es dann RPC-Net-Piali ersetzen und sobald Windows startet, wird der RPC-Net-D-Service quasi das in das SVC-Haus integrieren und von dort weiter zum Beispiel in den Internet Explorer. Das ist etwas, was wir häufiger mal sehen, aber nicht unbedingt in legitimer Software. Dieser Teil wird dann mit dem Command- and Control-Server kommunizieren und kann von dort einen vollständigen Agent herunterladen. So was gibt es jetzt auch, was wir jetzt als Forscher da gesunden haben in dieser Lösung? Eine der Verunbarkeiten, die wir gefunden haben, ist, was eigentlich die Einzige, die für diesen Talk relevant ist, ist in einer Konfigurationsdatei diese Konfiguration in einem RPC-Net-D drin und wir können diese anpassen und sie wird nicht authentifiziert oder ähnliches, wird einfach geladen. Was da drinsteht, ja, da sieht man einen Server, und zwar ist das der Command- and Control-Server. Ein Angrafer kann jetzt also diese Konfiguration einfach anpassen für seinen eigenen Command- and Control-Server. So, jetzt wissen wir, dass diese Verwundbarkeit existiert. Im 2009, circa wussten wir das, aber wir hatten noch keinen Anzeichen, ob das in der weiten Welt verwendet wird. Und was wir dann haben gefunden haben, war ein Blog-Post, welcher so einen kleinen modifizierten Agent gefunden hat, der diese Konfigurationsfeile für alte Set-Nits-Domains modifiziert. So, auf diesem Level wurde diese Attacke platziert. Von dort haben wir etwas herausgefunden, wir haben diese Malware-Halt gefunden, also wir haben sie verschiedene Samples gesucht, und es war dann relativ einfach, weil es immer dieselbe Version von diesem Agent modifiziert wurde. Und wir sehen, was hier modifiziert wurde, auf der rechten Seite dieser Command- and Control-Server. Das ist jetzt eine verschlüsselte Version. Wenn wir das genau anschauen, dann sehen wir uns... Also es wurden nur wenige Organisationen davon betroffen, vor allem militärische Diplomatische Organisationen im Balkan, und wir haben aber auch andere Set-Nits-Tools bei diesen Organisationen gefunden. So, wie ist denn diese Malware überhaupt da angekommen? Und gibt es noch weitere Backdoors, die jetzt offen wären in diesen Organisationen? Und da haben wir das weiteres Interessantes gefunden. Ich gehe mal zurück zur Architektur. Die Komponente, die wir gefunden haben, ist in diesem Schritt, in der Lowjack-Architektur, da, was wir da gefunden haben, ist ein Auto... Also es heißt Auto-Cheap, anstatt Auto-Check.exe. Und was es macht, es installiert auch ein Service, ein Dienst im Windows, im Betriebssystem. Und dieser Dienst ist dann halt intern modifiziert worden mit anderen Domeinnahmen. Und wir haben dann weiter geschaut, was wir... wir haben ein weiteres Tool gefunden. Das heißt InfoEvi. Und damit kann man viele Low-Level-Informationen herunterladen von der... von PC. Dieses Tool kann überall Lesen schreiben und Read-Write-Everything-Driver. Und mit diesem Tool könnt ihr quasi... also die PCI-Konfiguration, Memory-Konfiguration und so weiter alles lesen schreiben und physikalischen Speicher lesen und so weiter. Das benutzt ein Kerneldriver. Und der Kerneldriver ist auch richtig signiert, sodass man ihn tatsächlich im Windows auch nutzen kann. Dies ist jetzt der Driver, welcher von InfoEvi benutzt wurde. Und wenn man da ein bisschen danach googelt oder sucht, dann findet man heraus, dass dieser Driver auch schon für andere... für andere Attacken benutzt wurde auf so einem Formel-Level. Und das letzte, was jetzt noch fehlte, ganz eine Low-Jagg-Lösung war, dass wir ein UEFI-Bios-Modul hinzufügen müssten. Und Sie fragten, wo kommt die her? Also das Werkzeug, die wir gefunden haben, war man ziemlich sicher, dass dann noch weiteres passieren muss. Und dann haben wir ein bisschen tiefer gegraben und haben andere Werkzeuge darin gefunden. Das erste Werkzeug ist ein Schreibfunktion, die wird benutzt, um den SPI-Flash-Speicher auszulesen, auf dem das BIOS liegt. Und das benutzt diese spezifischen IOControls. Und es kann direkt auf Memory-Map IO-Space zugreifen. Was für uns als Reverse-Engineer interessanter ist, ist, dass sie sehr viele Debugstrings beinhaltet und das macht unsere Aufgabe ein bisschen einfacher und macht folgende Operationen. Das erste, was das macht, ist, dass die BIOS-Control-Register lockt und wir werden über diesen Register später reden. Dann schaut es, wo diese BIOS-Region Grundadresse ist und dann liest es die UEFI-Firmware heraus und schreibt es sie in eine Datei. Den Angriff hat es sehr nett, weil er sehr viele Debugstrings hat. Aber es ist eine Binärdatei. Und jetzt, wo wir die UEFI-Firmware im Arbeitsspeicher haben, wird die modifiziert und wieder auf den SPI-Flash geschrieben, auf den BIOS-Speicherplatz geschrieben. Jetzt werden wir darüber reden, wie die UEFI-Firmware gepatched wird. Zuerst haben wir ein paar Punkte, die wir besprechen müssen, um sicherzustellen, dass wir alle auf derselben Seite sind, weil wir alle gleich wissen. UEFI ist eine standardisierte Spezifikation, die den alten BIOS ersetzen soll und eine Standard zwischen der Firmware und dem Betriebssystem herstellen soll. Eine UEFI Standard-Firmware hat ein paar Services, die es ans Betriebssystem weitergibt. Die ersten Services sind die sogenannten Boot Services oder Start Services. Die sind vorhanden, während die Firmware läuft, aber während das Betriebssystem läuft, sind sie nicht mehr verfügbar. Und es gibt außerdem Runtimeservices, die auch vorhanden sind, während die Firmware läuft, aber die sind immer noch vorhanden, wenn das Betriebssystem läuft. Dadurch kann ein Kerneltreiber z.B. auf diese zugreifen. Und die ermöglichen das mit dem Betriebssystem UEFI Variablen zu lesen und zu schreiben. Und was wichtig ist bei UEFI, ist, dass es kein Master Boot, Record und Volume Boot, Record auf den Festplatten gibt und die benutzt werden. Darum gibt es keine einfache Methode, den frühen Bootprozess zu einzuspringen und zu interraten. Zuerst die in Pixie-Tever. Das heißt, sie sind Windows, im Endeffekt Windows binär Dateien oder ausführbare Dateien und sie sind tiefer im Inhalt von den UEFI-Systemen, die abstrahieren die Hardware oder erstellen verschiedene Standard-Interfaces, UEFI Standard-Interfaces. Und sie können auch von Firmware-Herstellern unterschiedliche Protokolle einschalten oder zur Verfügung stellen. Und diese Nächsten werden in der DXE-Schicht hinzugezogen und das wird durch den DXE-Core geladen. Und das Letzte ist der UEFI-Firmware-Layout. Der ist im BIOS-Region, im SPI Flash-Speicher auf dem Mainboard und das beinhaltet verschiedene Partitionen. Zuerst schauen wir uns hier auf dieses UEFI-Tool. Das ist ein freies Software, die uns ermöglicht UEFI-Firmware-Images zu verändern. Hier lade ich diesen Flash-Speicher und wenn wir uns anschauen, dass wir zuerst eine Diskentur haben, die erklärt, wie die ganze restliche Information aufgebaut ist, dann finden wir die ME-Region, die dem Intel Management Engine beinhaltet und dann haben wir die BIOS-Region. Das ist, was wir uns genauer anschauen wollen. Die BIOS-Bereich hat auch verschiedene Ordner und hier schauen wir mal einen Ordner oder eine Partition genauer an und da ist ein Filesystem 2 und da sind verschiedene Dateien drin und die sind bei UUIDs definiert. Und eine Datei beinhaltet nicht direkt die ausführbare Datei, sondern mehrere Sektionen und eine der Sektionen ist die ausführbare Datei. Aber es gibt auch noch andere Bestandteile zum Beispiel, was benötigt wird, um diese Software auszuführen oder auch eine Version und eine Benutzer-Interface-Bereich, die ein menschenlesbarer Dateiname anbietet, weil der UEFI die eindeutige Identifikator nicht menschenlesbar ist oder nicht so einfach menschenlesbar ist. Lass uns nochmal auf die Patch-Software schauen. Es versucht alles zu patchen und es schaut sich genau vier unterschiedliche Dateien an. IPv4, DEXY und NTFS-DXE. Warum tut es das? Diese Dateien, die sie anschaut, definieren, wo die UEFI-Firmware installiert ist. Normalerweise sind die alle in derselben Partition. Und wenn man eine Standard-Dexy hat, weiß man, wo die ganzen Treiber sind und wo die Partition ist und wird das verwenden um ihre eigenen Sachen. Die DXE-Kur wird auch gesucht, um das zu finden, aber manchmal ist es in einer anderen Partition. Und dann wird es das als eine andere mögliche Option für das UEFI-Rootkit benutzen, wenn es in einer anderen Partition ist als die Standard-Software. NTFS-Dexy ist ein Standard-NTFS-Treiber und wenn das Werkzeug diesen findet, wird es ihn entfernen. Und das ist, weil das UEFI-Rootkit ihren eigenen NTFS-Treiber installiert und mit keinem Konflikt existiert, wird es einfach entfernt. SMI-Flash wird gesucht und werden ein paar Metadaten daraus speichert, aber es wird sonst nicht weiter benutzt. Aber SMI-Flash ist ein bekannter Dexy-Treiber, der mit Unsicherheiten drin. Und vielleicht arbeiten Sie daran, einen Exploit dafür zu schreiben, um später einen anderen Angriff fahren zu können. Jetzt, wo wir die Partitionen gefunden haben, wird das Rootkit-Datei installiert. Zuerst wird eine Dateisystem-Header installiert, dann wird das Rootkit-File dort installiert. Das sind zwei andere Sektionen. Das eine dieser Sektionen ist das Programm und das andere ist ein Benutzer-Interface-Section, wo der Name definiert wird. Es wird als Sekt-Dexy definiert. Wir nehmen jetzt den Datei, also den Datenblopp und schreiben den an Ende der Firmware dran. Jetzt, wo das EV Rootkit in der Firmware ist, also im Speicher, müssen wir das zurück auf den SPI-Flash speichern. Wieder zwei, drei Dinge, die ich vorstellen möchte zuerst. Der Chipset hat verschiedene Mechanismen, damit man nicht einfach darauf so Dinge schreiben kann. Also z.B. der BIOS-Schutz ist z.B. immer aktiviert und nur die Firmware kann hineinschreiben. Und nur für unsere Binary, welche das jetzt ändern will, müssen wir das genauer anschauen. Wenn wir das einen Kerneldreiber haben und in die BIOS-Region schreiben möchten, dann müssen wir zuerst diesen BIOS-Right-Enable, also Schreibschutz, aufheben. Erst dann können wir den SPI-Flash schreiben. Eigentlich wollen wir nicht unbedingt, dass ein Kerneldreiber einfach so dahin hineinschreiben kann, weil das kann den ganzen Computer kaputtmachen. Darum gibt es ein zweites BIOS-Lock-Feld, welches man halt auch noch setzen muss. Und dieses Feld kann man lesen. Und WLO, also das heißt, wenn es die Firmware mal auf 0 geschrieben hat, kann man es nicht mehr wieder auf 1 setzen. Aber da gibt es ein Problem. Und das Problem, also da ist eine Verunbarkeit drin in dieser Implementation. Und also wenn das BIOS-Right-Enable auf 1 gesetzt wird, dann wird das nur für kurze Zeit geändert. Und dann wird ein Systemmanagement interabt und dieser wird das wieder auf 0 setzen. Das ist also ein Fehler in der Implementation. Also die Firmware muss quasi das unterstützen, sonst funktioniert der Mechanismus nicht. Und was passiert denn jetzt, wenn wir einfach vor diesem ASAMI-Handler auf den SPI-Flash schreiben, dann haben wir wahrscheinlich eine Race-Condition. Das gibt dann Paper darüber, welches Speed-Racer heißt. Und ein Thread versucht die ganze Zeit, das Ganze auf 1 zu setzen. Und der andere versucht dann halt, die effektiven Daten hineinzuschreiben. Und gemäß diesem Paper soll das auf verschiedenen Prozessoren gut funktionieren, vor allem Multi-Core. Intel hat im etwa 2008 die Plattform-Controller Hub-Family eingeführt. Und da gibt es ein neues Feld, Bios-Ride-Protect Disable. Der Name ist ein bisschen irreführend, aber wenn man die, ja, es nimmt halt den Schutz weg. Wenn das auf 1 ist, dann gibt es keinen anderen Weg mehr auf das Bios-Flash, wenn wir jetzt das schreiben. Also nur noch im Systemmanagement Mode kann man schreiben. Und auch die Firma muss dieses Bit schreiben, unterstützen quasi und sonst wird der Mechanismus nicht aktiviert. Ist ja nutzlos. Gehen wir zurück zu unserem Rewriter-Datei. Diese macht diverse Checks. Sucht, ob die Plattform richtig konfiguriert ist, ob der Exploit unterstützt wird. Und der Schreibprozess sieht dann voll der Maßen aus. Zuerst schaut es, ob das Bios-Ride-Datei gesetzt ist. Und wenn es gesetzt ist, dann wird niemand es stoppen, um das UEFI zu setzen. Wenn es aber nicht gesetzt ist, dann sucht es, ob der Bios-Locken-Datei gesetzt ist. Falls nicht, dann versucht es einfach auf 1 zu setzen und dann kann es das Image schreiben. Aber wenn es aktiviert ist, muss er als Letztes noch schauen, ist es erst einmal Schreibschutz gesetzt. Und falls nicht, dann versucht es mit der zuletzt beschriebenen Race-Condition das Ganze zu implementieren. Und falls das auch nicht geht, dann geht es halt nicht. Der Exploit nicht. Und der DxC-Triber, der verwundbare DxC-Triber, konnte nun ausgenutzt werden mit einem Tool. Und auch wenn die Plattform richtig konfiguriert war, da hat es eine Verwundbarkeit drin in diesem DxC. Wenn der Firmware-Hersteller, der seinen Job richtig gemacht hatte, dann hätte die Attacke nicht funktioniert. Das zeigt mir wieder, wie wichtig das Firmware Security ist. Jetzt gehen wir einen Schritt zurück, schauen, was wir haben. Wir haben eine Softwareimplementation, welche das Flash Remote schreiben kann. Also als Angreifer kann ich jetzt, dass mein Ziel quasi, zum Beispiel mein Fishing-Email senden und sobald ich da irgendwie so ein bisschen in der Maschine drin bin, kann ich das UEFA Root Kit implementieren. Und das ist halt ein großer Unterschied zu anderen UEFA Root Kits, wo man einen physikalischen Zugriff auf die Maschine brauchen. Es ist halt viel einfacher. Also es gibt keinen Beweis, dass das mal benutzt wurde, oder das Begriff, es wurde noch nie öffentlich ausgenutzt. Wir haben das... Wir haben jetzt diese Tool gefunden und wir haben geschaut, ob wir das irgendwo finden. Und wir haben das UEFA Root Kit im SPI Flash, einer angreifenden Maschine gefunden. Und das ist der erste öffentlich bekannte Angriff mit einem UEFA Root Kit in der wirklichen Welt. So, jetzt müssen wir uns das UEFA Root Kit selber genauer anschauen. Das ist ein DXE Treiber, der vom DXE Dispatcher jedes Mal geladen wird, wenn er ausgeführt wird. Der Name ist Zack Dexter. Und hier haben wir die GUID, wenn ihr es auch mal seht. Lassen wir uns das mal genauer anschauen, wie das funktioniert. Es wird durch unterschiedliche Phasen durchlaufen. Das erste ist die Sicherheitsphase, dann die Vor-Initialisierung und dann den Treiber-Installationen. Das ist, wo es interessant wird. Das ist, wo der DXE Dispatcher lebt und das ist, wo die ganzen DXE Treiber geladen werden. Wird das UEFA Root Kit auch geladen und was passieren wird, ist, dass wir ein Event hinzufügen können, dass wenn es so weit ist, dass es gebotet werden kann, dann werden wir darüber informiert. Irgendwann wird der Boot Manager starten, dann wird er dieses Event aufrufen und dann kriegen wir das mit. Diese Notifizierungsfunktion macht drei Sachen. Zuerst wird der NTFS Treiber installiert, dann wird es die AutoCHE-Exe und die ACIP-Net-Exe installieren und dann wird es einen Wert in der Windows-Registrie überschreiben. Der NTFS Treiber wird benutzt, um Datalsystemzugriff auf die Windows Partition zu bekommen und sie haben keinen eigenen NTFS Treiber geschrieben, sondern sie haben Hacking-Teams veröffentlichten, geliebten Treiber benutzt. Hier ist der Code, der die Dateien in das Dateisystem schreibt und hier schreibt das AutoCHE-Exe. Der letzte Schritt ist die Windows-Registrie zu modifizieren. Wie macht er das? Eröffnet die Datei. Es wird das nicht ganz geparst und so, aber es wird einfach nur einen String suchen und der String ist AutoCHEC, AutoCHE Stern und es wird ersetzt durch das andere, es wird einem eh hinten drin und dann wird der Boot-Execute-Key verändert, dafür zuständig ist, dass es überhaupt gestartet wird und dadurch, dass wir AutoCHE, schreiben wird, AutoCHE ausgeführt anstelle von AutoCHEC und dann wird es, wenn wir wieder beim UIFI Boot-Gate Arbeitsflow sind, dann wird die eigene Software ausgeführt anstelle der Betriebssystem-Software und es wird die Windows-Registrie-Eintrag wieder zurückbauen, sodass als Windows-Benutzer, der sich die Registrie anschaut, wird er die Modifikation überhaupt nicht finden, weil sie zurückgebaut wurde. Das ist eine sehr interessante Versteckoption, die die Software aus der Firma heraus ausführt und der letzte Schritt, den wir uns anschauen wollen, ist Schutz und Gegenangriffe. Was können wir machen, um uns gegen solche Angriffe zu schützen und wenn ihr jemals feststellt, dass ihr ein UIFI Boot-Gate auf eurer Maschine habt, was könnt ihr dagegen überhaupt machen? Das allererste, um es ganz so weit kommt und das Wichtigste ist, dass der Einfachste ist, dass ihr euer UIFI-Firmware auf dem aktuellen Stand halten solltet. Wenn ihr irgendwelche Sicherheitslücken gefunden werden mit eurer Firmware und die veröffentlicht werden und der Firmwarehersteller eine Reparatur einspielt, dann wollt ihr die aktuellste Version haben, die für euer Gerät verfügbar ist. Und dann der zweite Schritt ist, dass ihr wirklich sich Secure Boot verwenden sollt. Secure Boot würde nicht gegen diesen spezifischen Angriff schützen, weil Secure Boot den Inhalt vom SPI-Flash als Vertrauensquelle benutzt und das heißt, der Inhalt von diesem Flash-Speicher wird überhaupt nicht verifiziert. Aber was verifiziert es dann? Secure Boot wird alles außerhalb des UIFI-Flash-Memories verifizieren, zum Beispiel den Roms von Grafikkarten, zum Beispiel. Was wir brauchen ist ein Hardware-Root of Trust. Das heißt, wir müssen den Vertrauensknoten der UIFI-Flash-Speicher in ein Hardware-Modul überprüfen. Es muss in einem einmal programmierbaren Chip sind, der während der Herstellung programmiert wird und niemals nachher beschrieben werden können. Ein Beispiel dafür existiert, zum Beispiel Intel Boot benutzt und Apple Titus hat auch ein Hardware-Sicherheitsknoten. Dann müsst ihr auch sicherstellen, dass die Hardware-Sicherheitsfreundlich funktioniert. Da könnt ihr nicht viel machen, wenn die Firma up-to-date ist, aber es gibt auch Software wie Intel Chipset-Zack, dass ein Open-Source-Software ist. Die könnt ihr herunterladen, von einem USB-Sdo-Stick booten und sie wird die ganzen Sicherheitsmethodiken überprüfen, über die wir heute geredet haben und schaut, ob die ordentlich konfiguriert sind und dann noch eine Reihe von anderen Sachen. Chip-Sack überprüft jetzt auch, ob dieses Root-Kit dort installiert ist. Das heißt, wenn ihr schauen wollt, ob eure Firma ordentlich konfiguriert ist, dann ist das der Weg, wie ihr das machen könnt. Nun, wie könnt ihr dagegen vorgehen, wenn das erst mal installiert ist? Dieser Foldier ist ein bisschen kurz. Wenn ihr feststellt, dass ihr ein UEFI-Root-Kit auf eurem Gerät, auf eurem SPI-Flash habt, dann könnt ihr nicht viel dagegen machen. Ihr müsst ein neues UEFI-Formbär auf eurem Gerät flaschen. Das ist etwas, was für die meisten Menschen nicht einfach zu tun ist, dabei fast alle nicht einfach zu machen. Wenn es nicht für euch ist, dann müsst ihr eure Hardware, oder vielleicht euren ganzen Laptop wegschmeißen und einen neuen bekommen. Das ist wie gefährlich dieser Angriff ist. Und so zum Zusammenkommen. Unsere Forschung zeigt, dass UEFI-Root-Kits nicht nur eine kleine Spielzeuge für Forscher sind, sondern ein Angriff in der echten Welt sein kann. Das heißt, vielleicht wollt ihr darüber nachdenken, wenn ihr eure Gefährdungsmodelle schreibt. Außerdem, und da können wir nicht genug darüber reden, die Firma muss mit Sicherheitsmodulen eingedacht werden von den grundlegenden Stritten heraus. Mehr und mehr Leute reden darüber und denken darüber nach, aber es gibt immer noch mehr, was getan werden muss. Und wir hoffen, dass unsere Forschung ein bisschen Informationen darüber gegeben kann, wie man sich gegen UEFI-basierte Gefahren schützen kann. Also vielen Dank dafür, dass ich hier reden konnte. Und wenn ihr mehr darüber informieren wollt, da die Informationen sind auf unserer Webseite vorhanden und ihr könnt ihr da von dort holen. Das ist www.we-live-security.com, die Webseite von der die Informationen zu holen sind. Okay, ihr kennt die Situation. Wir haben fünf Minuten für Fragen und Antworten, also bitte kurze und präzise Fragen. Ist Ihnen bekannt, dass solche Rootkits auch andere Betriebssysteme wie Marco aus der Linux angreifen? In dieser Situation. Und das ist der einzige UEFI-Rootkit, das wir kennen, außer dem von Hacking Teams. Und dieser funktioniert ausschließlich bei Windows. Wir kennen keine anderen Angriffsziele wie Linux oder MacOS. Bitte nicht von den Kameras durchlaufen, wenn ihr den Saal verlässt. Mikrofon Nummer zwei. Hallo, danke für den Vortrag. Auf den Folien haben Sie ein Tool erwähnt, mit dem man das Layout anschauen kann. Das nennt sich UEFI Tool. Ich könnte es auf GitHub finden. Eine Frage aus dem Internet. Funktioniert das Rootkit auch, wenn das UEFI auf BIOS Legacy Mode gestellt wurde? Das ist eine sehr interessante Frage. Es sollte, aber ich bin mir dann nicht sicher. Das ist eine gute Frage, aber ich bin mir dann jetzt nicht 100% sicher. Mikrofon Nummer drei, bitte. Das war Nummer vier, Entschuldigung. Funktioniert der UEFI-Dropper auch, wenn BitLocker aktiviert ist? Ja, haben wir getestet? Nein, funktioniert nicht, wenn BitLocker aktiviert ist. Es wartet nicht darauf, dass BitLocker, alle Daten, die Entschlüssel haben. Also, es funktioniert nicht, wenn ihr BitLocker aktiviert habt. Mikrofon Nummer eins. War es möglich, dass man mit... Also, war es möglich, auch mit kompletter Diskverschlüsselung? Also, ich habe die Frage nicht ganz verstanden. War es grundsätzlich möglich, dass das Ruch hier auch mit vollverschlüsselter Disk funktionieren würde? Es sollte, die Software, können wir es dazu bringen, dass es funktioniert, wenn kompletter Verschlüsselung aktiviert ist, oder BitLocker. Was ist denn, wenn das Ruch hier zu groß ist für das SPI-Flash? Könnte man das SPI-Flash einfach geformstaltig füllen, um es, um den Angriff zu unterbinden? Nee, das ist kein wirklicher Verteidigerungsmethodik. Aber wenn kein Platz mehr drauf ist und alles mit Treibern voll ist, dann wird das einfach nicht funktionieren. Du hast gesagt, dass es nicht wirklich möglich ist, alles abzusichern. Was würdest du persönlich jetzt auf deinem Computer machen, damit du gut gesichert bist? Ja, wenn ihr ein modernes Intel-CPU habt und alle aktuellen Wifi-Patches und Firmware-Updates installiert habt, dann macht ihr das Beste, was ihr machen könnt, um euch sicher zu halten. Um sicher zu sein. Mikrofon Nummer 1. Zurück zum Lautsack zu dem Konfigurationsfile von Umparkite. Ist das diese Konfigurationsdatei auf dem Betriebssystem? Nein, es ist nicht wirklich eine eigene Konfigurationsdatei. Das ist ein Teil von der Ausführdatei, die in der Firma ist. Leider haben wir bereits keine Zeit mehr. Auf Ihrem Applaus für unseren Vortragenden. Copyright WDR 2021