Forscher von ESET haben 11 alte UEFI-Shim-Bootloader der Versionen 0.9 und darunter identifiziert. Mit ihnen lässt sich der UEFI Secure Boot auf jedem UEFI-basierten Rechner umgehen, der dem Zertifikat der Drittanbieter-Zertifizierungsstelle (CA) „Microsoft Corporation UEFI CA 2011“ von Microsoft vertraut, unabhängig vom installierten Betriebssystem (OS). Die gemeldeten Shim-Bootloader können ausgenutzt werden, um während des Systemstarts nicht vertrauenswürdigen Code auszuführen. Angreifer sind dadurch in der Lage, bösartige UEFI-Bootkits (wie Bootkitty, HybridPetya oder BlackLotus) selbst auf Systemen mit aktiviertem UEFI Secure Boot zu installieren. ESET hat seine Erkenntnisse im Februar 2026 an CERT/CC gemeldet. Die anfälligen UEFI-Anwendungen wurden am „Patch Tuesday“ von Microsoft am 9. Juni 2026 widerrufen.

Zwar wurden diesem Fall zwei CVE-IDs zugewiesen, um die gemeldeten Shims abzudecken – CVE-2026-8863 und CVE-2026-10797–, doch geht es bei der Ausnutzung jedes gemeldeten Shims nicht nur um einen oder zwei einzelne Fehler, die direkt in diesen alten Shims zu finden sind. Vielmehr wird die Angriffsfläche durch die vertrauenswürdigen Bootloader der zweiten Stufe (meist GRUB 2) der Shims erweitert, die – wie die Shims selbst – veraltete Versionen mit bekannten Schwachstellen enthalten können. Die entdeckten Shims stammen aus verschiedenen Tools oder Softwarepaketen, darunter PC-Diagnosesoftware, Linux-Distributionen und andere UEFI-basierte Dienstprogramme. Wichtig ist, dass die Ausnutzung nicht auf Systeme beschränkt ist, auf denen die betroffene Software oder das betroffene Betriebssystem installiert ist, da Angreifer ihre eigene Kopie der anfälligen Shim-Dateien auf jedes UEFI-System bringen können, auf dem das UEFI-Zertifikat eines Drittanbieters von Microsoft registriert ist.

Die vollständige Liste der Softwareprodukte, die auf die gemeldeten Shim-Dateien zurückgreifen, sowie deren betroffene Versionen ist in der Sicherheitsmitteilung (Vulnerability Note) von CERT/CC verfügbar. Als Reaktion auf den Bericht der ESET-Forscher wurden UEFI-Shim-Bootloader mit den folgenden PE-Authenticode -Hashes im Rahmen des dbx-Updates widerrufen, das Teil des „Patch Tuesday“ von Microsoft am 9. Juni war:

  • AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
  • 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
  • EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
  • FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
  • A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
  • 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
  • 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
  • 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
  • 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
  • 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
  • 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629
Die wichtigsten Punkte dieses Blogbeitrags:
  • ESET Forscher haben 11 alte, von Microsoft signierte UEFI-Anwendungen entdeckt, die es ermöglichen, den UEFI Secure Boot auf den meisten UEFI-basierten Systemen zu umgehen.
  • Ein Angreifer, der eine dieser anfälligen Anwendungen ausnutzt, kann während des Systemstarts nicht vertrauenswürdigen Code ausführen und so bösartige UEFI-Bootkits oder andere Malware einschleusen.
  • Die Ausnutzung ist nicht auf Systeme beschränkt, auf denen die betroffene Software oder das betroffene Betriebssystem installiert ist, da Angreifer ihre eigene Kopie der anfälligen Binärdateien auf jedes UEFI-System bringen können, auf dem das Microsoft-UEFI-Zertifikat für Drittanbieter registriert ist.
  • Alle UEFI-Systeme, auf denen die UEFI-Signierung durch Dritte von Microsoft aktiviert ist, sind betroffen (bei Windows 11 Secured-Core-PCs sollte diese Option standardmäßig deaktiviert sein).
  • Die anfälligen Binärdateien wurden von Microsoft im Rahmen des „Patch Tuesday“-Updates vom 9.. Juni 2026 widerrufen.

Im Folgenden finden Sie den Zeitplan für die koordinierte Offenlegung. Wir möchten uns bei CERT/CC für die Unterstützung bei der Koordination des Offenlegungsprozesses bedanken sowie bei den betroffenen Anbietern für die reibungslose und transparente Kommunikation und Zusammenarbeit während des Offenlegungs- und Behebungsprozesses. Um Ihre Systeme vor dieser Bedrohung zu schützen, installieren Sie die neuesten Microsoft -dbx -Updates. Eine Anleitung dazu finden Sie im Abschnitt „Schutz und Erkennung “.

