ESET entdeckt 11 Microsoft-signierte UEFI-Shims mit Secure-Boot-Bypass

Ahmet Taş | Express Webdesign24

BERLIN, DEUTSCHLAND — ESET-Forscher haben elf veraltete, von Microsoft signierte UEFI-Shim-Bootloader entdeckt, mit denen Angreifer Secure Boot umgehen und nicht vertrauenswürdigen Code vor dem Start des Betriebssystems ausführen können.

Die betroffenen Komponenten stammen überwiegend aus Shim-Version 0.9 oder älteren Ausgaben. Obwohl die darin enthaltenen Schwachstellen teilweise seit Jahren bekannt waren, wurden die Binärdateien von vielen UEFI-Systemen weiterhin akzeptiert, weil ihre Microsoft-Signaturen noch nicht in der Sperrdatenbank DBX eingetragen waren.

ESET meldete die Ergebnisse am 16. Februar 2026 gemeinsam mit einem Machbarkeitsnachweis an das CERT Coordination Center. Microsoft sperrte die elf identifizierten Dateien anschließend im Rahmen der Sicherheitsaktualisierungen vom 9. Juni 2026. Die ausführliche technische Analyse veröffentlichte ESET am 14. Juli.

Veraltete Bootloader blieben weiterhin vertrauenswürdig

Ein UEFI-Shim ist ein kleiner, digital signierter Bootloader, der zwischen der UEFI-Firmware eines Computers und dem eigentlichen Betriebssystem vermittelt. Er wird vor allem von Linux-Distributionen genutzt, damit diese auf Geräten mit aktiviertem Secure Boot starten können, ohne dass der Schlüssel jeder einzelnen Distribution direkt in der Firmware hinterlegt werden muss.

Microsoft signierte zahlreiche Shim-Versionen mit dem weitverbreiteten Zertifikat „Microsoft Corporation UEFI CA 2011“. Gerätehersteller hinterlegten dieses Zertifikat in der autorisierten Secure-Boot-Datenbank vieler Computer, damit auch Boot-Komponenten von Drittanbietern ausgeführt werden konnten.

Das grundlegende Konzept war vorgesehen und legitim. Problematisch wurde jedoch, dass verschiedene Anbieter auf älteren Versionen des quelloffenen Shim-Projekts aufbauten, eigene Varianten erstellten und sie zur Signierung an Microsoft übermittelten. Später erkannte und behobene Schwachstellen in Shim führten nicht automatisch dazu, dass bereits signierte alte Dateien ihre Vertrauensstellung verloren.

Solange eine solche Datei durch ein in der DB hinterlegtes Zertifikat autorisiert und ihr Hashwert nicht in der Sperrliste DBX enthalten war, konnte die Firmware sie weiterhin ausführen. Dadurch entstand ein langfristiges Lieferkettenrisiko: Vollständig aktualisierte Systeme konnten weiterhin ältere, signierte und verwundbare Boot-Komponenten akzeptieren.

So kann Secure Boot umgangen werden

UEFI Secure Boot soll verhindern, dass manipulierte oder nicht autorisierte Software bereits während des Startvorgangs ausgeführt wird. Dazu überprüft die Firmware jede Boot-Komponente anhand mehrerer Datenbanken.

Die sogenannte DB enthält zugelassene Zertifikate und Hashwerte. Die DBX enthält dagegen Zertifikate und Datei-Hashes, die ausdrücklich nicht mehr akzeptiert werden dürfen. Eine Boot-Anwendung wird nur gestartet, wenn sie als vertrauenswürdig eingestuft ist und nicht auf der Sperrliste steht.

Bei den von ESET entdeckten Dateien funktionierte diese Kontrolle formal korrekt: Die Shims verfügten über eine gültige Microsoft-Signatur und waren noch nicht gesperrt. Ihr veralteter Programmcode erlaubte jedoch, die nachfolgenden Sicherheitsprüfungen zu umgehen und weitere nicht vertrauenswürdige Komponenten zu laden.

CERT/CC vergleicht das Vorgehen mit einem „Bring Your Own Vulnerable Driver“-Angriff. Der Angreifer nutzt dabei nicht zwingend eine bereits auf dem Zielcomputer installierte Komponente. Stattdessen bringt er selbst eine bekannte, verwundbare, aber korrekt signierte Datei mit und fügt sie in den Startprozess ein.

