LoJax: Das erste bekannte UEFI-Rootkit, das in einer böswilligen Kampagne verwendet wird

Sednit Cybergroup, auch bekannt als ART28, Strontium und Fancy Bear, ist seit mindestens 2004 in Betrieb. Es wird angenommen, dass die Gruppe hinter einer Reihe von resonanten Cyberangriffen steckt. Einige IB-Unternehmen und das US-Justizministerium haben Sednit für den Hacking des Democratic National Committee vor den US-Wahlen 2016 verantwortlich gemacht. Der Gruppe wird das Hacken des globalen Fernsehsenders TV5Monde, das Durchsickern von E-Mails der Welt-Anti-Doping-Agentur (WADA) und andere Vorfälle zugeschrieben. Sednit hat viele Ziele und eine breite Palette von Tools, von denen einige bereits zuvor dokumentiert wurden. Zum ersten Mal in dieser Arbeit werden wir jedoch die Verwendung des UEFI-Rootkits ausführlich beschreiben.

Kurzer Rückblick

Wir haben festgestellt, dass Sednit mindestens seit Anfang 2017 eine trojanisierte Version des alten Benutzeragenten des Programms verwendet, um Geräte vor Diebstahl durch den Entwickler von Absolute Software - LoJack zu schützen. Das Tool erregte die Aufmerksamkeit von Fachleuten für Informationssicherheit aufgrund der Verwendung des UEFI / BIOS-Moduls als Mechanismus zur Sicherstellung der Persistenz. Wir haben die trojanisierte Version dieses Programms LoJax genannt .

Das Vorhandensein bekannter Sednit-Tools in infizierten Systemen zusammen mit LoJax-Beispielen sowie die Tatsache, dass einige von trojanisierten Agenten verwendete Befehlsserver zuvor Teil der Sednit-Infrastruktur waren, ermöglichen es uns, ein UEFI-Rootkit zuverlässig dieser Gruppe zuzuordnen.

Zusammen mit LoJax-Agenten wurden Tools zum Lesen der UEFI-Systemfirmware entdeckt, und in einem der Fälle konnte dieses Tool einen Teil des System-SPI-Flash-Speichers sichern, patchen und neu schreiben. Das ultimative Ziel des Tools ist die Installation eines schädlichen UEFI-Moduls in einem System, dessen Flash-SPI-Schutz anfällig oder nicht ordnungsgemäß konfiguriert ist.

Das UEFI-Modul ist für die Implementierung des LoJax-Agenten im System verantwortlich. Dies ist das erste von UEFI identifizierte Rootkit der Sednit-Gruppe. Da es sich in der Systemfirmware befindet, kann es die Neuinstallation von Windows und den Austausch der Festplatte überleben.

Es gab mindestens einen Fall, in dem dieses Rootkit erfolgreich im System-SPI-Flash-Speicher installiert wurde. Nach unseren Informationen ist dies das erste UEFI-Rootkit, das in freier Wildbahn entdeckt wurde.

Einführung

Sednit verwendet eine Reihe von Malware-Familien. Eine detaillierte Beschreibung der häufig verwendeten Gruppenwerkzeuge, die wir im Bericht bereitgestellt haben.

Wir verfolgen die Aktivitäten von Sednit seit mehreren Jahren und haben zahlreiche Berichte über die Arbeit der Gruppe veröffentlicht, von Beschreibungen von Zero-Day-Schwachstellen bis hin zu benutzerdefinierten Programmen wie Zebrocy . Die in diesem Bericht beschriebenen Komponenten bilden eine separate Gruppe.

UEFI-Rootkits wurden bereits in Berichten von Informationssicherheitsunternehmen beschrieben. Beispielsweise sind rkloader, der in einer Präsentation über Datenlecks im Hacking-Team vorgestellt wurde, und DerStarke, ein Implantat für den Download von macOS EFI / UEFI aus Vault7- Dokumenten, bekannt . Wir sind uns der Existenz dieser Tools bewusst, es wurden jedoch keine UEFI-Kompromissberichte von Rootkits veröffentlicht.

Jetzt haben wir nicht nur die Verwendung von In-the-Wild-Firmware mit dem böswilligen LoJax UEFI-Modul bewiesen, sondern auch die gesamte Palette von Tools gefunden, die höchstwahrscheinlich für die Installation verwendet wurden. Es ist interessant festzustellen, dass Sednit das DownDelph-Bootkit verwendet, das 2013 und 2014 verwendet wurde, um Downdelph, eine der ersten Hintertüren von Sednit, zu warten. Die Idee ist ähnlich, aber in der neuen Version von UEFI ist die Verwendung von Bootkits nicht mehr möglich. Somit unterscheiden sich diese beiden Komponenten erheblich im Verhalten.