Zeitplan für die koordinierte Offenlegung:

  • 16.02.2026 – ESET meldete die Ergebnisse zusammen mit einem Proof-of-Concept an CERT/CC.
  • 18.03.2026 – Der Termin für das dbx -Update und die öffentliche Bekanntgabe wurde auf 19. Mai 2026 (Microsofts „Patch Tuesday“ im Mai) festgelegt.
  • 30.03.2026 – Das Datum für das dbx -Update und die öffentliche Bekanntgabe wurde auf den 9. Juni 2026 (Microsofts „Patch Tuesday“ im Juni) verschoben.
  • 09.06.2026 – Microsofts „Patch Tuesday“-Update im Juni, Veröffentlichung der CERT/CC-Sicherheitsmitteilung.
  • 14.07.2026 – Veröffentlichung eines Blogbeitrags von ESET.

UEFI-Shim-Bootloader und UEFI Secure Boot

Um die Auswirkungen zu verstehen, die solche anfälligen Shim-Bootloader auf durch UEFI Secure Boot geschützte Systeme haben können, müssen wir wissen, wie UEFI Secure Boot funktioniert und wie signierte UEFI-Shim-Bootloader die Vertrauenskette von Secure Boot erweitern. In diesem Abschnitt befassen wir uns mit den Grundlagen von UEFI Secure Boot, der Art und Weise, wie UEFI-Shims die Vertrauenskette von UEFI Secure Boot erweitern, sowie mit zwei Shim-bezogenen Funktionen: Machine Owner Key (MOK) und Secure Boot Advanced Targeting (SBAT). Wer bereits mit der Theorie vertraut ist, kann direkt zum Abschnitt „Umgehung von UEFI Secure Boot mithilfe alter Shim-Dateien“ springen.

UEFI Secure Boot

Wie in Abbildung 1 dargestellt, überprüft die UEFI-Firmware beim Laden einer Startanwendung – wie beispielsweise des Windows Boot Managers oder eines UEFI-Shims – die Binärdatei anhand von zwei Secure-Boot-Datenbanken:

  • db (zulässige Zertifikate und Authenticode-Hashes) sowie
  • dbx (unzulässige Zertifikate und Authenticode-Hashes).
Figure 1. UEFI Secure Boot simplified scheme
Abbildung 1. Vereinfachtes Schema von UEFI Secure Boot (Quelle: „UEFI Bootkits and Where UEFI Security Fails“, S. 48)

Das Image muss in der Datenbank „db“ als vertrauenswürdig eingestuft sein und darf nicht in der Datenbank „dbx“ aufgeführt sein – andernfalls löst der Boot-Manager eine Sicherheitsverletzung aus, anstatt es auszuführen. Damit dies auf neu gekauften Geräten mit aktiviertem UEFI-Secure-Boot sofort funktioniert, tragen die meisten OEMs eine Reihe von Microsoft-UEFI-Zertifikaten in die Datenbank „db“ ein, nämlich:

  • Microsoft Windows Production PCA 2011 und Windows UEFI CA 2023 (werden zum Signieren von Microsofts eigenen UEFI-Boot-Anwendungen verwendet; das Zertifikat von 2011 wird aufgrund der BlackLotus-bezogenen Sicherheitslücken in Kürze zu dbx hinzugefügt ).
  • Microsoft Corporation UEFI CA 2011 und Microsoft UEFI CA 2023 (werden zum Signieren von UEFI-Boot-Software von Drittanbietern verwendet, wie z. B. Linux-Shims, Wiederherstellungstools und Festplattenverschlüsselungsprogramme).

Das bedeutet, dass jeder Entwickler, der möchte, dass seine Boot-Software standardmäßig mit UEFI Secure Boot kompatibel ist, seine Binärdateien über das Windows Hardware Dev Center zur Signierung bei Microsoft einreichen kann; nach der Genehmigung gelten die signierten Dateien auf den allermeisten UEFI-Systemen als vertrauenswürdig. Damit spielt Microsoft eine zentrale Rolle bei der Absicherung der meisten UEFI-basierten Geräte und entscheidet faktisch darüber, was während des Bootvorgangs ausgeführt werden darf und was nicht.

UEFI-Widerruf (dbx)

Das Widerrufskonzept von UEFI Secure Boot ist einfach: Wenn sich herausstellt, dass eine zuvor als vertrauenswürdig eingestufte Startanwendung – deren PE-Authenticode-Hash oder das Zertifikat, mit dem sie signiert wurde, in „db“ vorhanden ist – anfällig ist, wird ihr PE-Authenticode-Hash zu „dbx“ hinzugefügt, der von Microsoft verwalteten Datenbank für verbotene Signaturen (wobei der aktuelle Inhalt von „dbx“ in der Regel im GitHub-Repository von Microsoft veröffentlicht wird). Zertifikate selbst werden nur gelegentlich widerrufen.

