Eine gültige Signatur bedeutet nicht mehr sicheren Code

Secure Boot tat genau das, wofür es gebaut wurde, und das war das Problem. Am 14. Juli veröffentlichte die Sicherheitsfirma ESET eine von Martin Smolar geleitete Untersuchung, die elf von Microsoft signierte Bootloader zeigt, allesamt in Version 0.9 oder darunter, die ein Rechner bereitwillig ausführt, weil die Signatur echt ist. Der Code hinter dieser Signatur ist ein Jahrzehnt alt und fehlerhaft, doch Secure Boot prüft den Unterzeichner, nicht die Sicherheit des Signierten.

Das Ergebnis ist ein Angreifer, der auf nahezu jedem UEFI-Rechner ungeprüften Code beim Start ausführen kann. ESET meldete den Fund im Februar an die Koordinierungsstelle CERT/CC, und Microsoft setzte alle elf Dateien am 9. Juni auf seine Sperrliste. Die Lücke zwischen einer vertrauten Signatur und vertrauenswürdigem Code ist die ganze Geschichte, und sie wird durch den Patch allein nicht geschlossen.

So funktioniert die Umgehung

Der Angreifer bricht nichts auf; er liefert etwas bereits Vertrautes. Die meisten UEFI-Systeme tragen Microsofts Drittanbieter-Zertifikat, die Microsoft Corporation UEFI CA 2011, in ihrer Liste erlaubter Unterzeichner. Ein Angreifer kopiert einen der alten signierten Bootloader auf die EFI-Systempartition, den kleinen Boot-Bereich der Festplatte, und die Firmware akzeptiert ihn, weil die Signatur auf dieses vertraute Zertifikat zurückgeht. Es sind keine Administratorrechte nötig, nur die Möglichkeit, diese Datei zu schreiben.

Von dort an erledigen drei alte Lücken die Arbeit. Die Bootloader vertrauen veraltetem GRUB-2-Code mit einem Fehler von 2015, der ungeprüfte Module ausführt; Versionen unter 0.9 fehlt die Sperrliste, die bekannt schlechte Zertifikate blockieren würde; und Versionen vor 15.3 ignorieren SBAT, den neueren Mechanismus zum Aussortieren verwundbarer Binärdateien. Erfasst als CVE-2026-8863 und CVE-2026-10797, endet die Kette damit, dass Angreifer-Code läuft, bevor das Betriebssystem lädt, dem idealen Ort zum Verstecken.

Warum der Patch der einfache Teil ist

Ein Widerruf schützt nur ein Gerät, das ihn tatsächlich erhalten hat. Microsofts Fix vom 9. Juni fügt die elf Dateien zu dbx hinzu, der Firmware-Sperrliste, und auf verwalteten Windows-Flotten fließt dieses Update über die normalen Kanäle. Der Haken ist, dass viele Organisationen Änderungen an der Firmware-Sperrliste bewusst zurückhalten, weil ein falscher dbx-Eintrag ein Gerät nicht mehr booten lassen kann, und dieses Risiko ist bei älterer oder Dual-Boot-Hardware höher. Der Widerruf existiert; ob er Ihre Rechner erreicht hat, ist eine andere Frage.

Das tiefere Problem ist das Zählen. Das öffentliche shim-review-Verzeichnis begann erst 2017, und es gibt keine vergleichbare Liste dessen, was davor signiert wurde, sodass niemand mit Sicherheit sagen kann, wie viele alte, noch vertraute Bootloader im Umlauf sind. Elf ist die Zahl, die ESET benennen konnte, nicht die Zahl, die existiert. Eine Schutzmaßnahme, die davon abhängt, jeden vertrauten Unterzeichner zu kennen, ist genau dort schwach, wo das Inventar endet.

Was diese Woche wirklich zu prüfen ist

Behandeln Sie das als Aufgabe der Widerrufs-Hygiene, nicht als einzelnen Patch. Bestätigen Sie, dass das dbx-Update vom 9. Juni tatsächlich im gesamten Bestand angekommen ist, statt es anzunehmen; ESET verweist auf Prüfwerkzeuge und PowerShell-Abfragen, die den aktuellen Widerrufsstand melden. Weiten Sie die Prüfung über Windows hinaus aus, denn Linux-Server und Appliances erhalten denselben Fix über den Linux Vendor Firmware Service, und Dual-Boot-Notebooks sind der klassische blinde Fleck.

Für europäische Betreiber ist der Rahmen nun ebenso regulatorisch wie technisch. Nach NIS2 fällt die Integrität der Boot-Kette unter die Sicherheitsmaßnahmen, die eine wesentliche Einrichtung nachweisen soll, und ein Firmware-Bootkit ist genau die Art von Persistenz, nach der eine Aufsicht nach einem Vorfall fragen wird. Die Handlung des Eigentümers ist leicht gesagt und leicht übersprungen: prüfen Sie, was Ihre Firmware noch als vertrauenswürdig einstuft, und weisen Sie nach, dass die Sperre angekommen ist.

Weiterlesen: 570 Windows-Patches an einem Tag, zwei bereits ausgenutzt  |  18 Jahre alter Cisco-Fehler: jetzt 3 Tage Frist