Diese Arbeit ist in drei Abschnitte unterteilt. Im ersten Teil werden wir die frühen Studien zur Sicherheit von LoJack / Computrace und das Potenzial für eine böswillige Verwendung des Programms analysieren. Der zweite Abschnitt ist dem Forschungsprozess gewidmet, der uns schließlich zum UEFI-Rootkit führte. Schließlich beschreiben wir im dritten Abschnitt ausführlich die verschiedenen LoJax-Komponenten und wie sie auch nach der Neuinstallation von Windows und dem Austausch der Festplatte für Persistenz im System sorgen.

Namensnennung

Während viele Anbieter bereits in der Vergangenheit Aussagen zur Sednit-Gruppe gemacht haben, bestimmt ESET in keiner Weise ihre geopolitische Zugehörigkeit. Seit der Veröffentlichung der Studie 2016 hat sich unsere Position nicht geändert. Die Ermittlung der Quelle eines Cyberangriffs anhand eines wissenschaftlichen Ansatzes ist eine komplexe Aufgabe, die außerhalb des Kompetenzbereichs von ESET-Spezialisten liegt. Was wir als "Sednit-Gruppe" bezeichnen, ist nur eine Reihe von Software und eine zugehörige Netzwerkinfrastruktur, die wir keiner bestimmten Organisation autorisierend zuordnen können.

Ziele

Während der Studie fanden wir eine kleine Anzahl verschiedener LoJax-Bilder. Basierend auf unseren Telemetriedaten und einer Studie anderer in freier Wildbahn entdeckter Sednit-Programme sind wir zuversichtlich, dass dieses spezielle Modul im Vergleich zu anderen Tools selten verwendet wurde. Die Ziele waren hauptsächlich staatliche Organisationen auf dem Balkan in Mittel- und Osteuropa.

Frühe Computertrace / LoJack-Forschung

LoJack - Software zum Schutz von Computern vor Diebstahl und Verlust, entwickelt von Absolute Software Corporation. Frühere Versionen des Agenten sind als Computrace bekannt. Wie der vorherige Name schon sagt, kann der Computer nach Aktivierung des Dienstes auf seinen Befehlsserver zugreifen. Der Besitzer wird im Falle eines Verlusts oder Diebstahls über den Standort des Geräts informiert.

Der folgende Abschnitt beschreibt die vorherige LoJack-Architektur. Nur die alte Version der Software wurde von Cyberkriminellen trojanisiert, daher werden wir uns darauf konzentrieren. Darüber hinaus veröffentlichte Absolute Software im Mai 2018 eine Erklärung , dass die unten beschriebenen Sicherheitslücken den Betrieb der neuesten Versionen ihrer Agenten nicht beeinträchtigen.

Das Computrace-Programm zog die Aufmerksamkeit von Fachleuten für Informationssicherheit auf sich, da es eine ungewöhnliche Methode zur Sicherstellung der Persistenz verwendete. Der Zweck ist der Schutz vor Diebstahl. Daher ist es wichtig, dass das Betriebssystem nicht neu installiert und die Festplatte ausgetauscht werden kann. All dies ist im UEFI / BIOS-Modul implementiert, das nach diesen Aktionen überleben kann. Die Lösung ist in der Firmware eines wesentlichen Teils der Laptops verschiedener Hersteller vorinstalliert. Der Benutzer muss diese Funktion nur aktivieren. Die Aktivierung kann im BIOS erfolgen, wie in der folgenden Abbildung dargestellt.


Abbildung 1. Computrace im BIOS aktivieren

Einer der ersten LoJack / Computrace-Implementierungsberichte wurde 2009 veröffentlicht. Die globale Architektur des Produkts, das Leeren des UEFI / BIOS-Moduls des Benutzeragenten auf die Festplatte und die Art und Weise, wie der Agent mit einem von Absolute Software gesteuerten Webserver kommuniziert, wurden offengelegt. Das Diagramm ist aus der folgenden Abbildung ersichtlich.


Abbildung 2. LoJack-Persistenzmechanismus (ungefähr 2008)

Das Folgende ist eine Beschreibung der oben aufgeführten Schritte:

1. Wenn aktiviert, wird das UEFI / BIOS-Modul beim Booten ausgeführt. Er versucht, die FAT / FAT32 / NTFS-Partition zu finden. Anschließend erstellt er mithilfe des NTFS-Treibers eine Sicherungskopie der Datei autochk.exe und überschreibt deren Inhalt mit dem Dropper, der für die Installation der Benutzeragentenkomponente verantwortlich ist. Die Datei autochk.exe ist eine ausführbare Windows-Datei, die zu einem frühen Zeitpunkt des Systemstarts gestartet wird, um mögliche Schäden an der Festplatte festzustellen.

2. Wenn die geänderte autochk.exe , besteht ihr Hauptziel darin, den Mini-Agenten rpcnetp.exe zu implementieren und als Dienst hinzuzufügen, damit er bei jedem Neustart gestartet wird. Der letzte Schritt in dieser Komponente besteht darin, die ursprüngliche Version von autochk.exe .