Zwar mag die ursprüngliche Idee, einzelne anfällige Binärdateien anhand ihres Hashs zu widerrufen, zum Zeitpunkt der Einführung von Secure Boot sinnvoll gewesen sein, doch Fälle wie BootHole und BlackLotus zeigen, dass dieser Ansatz alles andere als ideal ist. Das grundlegende Problem ist die Skalierbarkeit, was im SBAT-Vorschlag bzw. in der Spezifikation des Red Hat Bootloader Teams gut zum Ausdruck kommt:

Im Rahmen des jüngsten Sicherheitsvorfalls „BootHole“ ( CVE-2020-10713) wurden 3 Zertifikate und 150 Image-Hashes zur UEFI-Secure-Boot-Sperrdatenbank „dbx“ auf der gängigen x64-Architektur hinzugefügt. Dieses einzelne Sperrereignis beansprucht 10 kB der 32 kB – also etwa ein Drittel – des auf UEFI-Plattformen üblicherweise verfügbaren Speicherplatzes für Sperrlisten. Aufgrund der Art und Weise, wie UEFI Sperrlisten zusammenführt, kann dies zusammen mit früheren Sperrereignissen dazu führen, dass die „dbx“-Datei eine Größe von fast 15 kB erreicht und damit fast 50 % der Kapazität auslastet.

Der gleiche Druck auf die dbx- Kapazität trat erneut bei den BlackLotus-bezogenen Sperrungen anfälliger Windows-Boot-Manager-Binärdateien zutage. Beides veranlasste Microsoft, gemeinsam mit seinen Partnern zusätzliche, versionsbasierte Sperrmechanismen einzuführen, die jeweils an einen der beiden weit verbreiteten, Secure-Boot-kompatiblen Bootloader gekoppelt sind:

  • Secure Boot Advanced Targeting (SBAT) – verwendet von „shim“, einem UEFI-Bootloader für Linux, ab Version 15.3.
  • Microsofts „Secure Boot Security Version Number“ (SVN) – verwendet vom Windows-Boot-Manager (veröffentlicht im April 2024) – in Bill Demirkapis „Booting with Caution“, S. 62, auch als „Revocation via Embedded Secure Version Information“ (REVISE) bezeichnet; dieser Name und dieses Akronym scheinen jedoch in der offiziellen Microsoft-Dokumentation nicht verwendet zu werden.

Kurz gesagt: Während dbx Binärdateien widerruft, widerrufen SBAT und Microsofts Secure-Boot-SVN Versionen. Wird eine Sicherheitslücke in einer UEFI-Anwendung entdeckt, die einen dieser versionsbasierten Sperrmechanismen unterstützt, müssen tatsächlich alle Builds bis einschließlich des betroffenen Builds ausgeschlossen werden – und das lässt sich viel einfacher durch eine Versionsnummer erfassen als durch eine lange Liste von Hashes. Weitere Informationen zu SBAT finden Sie im Abschnitt „Secure Boot Advanced Targeting (SBAT) “.

UEFI-Shim-Bootloader und Secure Boot

Bei Linux-Distributionen, die UEFI Secure Boot unterstützen, bringt der oben beschriebene, auf Microsoft-Schlüsseln basierende Secure-Boot-Mechanismus einige Herausforderungen mit sich. Jede Linux-Distribution generiert ihre eigenen Bootloader-Binärdateien, und jede davon hat einen anderen Hash-Wert. Es wäre zeitaufwendig, bürokratisch und in der Praxis kaum umsetzbar (wenn nicht gar unmöglich), jeden Linux-Bootloader direkt von Microsoft signieren zu lassen und dies über alle Linux-Distributionen hinweg zu verwalten.

Die Lösung für dieses Problem ist ein „Shim“: ein kleiner, minimaler Bootloader der ersten Stufe, den Microsoft einmalig prüfen und signieren kann und der dann einen sekundären Vertrauensanker für den Rest des distributionsspezifischen Linux-Boot-Stacks bildet – in der Regel GRUB 2 und den Linux-Kernel. Dieser Vertrauensanker ist ein weiteres Zertifikat, das als Herstellerzertifikat (verwaltet vom Distributionsanbieter) bezeichnet wird und der Shim-Binärdatei hinzugefügt wird, bevor diese von Microsoft signiert wird.

Eine vereinfachte Boot-Sequenz auf einem Secure-Boot-fähigen Linux-System unter Verwendung eines Shims ist in Abbildung 2 dargestellt.

Figure 2. Simplified UEFI boot flow on Linux systems
Abbildung 2. Vereinfachter UEFI-Boot-Ablauf auf Linux-Systemen