Der Angriff ist daher nicht auf Computer beschränkt, auf denen eines der ursprünglich betroffenen Programme oder eine bestimmte Linux-Distribution installiert ist. Eine Kopie des verwundbaren Shims kann grundsätzlich auf andere UEFI-Systeme übertragen werden, sofern diese dem Microsoft-Zertifikat für UEFI-Komponenten von Drittanbietern vertrauen und das notwendige DBX-Update nicht erhalten haben.

Schadcode startet vor Windows oder Linux

Das besondere Risiko liegt im Zeitpunkt der Ausführung. Der eingeschleuste Code kann bereits während der frühen Boot-Phase aktiv werden, bevor Windows, Linux oder ein anderes Betriebssystem vollständig geladen wurde.

Zu diesem Zeitpunkt sind viele gewöhnliche Sicherheitsmechanismen noch nicht aktiv. Antivirenprogramme, Endpoint-Detection-Systeme und andere betriebssystembasierte Schutzlösungen können einen Angriff deshalb möglicherweise erst erkennen, nachdem der Schadcode bereits tief in den Startprozess eingegriffen hat.

Nach Angaben von CERT/CC könnten Angreifer unsignierte oder manipulierte Kernel-Komponenten laden und eine dauerhafte Kompromittierung des Systems erreichen. Boot-Level-Schadsoftware kann Neustarts überstehen und in bestimmten Fällen sogar nach einer Neuinstallation des Betriebssystems weiterhin wirksam bleiben.

ESET weist darauf hin, dass die Schwachstellen unter anderem den Einsatz von UEFI-Bootkits erleichtern könnten. Solche Schadprogramme setzen unterhalb des eigentlichen Betriebssystems an und können Schutzfunktionen manipulieren, den Bootvorgang verändern oder weitere Malware laden.

Für eine Ausnutzung benötigt ein Angreifer allerdings in der Regel bereits Administratorrechte oder eine andere Möglichkeit, den Startprozess des Zielsystems zu verändern. Es handelt sich damit nicht um eine einfache Schwachstelle, über die jeder Computer ohne vorherigen Zugriff unmittelbar aus dem Internet übernommen werden kann.

Elf Dateien aus unterschiedlichen Softwarepaketen betroffen

Die von ESET identifizierten Shims stammen aus unterschiedlichen Softwareprodukten und Boot-Umgebungen. Dazu gehören ältere Linux-Distributionen, Diagnoseprogramme, Verwaltungssoftware, Datenlöschlösungen und weitere UEFI-basierte Hilfsprogramme.

Die CERT/CC-Liste nennt unter anderem Komponenten aus Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, OpenSUSE, PC-Doctor Service Center, WipeDrive, ROSA Linux und der baramundi Management Suite. Die meisten betroffenen Dateien basieren auf Shim 0.9 oder noch älteren Versionen.

Die Sicherheitsprobleme werden unter anderem mit den Kennungen CVE-2026-8863 und CVE-2026-10797 erfasst. Die vollständige Risikobewertung beschränkt sich jedoch nicht nur auf diese beiden Einträge.

Ein alter Shim kann zusätzlich veraltete zweite Boot-Stufen wie ältere GRUB-Versionen laden. Diese können weitere bekannte Sicherheitslücken enthalten, die in aktuellen Ausgaben längst behoben wurden. Der verwundbare Shim öffnet damit möglicherweise den Zugang zu einer ganzen Kette historischer Schwachstellen.

Dass ein Produkt auf der Liste steht, bedeutet nicht automatisch, dass jedes Gerät mit diesem Produkt kompromittiert wurde. Umgekehrt bedeutet das Fehlen der genannten Software nicht, dass ein System ohne eingespielte Sperraktualisierung vollständig geschützt ist.

Microsoft sperrte die Komponenten über die DBX

Als Reaktion auf die koordinierte Meldung nahm Microsoft die Authenticode-Hashes der elf Dateien in die UEFI-Sperrdatenbank auf. Die entsprechenden Einträge wurden mit den Sicherheitsaktualisierungen vom 9. Juni 2026 verteilt.