3. Mini-Agent rpcnetp.exe - eine kleine ausführbare Datei, deren Zweck darin besteht, den Betrieb des Hauptagenten sicherzustellen. Wenn der primäre Agent nicht funktioniert, versucht rpcnetp.exe , eine Verbindung zum Absolute Software C & C-Befehlsserver rpcnetp.exe , um ihn herunterzuladen und auszuführen. Zuerst erstellt der Mini-Agent eine Kopie von sich selbst und nimmt dann Änderungen am PE-Header vor, um sie in eine DLL zu konvertieren. Diese Bibliothek wird dann in den Speicher geladen, ruft den Prozess svchost.exe auf und svchost.exe dort die DLL ein. Als nächstes wird der Internet Explorer-Prozess iexplore.exe und die DLL wird in ihn iexplore.exe . Der letztere Prozess wird dann für die Kommunikation über das Internet verwendet. Die Injektion von Computrace-Mini-Agenten in Prozesse von Drittanbietern ist häufig in Malware enthalten und wird selten mit legitimer Software in Verbindung gebracht.

4. Jetzt läuft ein voll funktionsfähiger Agent auf dem System und kann die Computrace-Funktionen zum Verfolgen und Wiederherstellen verwenden.

Eine Beschreibung dieses Prozesses und des Netzwerkprotokolls zwischen dem Mini-Agenten und dem C & C-Server wurde 2014 veröffentlicht. Aufgrund des Fehlens eines Authentifizierungsmechanismus können Angreifer, wenn sie den Server steuern, mit dem der Mini-Agent kommuniziert, ihn zwingen, beliebigen Code herunterzuladen. Es gibt verschiedene Mechanismen, mit denen Angreifer den Mini-Agenten direkt kontaktieren können. Das für uns wichtigste ist die Methode, mit der die Adresse des C & C-Servers vom Mini-Agenten abgerufen wird. Tatsächlich werden diese Informationen in der Konfigurationsdatei in der ausführbaren Datei selbst gespeichert.


Abbildung 3. Konfigurationsdatei für die verschlüsselte LoJack-Teilentschlüsselung auf der rechten Seite

Die Abbildung zeigt die LoJack Mini-Agent-Konfigurationsdatei. Die verwendete Verschlüsselungsmethode ist ein einfaches XOR mit einem Einzelbyte-Schlüssel. Der 0xB5-Schlüssel ist für alle untersuchten Mini-Agenten gleich. Wie aus der Abbildung ersichtlich, ist die C & C-Domäne in der Datei angegeben. Die vier vorhergehenden Bytes enthalten die IP-Adresse des C & C-Servers. %WINDIR% der Inhalt der Konfigurationsdatei nicht %WINDIR% können Angreifer mit Schreibberechtigungen in %WINDIR% den Inhalt so ändern, dass der Mini-Agent nicht legitim, sondern mit seinem Befehlsserver kommuniziert. Wenn Sie das Netzwerkprotokoll kennen, können Sie den Mini-Agenten dazu bringen, beliebigen Code herunterzuladen und auszuführen. Diese Risiken sind seit langem bekannt, aber bis vor kurzem wurde der Mechanismus in der Praxis nicht angewendet.

LoJack wird zu LoJax

Im Mai 2018 wurden die Trobor-Beispiele des LoJack-Mini-Agenten rpcnetp.exe im Arbor Network- Blog beschrieben . Ihre fest codierten Netzwerkeinstellungen wurden geändert, sodass böswillige Beispiele eine Verbindung zum C & C-Server des Angreifers anstelle des legitimen Absolute Software-Servers herstellten. Einige der in den Trojaner-Beispielen gefundenen Domänen wurden früher erfüllt - sie wurden Ende 2017 als C & C-Serverdomänen für SedUploader, die Hintertür der ersten Stufe der Sednit-Cybergruppe, verwendet. Die folgende Abbildung zeigt ein Beispiel für eine geänderte Konfiguration in einem der LoJax-Miniagenten.


Abbildung 4. Links befindet sich eine legitime Konfigurationsdatei, rechts eine geänderte

Die Unterschiede zwischen legitimen und trojanisierten Agenten sind äußerst gering, fast alle sind oben angegeben. Die LoJax-Mini-Agent-Beispiele, die wir finden konnten, sind trojanisierte Versionen desselben Computrace-Mini-Agent-Beispiels, rpcnetp.exe . Sie haben alle identische Kompilierungszeitstempel und nur wenige Dutzend Bytes unterscheiden sich vom Original. Zusätzlich zu den Änderungen an der Konfigurationsdatei gibt es Unterschiede bei den Timer-Variablen, die die Intervalle zwischen den Verbindungen zum C & C-Server bestimmen.