Die UEFI-Firmware lädt das Shim und überprüft dessen Signatur anhand der in der Firmware gespeicherten Microsoft-Zertifizierungsstelle (der Variable „db“ ). Das Shim übernimmt dann die Kontrolle und überprüft den Bootloader der zweiten Stufe (häufig GRUB 2) anhand seines eigenen eingebetteten Herstellerzertifikats – beispielsweise Debians UEFI-Schlüssel für Debian, Canonicals UEFI-Schlüssel für Ubuntu oder Red Hats Schlüssel für RHEL und Fedora. GRUB 2 wiederum überprüft den Kernel anhand desselben Herstellerzertifikats, bevor es die Kontrolle übergibt. Jeder Schritt wird kryptografisch durch den vorhergehenden Schritt abgesichert.

Diese Umleitung bedeutet, dass eine Linux-Distribution Bootloader- und Kernel-Updates schnell veröffentlichen und mit ihrem eigenen Hersteller-Schlüssel signieren kann, ohne für jedes Update erneut auf Microsoft zurückgreifen zu müssen. Nur der Shim selbst benötigt die Signatur von Microsoft – und dieser ändert sich nur selten.

Zusätzlich zum Herstellerzertifikat enthält der Shim oft ein weiteres integriertes Zertifikat, das ausschließlich mit dem jeweiligen Shim-Build bzw. der jeweiligen Binärdatei verknüpft ist. Dieses Zertifikat wird oft als „Shim-Zertifikat“ bezeichnet und dient dazu, die Integrität der Shim-Dienstprogramme zu signieren und zu überprüfen, die während der Erstellungsphase des Shims generiert werden können, wie beispielsweise MokManager (der zur Verwaltung von MOKs dient und weiter unten näher erläutert wird) oder das Fallback-Modul des Shims.

Machine Owner Key (MOK)

Wenn es um Shims geht, dürfen wir einen weiteren wichtigen Mechanismus nicht außer Acht lassen, der es einem Shim ermöglicht, vom Benutzer verwaltete externe Schlüssel zu verwenden, die als Machine Owner Keys (MOKs) bekannt sind. Eine MOK-Zulassungsliste (man kann sie sich als eine Shim-spezifische „Erweiterung“ der UEFI-db-Datenbank vorstellen) wird in einer nur beim Booten verfügbaren NVRAM-Variablen namens „MokList“ gespeichert, und eine Sperrliste (die Shim-spezifische „Erweiterung“ der UEFI-dbx-Datenbank ) wird in einerNVRAM-Variable namens „MokListX“ gespeichert; um beide Variablen auf einem System mit aktiviertem UEFI Secure Boot zu ändern, ist physischer Zugriff erforderlich (Boot-only-Variablen können nur während des Bootvorgangs geändert werden, bevor der Betriebssystem-Loader die UEFI-Boot-Services-Funktion „ExitBootServices“ aufruft). Zur Verwaltung der Listen nutzt der Shim die UEFI-Anwendung „MokManager“. Eine Anleitung zur Verwaltung von MOKs finden Sie hier. Abbildung 3 veranschaulicht, wie ein MOK die Vertrauenskette des UEFI Secure Boot des Shims erweitert.

Figure 3. Simplified UEFI boot flow on Linux systems (with Machine Owner Key)
Abbildung 3. Vereinfachter UEFI-Boot-Ablauf auf Linux-Systemen (mit Machine Owner Key)

Wie wir bereits in unseren Berichten zu BlackLotus und Bootkitty beschrieben haben, neigen Bootkits aufgrund der nicht authentifizierten Natur der vom MOK-Mechanismus verwendeten „Boot-only“-NVRAM-Variablen dazu, MOKs zur Persistenz zu missbrauchen, sobald sie UEFI Secure Boot erfolgreich umgangen haben.

Secure Boot Advanced Targeting (SBAT)

Jede UEFI-Anwendung (Komponente), die SBAT unterstützt, enthält ein kleines Stück Metadaten in einem dedizierten .sbat-Abschnitt ihrer PE-Datei, der durch dieselbe Signatur geschützt ist wie die Binärdatei selbst. Die Metadaten benennen die Komponente (z. B. „shim“ oder „grub“) und weisen ihr eine Generationsnummer zu, die bei jeder Veröffentlichung eines Sicherheitspatches erhöht wird.