Sobald die aktualisierte DBX erfolgreich in der Gerätefirmware gespeichert ist, erkennt Secure Boot die betroffenen Dateien als gesperrt und verhindert ihre Ausführung. Eine weiterhin vorhandene Microsoft-Signatur reicht dann nicht mehr aus, um die Bootloader zu starten.

Die Sperrung einzelner Hashwerte schützt gezielt vor den bekannten elf Dateien. ESET warnt jedoch davor, dass weitere alte, früher signierte und bislang nicht vollständig katalogisierte Shim-Versionen existieren könnten. Der Signierungsprozess wurde erst ab 2017 stärker dokumentiert und öffentlich nachvollziehbar gestaltet.

Auch der Ablauf eines alten Zertifikats führt nicht automatisch dazu, dass bereits damit signierte Dateien blockiert werden. Entscheidend ist bei Secure Boot, ob das Zertifikat beziehungsweise die Datei weiterhin in der Vertrauensdatenbank zugelassen und nicht in der DBX gesperrt ist.

Damit zeigt der Fall ein grundsätzliches Problem digitaler Signaturen: Eine Datei kann zum Zeitpunkt der Signierung vertrauenswürdig gewesen sein, später aber durch neu entdeckte Schwachstellen unsicher werden. Ohne wirksamen Widerrufsprozess bleibt die ursprüngliche Vertrauensentscheidung bestehen.

Windows- und Linux-Systeme sollten aktualisiert werden

ESET empfiehlt, die neuesten Microsoft-DBX-Aktualisierungen zu installieren. Auf Windows-Systemen sollen die entsprechenden Änderungen über den regulären Windows-Update-Prozess verteilt werden. Nutzer sollten alle ausstehenden Sicherheitsupdates installieren und das Gerät neu starten, wenn Windows dazu auffordert.

Unternehmen und IT-Administratoren sollten zusätzlich prüfen, ob die DBX-Aktualisierung tatsächlich in der Firmware angekommen ist. Microsoft dokumentiert dafür Ereigniseinträge im Windows-Systemprotokoll, mit denen erfolgreiche Secure-Boot-, DB-, DBX- und Zertifikatsänderungen sowie mögliche Fehler kontrolliert werden können.

Microsoft weist darauf hin, dass mehrere Schritte erfolgreich abgeschlossen werden müssen. Dazu gehören die Aufnahme neuer UEFI-Zertifikate aus dem Jahr 2023, die Aktualisierung des Schlüsselaustauschschlüssels und die Umstellung auf einen neu signierten Windows-Start-Manager. Bestimmte Schritte werden erst nach einem Neustart abgeschlossen.

Auf Linux-Systemen sollen Aktualisierungen über die jeweilige Distribution und den Linux Vendor Firmware Service bereitgestellt werden. Administratoren können außerdem Prüfwerkzeuge einsetzen, um den Stand der UEFI-DBX und der gesperrten Boot-Komponenten zu kontrollieren.

Vor einer unternehmensweiten Verteilung sollten Änderungen an Secure Boot getestet werden. Werden alte Boot-Komponenten gesperrt, die noch von Wiederherstellungsmedien, Installationsabbildern, PXE-Systemen oder Spezialgeräten benötigt werden, kann dies dazu führen, dass diese Medien oder Systeme nicht mehr starten.

Secure Boot sollte nicht deaktiviert werden

Das Abschalten von Secure Boot ist keine empfohlene Lösung. Dadurch würde eine wichtige Schutzschicht vollständig entfernt, während das eigentliche Problem der veralteten und weiterhin vertrauenswürdigen Boot-Komponenten bestehen bliebe.

Sinnvoller ist es, Betriebssystem, Firmware, Bootloader und DBX-Sperrlisten aktuell zu halten. Unternehmen sollten auch ältere Wiederherstellungsmedien, bootfähige USB-Sticks, virtuelle Maschinen, Serverabbilder und lange nicht aktualisierte Linux-Installationen in ihre Bestandsaufnahme einbeziehen.

ESETs Untersuchung macht deutlich, dass Cybersicherheit nicht nur von neuen Sicherheitslücken abhängt. Auch Komponenten, die vor vielen Jahren digital signiert und damals als sicher eingestuft wurden, können später zu einem erheblichen Risiko werden, wenn bekannte Schwachstellen nicht konsequent durch Sperrlisten und Firmware-Aktualisierungen geschlossen werden.

ExpressWebdesign24.de