Zum Zeitpunkt der Veröffentlichung entdeckten wir verschiedene LoJax-Mini-Agenten, die bei Angriffen auf verschiedene Organisationen auf dem Balkan in Mittel- und Osteuropa eingesetzt wurden, hatten jedoch keine Ahnung, wie sie installiert werden sollten. Eine naheliegende Erklärung wäre die Installation mit einer der berühmten Sednit-Hintertüren. Vergessen Sie nicht, dass LoJack als etabliertes Tool von vielen Antiviren-Anbietern auf die Whitelist gesetzt wurde. Selbst wenn in dieser Kampagne nur ein Mini-Agent verwendet wurde, der nach der Neuinstallation von Windows nicht überlebte, hatte er dennoch einen Vorteil: Es war weniger wahrscheinlich, dass er als Malware erkannt wurde. Was aber, wenn der Kompromiss noch tiefer ging und die Angreifer versuchten, LoJack zu kopieren, um zur Systemfirmware zu gelangen?

Suchen Sie nach der Komponente der unteren Ebene

Wir haben LoJax-Angriffe gegen mehrere Organisationen auf dem Balkan in Mittel- und Osteuropa aufgezeichnet. In allen von ihnen konnten wir Spuren von Sednit-Malware finden, darunter:

• SedUploader, Hintertür der ersten Stufe
• XAgent, Sednits Flaggschiff-Hintertür
• Xtunnel, ein Netzwerk-Proxy-Tool, das jeglichen Netzwerkverkehr zwischen einem C & C-Server im Internet und einem Zielcomputer in einem lokalen Netzwerk übertragen kann

Wir fanden Spuren von Sednit-Werkzeugen in den meisten untersuchten Systemen, die zu LoJax-Zielen wurden, sowie in einigen Systemen, in denen nur LoJax vorhanden war. Es ist davon auszugehen, dass LoJax in einigen Fällen als separates Tool verwendet wurde, wahrscheinlich als zusätzliche Hintertür zur Wiederherstellung des Zugriffs von Sednit-Betreibern auf das Netzwerk.

Die XAgent-Hintertür fügt normalerweise zusätzliche Module in ein kompromittiertes System ein, sodass sofort in den Sinn kommt, dass LoJax-Muster auf die gleiche Weise ohne andere Mechanismen geliefert wurden. Es war davon auszugehen, dass Sednit nur einen Mini-Agenten aus der LoJack-Lösung ausgeliehen hatte. Kurz nach Beginn der Analyse fanden wir jedoch mehrere Hinweise darauf, dass die Inspirationsquelle etwas umfangreicher war.

RWEverything (RwDrv) Treiber und info_efi.exe

Der erste Beweis wurde dank eines benutzerdefinierten Tools von Cyberkriminellen gefunden, die bei der Ausführung Informationen über die Einstellungen des untergeordneten Systems in eine Textdatei entladen. Das Tool wurde zusammen mit einigen LoJax-Beispielen entdeckt. Die folgende Abbildung zeigt ein Fragment der info_efi.exe dieses Tools unter dem logischen Namen info_efi.exe .


Abbildung 5. Auszug aus den von info_efi .exe generierten Dateiprotokollen

Um diese Art von Informationen zu lesen, enthält das Tool einen Treiber namens RwDrv.sys . Der Kerneltreiber wird mit RWEverything geliefert , einem kostenlosen Dienstprogramm, das im Netzwerk verfügbar ist und zum Lesen von Informationen zu fast allen Einstellungen auf niedrigerer Ebene verwendet werden kann, einschließlich der PCI Express-Schnittstelle, des Speichers, der PCI Option-ROMs usw. Der Kerneltreiber ist eine legitime Software und mit einem gültigen Zertifikat signiert.


Abbildung 6. Codesignaturzertifikat für RwDrv.sys

RWEverything verfügt über eine grafische Benutzeroberfläche, über die Sie auf alle diese Informationen zugreifen können.


Abbildung 7. Screenshot der RWEverything-Benutzeroberfläche

Die Entdeckung des Tools info_efi war das erste Anzeichen dafür, dass ein UEFI LoJax-Modul existieren könnte. Wenn Sie versuchen, die Systemfirmware zu aktualisieren, ist es wichtig, Informationen über den Hersteller, die Version usw. zu haben. Angesichts der Sicherheitslücken, die es Benutzerprozessen ermöglichen, auf den Inhalt des SPI-Flash-Speichers zuzugreifen und diesen zu ändern, in dem UEFI-Module gespeichert sind, ist das Abrufen von Systemfirmware-Daten der erste Schritt zu einem erfolgreichen Angriff.

Der letzte Hinweis, der es uns ermöglichte, das erste UEFI-Rootkit der Sednit-Gruppe zu finden, waren zwei Tools - zum Speichern des SPI-Flash-Speichers und zum Schreiben darauf.

Dump SPI Flash