Was diese Nummern zu einem Sperrmechanismus macht, ist eine Abgleichrichtlinie auf dem UEFI-System selbst: eine nur beim Bootvorgang verwendete UEFI-Variable namens „SbatLevel“, die für jede bekannte Komponente die minimal zulässige Generationsnummer speichert. Entscheidend ist, dass diese Variable vom Shim und nicht von der Firmware verwaltet und durchgesetzt wird, was im Vergleich zu einem dbx-Update schnellere Sperr-Updates ermöglicht. Der Shim bettet die Richtlinie ein, sodass die Durchsetzung nicht ausschließlich auf der externen Variablen beruht und alle neueren, über „SbatLevel“ bereitgestellten Richtlinien berücksichtigt werden. Bei jedem Systemstart überprüft der Shim zunächst seine eigenen SBAT-Metadaten anhand der Richtlinie – sodass ein veralteter Shim dazu gebracht werden kann, sich selbst abzulehnen – und wendet dann denselben Test auf jede geladene Binärdatei an, wobei er alles ablehnt, dessen Generationsnummer unter das von der Richtlinie geforderte Minimum fällt.

Beispiele für SBAT-Sperrungen sind in Abbildung 4 dargestellt. Diese stammen aus der Datei „SbatLevel_Variable.txt“ im Shim-Repository, das als einzige Quelle für SBAT-Sperrungen dient.

Figure 4. Latest SBAT revocations in the shim repository
Abbildung 4. Aktuellste SBAT-Sperrungen im Shim-Repository

Die erzwungene Stufe wird vor dem Betriebssystem nicht verborgen – der Shim veröffentlicht eine schreibgeschützte Kopie von `SbatLevel` in einer Laufzeitvariablen, `SbatLevelRT`. Das Betriebssystem kann überprüfen, welche Sperrrichtlinie derzeit in Kraft ist, sie jedoch nicht ändern. Unter Windows sind dieselben Informationen auch über den Registrierungswert HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\SbatLevel verfügbar.

Umgehung von UEFI Secure Boot mithilfe alter Shims

Nachdem wir im vorigen Abschnitt die Theorie zur Secure-Boot-Vertrauenskette eines Shims erläutert haben, können wir uns nun auf die praktischen Auswirkungen konzentrieren, die vergessene und alte, aber vertrauenswürdige UEFI-Binärdateien auf die Sicherheit von UEFI-Systemen haben können.

Wir veranschaulichen dies anhand einiger spezifischer Probleme in den gemeldeten Shims – Probleme, die leicht ausgenutzt werden können und die Breite der dadurch offengelegten Angriffsfläche verdeutlichen.

Anfällige Bootloader der zweiten Stufe

Jeder der gemeldeten Shims enthält sowohl ein vom Hersteller verwaltetes als auch ein integriertes Shim-Zertifikat, die als Vertrauensanker für die Bootloader oder Dienstprogramme der zweiten Stufe des Shims dienen: GRUB-2-Binärdateien, MokManager, Fallback-Loader und gelegentlich andere vom Hersteller signierte Shim-Zertifikate, die die Vertrauenskette noch weiter ausdehnen. Die Anzahl der Binärdateien, denen ein bestimmtes Shim vertraut, variiert: von weniger als zehn im Fall dedizierter, spezialisierter Software bis zu fast hundert im Fall bekannter Linux-Distributionen.

Die Signatur- und Kompilierungszeitstempel der Anwendungen, denen die von uns gemeldeten Shim-Programme vertrauen, reichen von 2013 bis 2025 – genug, um zu bestätigen, dass ein erheblicher Teil dieser Binärdateien veraltet war und wahrscheinlich von zahlreichen öffentlich bekannten Schwachstellen betroffen war, darunter im Fall von GRUB 2 die bereits erwähnte „BootHole“-Schwachstelle. Während die meisten dieser vertrauenswürdigen Komponenten alt genug sind, um ein gewisses Sicherheitsrisiko darzustellen, scheint GRUB 2 das schwächste Glied zu sein. Es handelt sich um eine komplexe Software, und in älteren Versionen häufen sich entsprechend Sicherheitslücken an.

Betrachten wir den Shim von Oracle Linux, der zu den von uns gemeldeten gehört. Er vertraut Binärdateien, die mit einem auf die Oracle Corporation ausgestellten Zertifikat signiert sind (SHA-1-Fingerabdruck: 2E434A724B4759C981E4189AA5AD3D635096DD2F). Eine der mit diesem Zertifikat signierten Binärdateien ist eine GRUB-2-Binärdatei, die sich in der Oracle-Linux-7.1-Installations-ISO (V74844-01.iso) befindet. Diese Binärdatei ist von CVE-2015-5281 betroffen, was – um den Schwachstellenbericht zu zitieren – „bei Verwendung auf UEFI-Systemen lokalen Benutzern ermöglicht, vorgesehene Secure-Boot-Einschränkungen zu umgehen und nicht verifizierten Code über ein manipuliertes (1) multiboot- oder (2) multiboot2-Modul auszuführen“. Beide genannten Module, „multiboot“ und „multiboot2“, ermöglichen das Laden von nicht signiertem Code während des Systemstarts mithilfe der gleichnamigen Befehle und sollten in signierten, UEFI-Secure-Boot-kompatiblen GRUB-2-Binärdateien untersagt sein, da sie UEFI Secure Boot konstruktionsbedingt umgehen.

Der Exploit ist einfach: Es müssen keine Speicherbeschädigungsfehler ausgelöst, keine ROP-Ketten aufgebaut und keine komplexen Reverse-Engineering-Maßnahmen durchgeführt werden. Die einzige Voraussetzung ist die Erstellung eines benutzerdefinierten, nicht signierten, multiboot2-kompatiblen Kernel-Images – in der Praxis kaum mehr als eine ELF-Binärdatei, die die erforderlichen Header und eine Handvoll weiterer Besonderheiten enthält. Sobald ein Angreifer diese Binärdatei erstellt und sie zusammen mit dem anfälligen Shim und GRUB 2 auf die EFI-Systempartition (ESP) kopiert hat, kann ein einziger GRUB-2-Multiboot2-Befehl verwendet werden, um sie während des Bootvorgangs zu laden und auszuführen – unabhängig davon, ob Secure Boot aktiviert ist oder nicht. Ein Proof-of-Concept, der die Ausnutzung von CVE-2015-5281 über den alten, gemeldeten Oracle-Linux-Shim auf einem System mit aktiviertem UEFI-Secure-Boot (ohne die neuesten Microsoft-Patches) demonstriert, ist im folgenden Video zu sehen:

Fehlen neuerer Funktionen

Im Laufe der Jahre hat sich der UEFI-Shim-Bootloader natürlich weiterentwickelt, wobei in aufeinanderfolgenden Veröffentlichungen des Upstream-Repositorys für den UEFI-Shim neue Verbesserungen und Sicherheitsfunktionen eingeführt wurden. Gleichzeitig haben viele Drittanbieter verfügbare Versionen des Shim-Quellcodes genutzt, um ihre eigenen Binärdateien zu erstellen, die sie anschließend zur Signierung an Microsoft übermittelten. Dieses Verhalten ist zu erwarten und entspricht dem ursprünglichen Design von Shims. Allerdings wurde der Sperrung veralteter, von Microsoft signierter Shims nicht genügend Aufmerksamkeit geschenkt, von denen viele aufgrund ihres Designs dazu genutzt werden können, neuere Sicherheitsmechanismen zu umgehen. Wir veranschaulichen diese Lücke anhand einiger konkreter Beispiele.

Durchsetzung der MOK-Sperrliste

Die MokList (MOK-basierte Zulassungsliste) wird vom Upstream-UEFI-Shim bereits seit fast Beginn an (Version 0.3) unterstützt. MOK-Widerrufe (MokListX) werden jedoch erst seit Version 0.9 durchgesetzt. Warum ist das ein Problem? Stellen Sie sich folgendes Szenario vor...

Ein Unternehmen hat sein eigenes MOK registriert, um benutzerdefinierte UEFI-Tools und Bootloader zu signieren, die es in seinem Netzwerk einsetzt. In mehreren dieser Binärdateien taucht eine Sicherheitslücke auf, und als Reaktion darauf widerrufen die Administratoren das alte Signaturzertifikat, indem sie es in die MOK-Sperrliste (MokListX) aufnehmen. Anschließend registrieren sie ein neues MOK und signieren die gepatchten Versionen der betroffenen Binärdateien erneut mit dem neuen Schlüssel. Die alten, anfälligen Binärdateien werden nun vom Shim abgelehnt, während die neu signierten ordnungsgemäß geladen werden, sodass die Geräte des Unternehmens sicher erscheinen. Das alte Zertifikat ist weiterhin in der MokList vorhanden und wird dort als vertrauenswürdig eingestuft, ist jedoch in MokListX widerrufen, wo diese Regel mit höherer Priorität durchgesetzt wird.

In diesem Szenario könnte ein Angreifer den aktuellen Shim des Opfers durch einen älteren, von Microsoft signierten UEFI-Shim aus unserem Bericht ersetzen – beispielsweise Version 0.8 der Abitti-1-Software, die von Microsoft für die finnische Matriculation Examination Board signiert wurde. Dieser Shim vertraut weiterhin den in der MokList-Variablen des Opfers gespeicherten Zertifikaten, in der das veraltete MOK-Zertifikat weiterhin gültig ist, ignoriert jedoch MokListX, da er vor der Einführung der Durchsetzung der MOK-Denylist erstellt wurde. Infolgedessen könnte der Shim des Angreifers dazu genutzt werden, anfällige Binärdateien ohne Einschränkung zu laden, was die Ausführung von beliebigem Code oder die Installation eines bösartigen UEFI-Bootkits ermöglicht.

Durchsetzung der SBAT-Regeln