Das erste Puzzleteil war eine Datei namens ReWriter_read.exe . Es enthielt den gesamten Code, der zum Speichern des System-SPI-Flashs mithilfe des RWEverything-Treibers RwDrv.sys . Damit der Gerätetreiber die erforderlichen Vorgänge ausführen kann, muss das Dump-Tool die richtigen E / A-Steuercodes (IOCTL) senden. Während RwDrv.sys viele verschiedene IOCTL-Codes unterstützt, verwenden das in diesem und im nächsten Abschnitt beschriebene Dumper- und Writer-Tool nur vier davon.

RwDrv.sys: unterstützte IOCTL-Codes:

0x22280c - Schreibt in den für E / A zugewiesenen Speicherbereich
0x222808 - Liest den für die Eingabe / Ausgabe zugewiesenen Speicherbereich
0x222840 - Liest das Dword aus dem angegebenen PCI-Konfigurationsregister
0x222834 - schreibt ein Byte in das angegebene PCI-Konfigurationsregister

ReWriter_read erstellt zunächst einen Dienst mit dem integrierten RwDrv.sys und schreibt die UEFI / BIOS-Konfigurationsinformationen sowie die entsprechenden Werte der drei im BIOS-Verwaltungsregister (BIOS_CNTL) enthaltenen Felder: BIOS Lock Enable (BLE), BIOS Write Enable (BIOSWE) und SMM BIOS Schreibschutz deaktivieren (SMM_BWP). Obwohl ReWrite_read diese Werte nicht verwendet, werden wir in den folgenden Abschnitten erklären, warum diese Felder für dieses Tool von Interesse sind.

Die nächste Aufgabe des Tools besteht darin, die Basisadresse des BIOS-Speicherbereichs in SPI und seine Größe zu ermitteln. Diese Informationen sind im Register der SPI-Hauptschnittstelle als BIOS-Flash-Primärregion enthalten. Alle Register werden im Speicher im Root Complex Register Block (RCRB) angezeigt, dessen Basisadresse durch Lesen des gewünschten PCI-Konfigurationsregisters erhalten werden kann. ReWriter_read erhält diese Adresse, indem es RwDrv IOCTL 0x22840 verwendet und den richtigen Einzug liest (in unserem Fall 0xF0). Sobald die Basisadresse des BIOS-Bereichs und seine Größe bekannt sind, liest das Dump-Tool den entsprechenden Inhalt des SPI-Flash-Speichers und schreibt ihn in eine Datei auf der Festplatte. Der Vorgang des Lesens des SPI-Flash-Speichers ist in der folgenden Abbildung dargestellt. Definitionen der Abkürzungen finden Sie im folgenden Glossar.


Abbildung 8. Die Lesesequenz aus dem SPI-Flash-Speicher

Zusätzlich zu den ersten beiden Schritten, die nur einmal ausgeführt werden, werden die Vorgänge in einem Zyklus wiederholt, bis alle Daten aus dem SPI-Flash-Speicher gelesen wurden. Der Prozess ist auch hier gut beschrieben. Anschließend ReWriter_read die Größe des zusammengeführten Bildes. Es analysiert den Bildspeicher-Deskriptor, um eine Reihe von BIOS-, Gigabit-Ethernet- (GbE) und Management Engine- (ME) Bereichen zu erhalten. Durch Hinzufügen der Abmessungen dieser drei Bereiche kann das Dumper-Tool den gesamten Inhalt des Flash-SPI berechnen. Wenn die Größe mit der Größe übereinstimmt, die beim Lesen des Registrierungsbereichs des primären Flash-BIOS erhalten wurde, wird das Bild als korrekt angesehen.

UEFI-Firmware-Patch

Das zweite Puzzleteil war eine Datei namens ReWriter_binary.exe . Diese Datei enthält Hinweise darauf, dass Sednit zur Firmware gelangt ist. Die Datei enthält Code zum Anwenden des Patches des heruntergeladenen UEFI-Images und zum Zurückschreiben der trojanisierten Version in den SPI-Flash-Speicher. In diesem Abschnitt beschreiben wir, wie diese Binärdatei aufgebaut ist.

Nachdem der Inhalt des Flash-Speichers mit dem obigen Tool entladen und überprüft wurde, wird dem Image ein schädliches UEFI-Modul hinzugefügt. Dazu muss das UEFI-Bild analysiert werden, um die erforderlichen Informationen hervorzuheben.

Die im UEFI-Image gespeicherten Daten werden über das Dateisystem (FFS) in Volumes zerlegt. Wie der Name schon sagt, handelt es sich um ein spezielles Dateisystem zum Speichern von Firmware-Images. Volumes enthalten Dateien mit GUIDs. Jede Datei besteht normalerweise aus vielen Abschnitten, von denen einer die tatsächlich ausführbare Datei PE / COFF enthält, bei der es sich um ein UEFI-Image handelt. Unten finden Sie einen Screenshot von UEFITool , einem Open-Source-Projekt für die Arbeit mit UEFI-Firmware-Images, um das Verständnis der Schaltung zu vereinfachen.


Abbildung 9. Beispiel eines in UEFITool geladenen UEFI-Firmware-Images

ReWriter_binary analysiert alle Firmware-Volumes im BIOS SPI-Bereich des Flash-Speichers und sucht nach bestimmten Dateien:

• IP4Dxe (8f92960f-2880-4659-b857-915a8901bdc8)
• NtfsDxe (768bedfd-7b4b-4c9f-b2ff-6377e3387243)
• SmiFlash (bc327dbd-b982-4f55-9f79-056ad7e987c5)
• Dxe Kern

Abbildung 10. Das Ergebnis der Verwendung des Hex-Rays-Dekompilierers in den Firmware-Volumes

Ip4Dxe und NtfsDxe sind DXE-Treiber. In der UEFI-Firmware sind DXE-Treiber PE / COFF-Images, die entweder zur Hardware-Abstraktion oder zum Organisieren von Diensten zur Verwendung durch andere DXE-Treiber oder UEFI-Anwendungen erstellt wurden. Solche Treiber werden von der DXE Foundation zu einem frühen Zeitpunkt des Startvorgangs über den DXE Manager (DXE-Kernel) erkannt und heruntergeladen. Nach Abschluss dieser Phase stehen alle Dienste, z. B. OS Loader, für die Arbeit mit UEFI-Anwendungen zur Verfügung. In der Regel werden DXE-Treiber auf demselben Volume gespeichert. Der DXE-Dispatcher kann jedoch separat sein.

ReWriter_binary sucht nur nach Ip4Dxe, um herauszufinden, ob ein bestimmtes Volume DXE-Treiber enthält. Wie wir später beschreiben, wird dieses Volume zu einem Kandidaten für die Installation des schädlichen DXE-Treibers. Er sucht auch nach dem DXE-Kernel und fügt das Volume hinzu, in dem er sich als weiterer Kandidat für einen Ort zum Aufzeichnen eines Rootkits befindet. Der freie verfügbare Speicherplatz in jedem dieser Volumes wird gespeichert und später verwendet, um zu überprüfen, ob ein bösartiger Treiber hinzugefügt werden kann.

NtfsDxe - AMI NTFS DXE-Treiber. Wenn es auf dem Firmware-Volume vorhanden ist, wird sein Speicherort gespeichert und später zum Entfernen dieser Datei vom Volume verwendet. Im Abschnitt UEFI-Rootkit werden wir sehen, warum diese Datei gelöscht wird.

Was das SmiFlash-Bild betrifft, werden die damit verbundenen Informationen gespeichert, aber nirgendwo in Malvari verwendet. Interessanterweise ist das Bild anfällig . Wir glauben daher, dass Sednit-Betreiber daran arbeiten können, diese Sicherheitsanfälligkeiten auszunutzen. Dadurch können sie möglicherweise auch korrekt konfigurierte Systeme in den SPI-Flash-Speicher schreiben. Wie wir später erfahren werden, kann das Tool in seiner aktuellen Form nur in den BIOS-Bereich von falsch konfigurierten oder ziemlich alten Systemen schreiben (auf Motherboards mit Chipsätzen, die älter sind als der um 2008 eingeführte Platform Controller Hub).

Nachdem die erforderlichen Metadaten zugewiesen wurden, ReWriter_binary den ReWriter_binary des UEFI-Images und fügt den schädlichen DXE-Treiber hinzu. Zunächst wird der Dateikopf (EFI_FFS_FILE_HEADER) erstellt. Anschließend wählt er das Zieldatenträger basierend auf dem Speicherort von Ip4Dxe und dem DXE-Kernel sowie dem auf diesen Datenträgern verfügbaren freien Speicherplatz aus. ReWriter_binary bettet einen komprimierten Abschnitt ein, der ein PE-Image und einen Abschnitt der Benutzeroberfläche enthält, der einen für Menschen lesbaren Dateinamen definiert: SecDxe. Der komprimierte Abschnitt wird dem Dateikopf hinzugefügt und am Ende des Volumes in freien Speicherplatz geschrieben. Die folgende Abbildung zeigt die Struktur - ihre Anzeige in UEFITool.


Abbildung 11. Ansicht der SecDxe-Datei in UEFITool

Wenn der NtfsDxe-Treiber im Image vorhanden ist, wird er entfernt. Das Firmware-Dateisystem speichert Dateien und deren Inhalt nacheinander, sodass der Vorgang recht einfach ist:

• Einzug in einen freien Speicherplatz am Ende des Bandes
• 0xFF-Bytes, die über das NtfsDxe-Image geschrieben wurden
• Der nächste Teil des Firmware-Volumes wird kopiert, beginnend mit dem Einzug, in dem sich NtfsDxe befand
• Der Rest des Dateisystems ist mit 0xFF-Bytes gefüllt, d. h. freiem Speicherplatz

Gepatchte Firmware zurück in den SPI-Flash-Speicher schreiben