Das gleiche Problem gilt für SBAT. Die Unterstützung dafür wurde im Upstream in Shim-Version 15.3 eingeführt, sodass alle früheren Shim-Versionen diesen Mechanismus nicht kennen: Sie lesen weder die SbatLevel-Sperrrichtlinie noch überprüfen sie den .sbat-Abschnitt des von ihnen geladenen Bootloaders der zweiten Stufe. Infolgedessen ignoriert er alle späteren SBAT-Widerrufe, die dazu dienen, anfällige Komponenten zu blockieren.

In diesem Fall würde ein Angriffsszenario wie folgt aussehen: Ein Angreifer kombiniert einen von Microsoft signierten– wie beispielsweise den Shim der Version 0.9 aus Red Hat Enterprise Linux 7.2, der Teil unseres Berichts war –, kombiniert ihn mit einer der zahlreichen GRUB-2-Binärdateien, denen der Shim noch vertraut, die SBAT jedoch bereits widerrufen hat, und kopiert anschließend beide auf das ESP. Während des Systemstarts überprüft der Shim die GRUB-2-Binärdatei anhand seines eigenen eingebetteten Zertifikats, konsultiert SBAT zu keinem Zeitpunkt und lädt die anfällige Binärdatei ohne Beanstandung – wodurch es dem Angreifer freisteht, jede Schwachstelle in dieser GRUB-2-Binärdatei auszunutzen.

Bekannte Schwachstellen im Shim

Schließlich sind alte Shims einfach alter Code, und viel alter Code weist bekannte Schwachstellen auf. Um dies zu veranschaulichen, verwenden wir ein Beispiel für ein altes Problem, das Shims der Version 0.9 und darunter betrifft. Dieser Schwachstelle war bis zu unserem Bericht keine CVE-ID zugewiesen worden – obwohl sie bereits vor fast genau einem Jahrzehnt in der Meldung eines der Upstream-Commits des Shim-Repositorys, d241bbb, behoben und ausführlich beschrieben wurde. Sie wird nun unter der Kennung CVE-2026-10797 geführt.

Das Problem besteht darin, dass eine mit Authenticode signierte PE-Binärdatei die Länge ihrer Signatur an zwei unabhängigen Stellen speichert:

  • im Datenverzeichnis ihres PE-Headers (IMAGE_DIRECTORY_ENTRY_SECURITY) und
  • in ihrer WIN_CERTIFICATE -Struktur, die die Signatur selbst kapselt.

In den betroffenen Shims waren sich die Funktionen zur Sperrprüfung und zur Signaturüberprüfung nicht einig, welchem Größenwert sie vertrauen sollten. Die Sperrprüfung verwendete den Wert aus dem Signatur-Header, während die Signaturüberprüfungsfunktion den Wert aus dem PE-Header verwendete.

Es ist somit möglich, den Sperrmechanismus zu umgehen, indem die WIN_CERTIFICATE-Struktur des Bootloaders der zweiten Stufe so manipuliert wird, dass die Sperrfunktion dbx und MokListX mit gefälschten Daten vergleicht, anstatt mit der tatsächlichen Signatur des Bootloaders.

Einfach ausgedrückt: Selbst wenn das Zertifikat des Bootloaders der zweiten Stufe in dbx oder MokListX widerrufen worden wäre, würde der Shim dies nicht bemerken. Dazu zwei wichtige Anmerkungen:

  • Diese Umgehung funktioniert nur bei zertifikatsbasierten Sperrungen (nicht bei hashbasierten Sperrungen), und
  • der Bootloader der zweiten Stufe muss mit einem im Shim eingebetteten Zertifikat signiert sein (unabhängig davon, ob es sich um das während des Erstellungsprozesses des Shims generierte integrierte Zertifikat des Shims oder um das Herstellerzertifikat handelt).

Diese Einschränkungen ergeben sich daraus, dass hashbasierte Sperrungen und nicht eingebettete Zertifikate (aus MokList und db) an anderer Stelle im Code überprüft werden und von diesem Problem nicht betroffen sind.

Würde das Ablaufen von Microsoft-UEFI-Zertifikaten dieses Problem nicht lösen?

Angesichts der aktuellen Ablaufdaten von Microsoft-UEFI-Zertifikaten (wie in Abbildung 5 dargestellt, ist das Zertifikat „Microsoft Corporation UEFI CA 2011“ am 27. Juni 2026 abgelaufen) könnte man sich fragen, ob die Meldung von anfälligen UEFI-Anwendungen, die mit diesem abgelaufenen Zertifikat signiert wurden, nicht nur unnötigen Aufruhr verursacht.