Nachdem Sie erfolgreich Änderungen am Firmware-Image vorgenommen haben, müssen Sie es im nächsten Schritt in den SPI-Flash-Speicher zurückschreiben. Bevor wir uns mit diesem Prozess befassen, müssen wir einige der in diesem Fall wichtigen BIOS-Schreibschutzfunktionen charakterisieren. Andere vorhandene Mechanismen, wie das Range Write Protection BIOS, bleiben fern, da ReWriter_binary sie nicht überprüft.

Die Plattform verwendet mehrere Sicherheitsmechanismen, um nicht autorisierte Schreibversuche in den BIOS-Bereich zu blockieren. Ich muss sagen, dass diese Mechanismen nicht standardmäßig aktiviert sind. Die Firmware ist für die korrekte Konfiguration verantwortlich. Diese Konfigurationen werden im BIOS-Steuerregister (BIOS_CNTL) dargestellt. Es enthält das BIOSWE-Bit (BIOS Write Enable), das auf „1“ geschaltet werden muss, um in den BIOS-Bereich des SPI-Flash-Speichers schreiben zu können. Da die Plattform keinen Versuch zulassen sollte, in den BIOS-Bereich zu schreiben, enthält BIOS_CNTL noch ein Bit zum Schutz von BIOSWE - dies ist BIOS Lock Enable (BLE). Wenn es gesetzt ist, sollte der Mechanismus das BIOSWE-Bit blockieren und den Wert gleich "0" lassen. Die Lösung weist jedoch eine Sicherheitsanfälligkeit auf. Wenn eine Anforderung zum Ändern des BIOSWE-Bits auf "1" und des BIOSWE-Bits auf "1" eingeht und die Plattform die Aufgabe erst dann mithilfe von System Management Interrupt (SMI) unterbricht, ändert der Code für dieses SMI das BIOSWE-Bit zurück auf "0".

In dieser Version der Lösung gibt es viele Probleme. -, SMI . , BLE , «0» BIOSWE . -, « », , SMI . , BIOSWE «1», SPI -. , Hyper-Threading.

, BIOS_CNTL. Intel Platform Controller Hub (PCH). , SMM BIOS Write Protect Disable (SMM_BWP) BIOS , System Management Mode (SMM) BIOSWE «1». « », . , BLE, SMM_BWP . , , BIOS.

ReWriter_binary BIOS, .

, BIOSWE. , . BIOSWE , BLE. , BIOSWE . BLE , SMM_BWP « », . SMM_BWP , . .


12.

, ReWriter_binary UEFI , , BIOS, , Platform Controller Hub.

ReWriter_binary UEFI . SmiFlash UEFI UEFI , BIOS .

SPI -:


13. SPI -

, , , SPI -.

, SPI - image.bin . , ReWriter_read , . , SPI -, .

- , . . , , .

:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute = “autocheck autochk *”

RwDrv . , Windows , UEFI Windows. , UEFI .

LoJax

, SPI - . UEFI . , – , , . UEFI, . , UEFI Sednit , , in-the-wild.

, . , – , XAgent. , – , . , , , . , , , .

UEFI . SecDxe DXE DXE. EFI_EVENT_GROUP_READY_TO_BOOT . , . :

• NTFS DXE NTFS
• NTFS Windows: rpcnetp.exe autoche.exe
• 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\BootExecute': : 'autocheck autochk *'; : 'autocheck autoche *' .

14. , UEFI

SecDxe: DXE

, . , , .

UEFI Sednit – DXE GUID 682894B5-6B70-4EBA-9E90-A607E5676297 .

, Secure Boot. DXE Foundation .

SecDxe – DXE, , , . , GUID 832d9b4d-d8d5-425f-bd52-5c5afb2c85dc , . . , EFI_EVENT_GROUP_READY_TO_BOOT . , .


15. Hex-Rays

UEFI Sednit. NTFS Windows. , UEFI EFI, NTFS . FAT . UEFI NTFS. SecDxe NTFS . . EFI_SIMPLE_FILE_SYSTEM_PROTOCOL NTFS , .

, Windows, SecDxe rpcnetp.exe autoche.exe . rpcnetp.exe %WINDIR%\SysWOW64 64- Windows %WINDIR%\System32 32- . autoche.exe %WINDIR%\SysWOW64 . , .


16. Hex-Rays

SecDxe %WINDIR%\System32\config\SYSTEM , HKLM\SYSTEM . , 'autocheck autochk *' 'k' 'autochk' 'e' . 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ BootExecute' 'autocheck autoche *' . Windows autoche.exe autochk.exe .

NTFS Hacking Team

, SecDxe NTFS. , Sednit , NTFS DXE Hacking Team.
NTFS ntfs-3g. , UEFI DXE. INF Hacking Team ntfs-3g. SecDxe NTFS :