Tatsächlich hat das Ablaufdatum des UEFI-Zertifikats jedoch keinerlei Auswirkungen auf den Secure-Boot-Überprüfungsprozess. Solange das Zertifikat „Microsoft Corporation UEFI CA 2011“ in der Datenbank verbleibt und nicht in dbx widerrufen wird, gelten alle Bootloader, die gültig mit diesem abgelaufenen Zertifikat signiert sind, weiterhin als vertrauenswürdig, sofern sie nicht explizit anhand ihres Hash-Werts widerrufen werden. Dies ist der Grund, warum Microsoft neue Einreichungen bis zum Ablaufdatum weiterhin mit dem alten Zertifikat signiert hat.

Figure 5. Microsoft Corporation UEFI CA 2011 certificate
Abbildung 5. Zertifikat „Microsoft Corporation UEFI CA 2011“

Schutz und Erkennung

Diese anfälligen Shims können durch die Anwendung der neuesten UEFI-Sperrlisten von Microsoft blockiert werden. Windows-Systeme sollten automatisch aktualisiert werden. Abbildung 6 zeigt PowerShell-Befehle (die mit erhöhten Berechtigungen ausgeführt werden müssen), um zu überprüfen, ob die erforderlichen Sperrlisten auf Ihrem Windows-System installiert sind.

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

Abbildung 6. PowerShell-Befehle zur Überprüfung der UEFI-Sperrlisten

Für Linux-Systeme sollten Updates über den Linux Vendor Firmware Service verfügbar sein, und der Widerrufsstatus kann mithilfe des Skripts „uefi-dbx-audit“ überprüft werden.

Allgemeinere Empfehlungen zum Schutz vor (oder zumindest zur Erkennung von) der Ausnutzung unbekannter, anfälliger, signierter UEFI-Bootloader und zum Einsatz von UEFI-Bootkits finden Sie in unserem Blogbeitrag „Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344“.

Fazit

Was diese alten Shims so gefährlich macht, ist nicht eine neuartige Sicherheitslücke, sondern die Tatsache, dass keine neue Sicherheitslücke erforderlich ist, um UEFI Secure Boot zu umgehen. Ein Angreifer benötigt keine komplizierten Exploits – lediglich eine Kopie einer alten, nach wie vor vertrauenswürdigen, aber nicht widerrufenen Shim-Binärdatei sowie ein grundlegendes Verständnis der Funktionsweise von UEFI-Shims. Das reicht aus, um eine so wesentliche Sicherheitsfunktion wie UEFI Secure Boot zu umgehen.

Zwar wurde durch den Widerruf dieser 11 Shim-Dateien das unmittelbare Problem behoben, doch bleibt ein tiefer liegendes Problem bestehen: die Transparenz. Der Signierungsprozess für Shim-Dateien wurde 2017 mit der Einführung des „shim-review“-Repositorys deutlich transparenter; dort werden die von Anbietern eingereichten Shim-Dateien von den Betreuern geprüft, bevor Microsoft sie signiert. Jeder seitdem genehmigte Shim ist dokumentiert – die früher signierten jedoch nicht, und niemand kann zuverlässig sagen, wie viele dieser alten, nach wie vor als vertrauenswürdig eingestuften Shims noch vorhanden sind. Was nicht vollständig und transparent katalogisiert wurde, kann nicht effektiv außer Betrieb genommen werden.

Positiv zu vermerken ist, dass wir glauben, dass sich der Trend in die richtige Richtung bewegt. Jede Offenlegung wie diese verringert die Anzahl vergessener Shim-Dateien, und dank verbesserter Transparenz bei der Shim-Signierung sowie Mechanismen wie SBAT lassen sich die zu widerrufenden Shim-Dateien weitaus effizienter als in der Vergangenheit nachverfolgen und effektiv widerrufen. Der nächste Schritt besteht darin, dieses Maß an Transparenz im UEFI-Signatur- Ökosystem von Microsoft für Drittanbieter auf UEFI-Anwendungen von Drittanbietern ohne Shim auszuweiten, die, wie wiederholt gezeigt wurde (z. B. CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …) ebenfalls als einfache Quelle für Umgehungen des UEFI Secure Boot dienen können.

IoCs

Da die anfälligen Shims Teil legitimer Softwarepakete sind, die potenziell auf Tausenden von Systemen vorhanden sind, die über diese Loader noch nie kompromittiert wurden, stellen wir keine Indikatoren für eine Kompromittierung (IoCs) bereit, um massive Fehlidentifizierungen zu vermeiden. Stattdessen sollten Sicherheitsverantwortliche die Empfehlungen im Abschnitt „Schutz und Erkennung“ befolgen.

Bei Fragen zu unseren auf WeLiveSecurity veröffentlichten Forschungsergebnissen wenden Sie sich bitte an threatintel@eset.com.
ESET Research bietet private APT-Intelligence-Berichte und Daten-Feeds an. Bei Fragen zu diesem Service besuchen Sie bitte die ESET Threat Intelligence -Seite.