- c:\edk2\NtfsPkg\NtfsDxe\ntfs\inode.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\volume.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\bootsect.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\unistr.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\attrib.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\mft.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\index.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\cache.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\misc.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\dir.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\runlist.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\logfile.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\uefi_io.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\ntfsinternal.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\mst.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\lcnalloc.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\compress.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\bitmap.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\collate.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\security.c

, , vector-edk, Hacking Team EFI. vector-edk NtfsPkg . ntfs-3g . , , .

, Hex-Rays, , . NtfsDriverBindingStart , vector-edk/NtfsPkg/NtfsDxe/Ntfs.c . HT . . (LockedByMe) .


17. Hex-Rays NTFS Sednit () NTFS HT ()

Hacking Team, ntfs-3g. ReWriter_binary , AMI NTFS. , , .

, . , . , Sednit , , NTFS, . , Hacking Team . , , - .

, UEFI. , , Sednit vector-edk Hacking Team NTFS NTFS Windows. , SecDxe.

autoche.exe vs. autochk.exe

autoche.exe - rpcnetp.exe . , Windows API .


18. autoche .exe rpcnetp.exe

, , Computrace. BootExecute .


19. autoche.exe BootExecute

Windows, BootExecute . , autoche .exe autochk.exe Computrace, , API , . Computrace , autochk.exe . - , LoJax UEFI .

rpcnetp.exe

- rpcnetp.exe UEFI , , , LoJack, - . , UEFI , , .

- LoJax. /IP-. , Computrace, 2008 .

, LoJax , , . LoJax – , .

, . , – Secure Boot. Secure Boot , , . Secure Boot, UEFI.

, UEFI . , , .

, Platform Controller Hub ( Intel Series 5 ). « », , , .

UEFI/BIOS. , , , . . , , . CHIPSEC , , , , .

UEFI . , , . SPI -. , . UEFI , SPI -. UEFI , – .

Schlussfolgerungen

UEFI – , . UEFI , UEFI . , UEFI , , . , , , UEFI .

threatintel@eset.com

, opensecuritytraining.info. Introduction to BIOS & SMM , - SPI.

Intel .
— BIOS_CNTL: BIOS Control Register
— BIOSWE: BIOS Write Enabled
— BLE: BIOS Lock Enabled
— FADDR: Flash Address
— FDATAX: Flash Data from FDATA0 to FDATAN
— FDBC: Flash Data Byte Count
— FGO: Flash Cycle Go
— HSFC: Hardware Sequencing Flash Control
— HSFS: Hardware Sequencing Flash Status
— IOCTL: Input/Output Control
— PCH: Platform Controller Hub
— RCBA: Root Complex Base Address Register
— RCRB: Root Complex Register Block
— SCIP: SPI Cycle in Progress
— SMI: System Management Interrupt
— SMM: System Management Mode
— SMM_BWP: SMM BIOS Write Protect Disable
— SPI: Serial Peripheral Interface

ReWriter_read.exe

ESET
Win32/SPIFlash.A
SHA-1
ea728abe26bac161e110970051e1561fd51db93b

ReWriter_binary.exe

ESET
Win32/SPIFlash.A
SHA-1
cc217342373967d1916cb20eca5ccb29caaf7c1b

SecDxe

ESET
EFI/LoJax.A
SHA-1
f2be778971ad9df2082a266bd04ab657bd287413

info_efi.exe

ESET
Win32/Agent.ZXZ
SHA-1
4b9e71615b37aea1eaeb5b1cfa0eee048118ff72

autoche.exe

ESET
Win32/LoJax.A
SHA-1
700d7e763f59e706b4f05c69911319690f85432e

- EXE

ESET
Win32/Agent.ZQE
Win32/Agent.ZTU
SHA-1
1771e435ba25f9cdfa77168899490d87681f2029
ddaa06a4021baf980a08caea899f2904609410b9
10d571d66d3ab7b9ddf6a850cb9b8e38b07623c0
2529f6eda28d54490119d2123d22da56783c704f
e923ac79046ffa06f67d3f4c567e84a82dd7ff1b
8e138eecea8e9937a83bffe100d842d6381b6bb1
ef860dca7d7c928b68c4218007fb9069c6e654e9
e8f07caafb23eff83020406c21645d8ed0005ca6
09d2e2c26247a4a908952fee36b56b360561984f
f90ccf57e75923812c2c1da9f56166b36d1482be

secao[.]org
ikmtrust[.]com
sysanalyticweb[.]com
lxwo[.]org
jflynci[.]com
remotepx[.]net
rdsnets[.]com
rpcnetconnect[.]com
webstp[.]com
elaxo[.]org

IP-

185.77.129[.]106
185.144.82[.]239
93.113.131[.]103
185.86.149[.]54
185.86.151[.]104
103.41.177[.]43
185.86.148[.]184
185.94.191[.]65
86.106.131[.]54

- DLL

ESET
Win32/Agent.ZQE
SHA-1
397d97e278110a48bd2cb11bb5632b99a9100dbd

elaxo.org
IP-
86.106.131[.]54