UEFI ist die Firmware-Schicht auf dem Mainboard, die Betriebssystem und Hardware verbindet. Auf Systemen mit aktiviertem Secure Boot startet die Firmware einen Shim-Bootloader als kleine erste Stufe zwischen Firmware und dem eigentlichen Bootloader des Betriebssystems. In Linux-Umgebungen dienen diese Shims als vertrauenswürdige Startkomponente, die weitere Teile des Startvorgangs wie GRUB 2 und den Linux-Kernel prüft und lädt.
Wie ESET in einem Bericht in dieser Woche erläutert, handelt es sich bei einem UEFI-Shim um einen kleinen, minimalistischen Bootloader der ersten Stufe, den Microsoft einmal prüft und signiert. Er schafft dann einen zweiten Vertrauensanker für den restlichen, distributionsspezifischen Linux-Boot-Stack. Damit muss Microsoft nicht jeden einzelnen Linux-Bootloader signieren, während die Integrität der Secure-Boot-Vertrauenskette erhalten bleiben soll.
Die von ESET entdeckten elf Shims waren Version 0.9 oder älter und lagen damit mehrere Generationen hinter den aktuellen Fassungen zurück. Nach Angaben des Sicherheitsanbieters waren diese Shims entweder so konfiguriert, dass sie verwundbare Bootloader der zweiten Stufe starteten, etwa ältere GRUB2-Versionen mit bekannten Schwachstellen, oder ihnen fehlten Schutzmechanismen neuerer Versionen. Teilweise enthielten sie auch eigene Schwachstellen, mit denen sich Secure Boot umgehen ließ.
Gerade darin liegt laut ESET das Problem: Obwohl diese Komponenten verwundbar waren, blieben sie innerhalb der Secure-Boot-Kette weiterhin vertrauenswürdig. Ein Angreifer konnte sie deshalb nutzen, um Schutzmechanismen von Secure Boot zu umgehen, Schadcode bereits beim Systemstart auszuführen und sich dauerhaft unterhalb der Betriebssystemebene festzusetzen. ESET-Forscher Martin Smolár betonte, dass dafür keine neue Schwachstelle und keine aufwendige Ausnutzung nötig seien. Es genüge eine alte, noch nicht widerrufene Shim-Binärdatei und ein grundlegendes Verständnis ihrer Funktionsweise.
Jason Soroko, Senior Fellow bei Sectigo, beschreibt den Vorgang als Versagen dabei, Vertrauen rechtzeitig zu entziehen. Entscheidend sei nicht nur, dass elf einzelne Produkte betroffen waren, sondern dass alte Software noch lange nach ihrem faktischen Aus weiter als vertrauenswürdig behandelt wurde. Durch die Microsoft-Signatur wurden diese alten Shims laut Soroko zu portablen Boot-Komponenten, die sich in jede Maschine einbringen ließen, die weiterhin der „Microsoft Corporation UEFI CA 2011“ vertraut – unabhängig vom installierten Betriebssystem.
Microsofts Widerrufe aus dem Juni verhindern nach Sorokos Einschätzung, dass Systeme mit aktualisierten Secure-Boot-Sperrlisten den bekannten anfälligen Shims weiter vertrauen. Zugleich verweist er darauf, dass ältere, vor 2017 signierte Shims mit unvollständiger Dokumentation es erschweren könnten, jede verwundbare Komponente im Ökosystem eindeutig zu identifizieren und zu sperren.
Auch Seemant Sehgal, Gründer und CEO von BreachLock, hebt die Besonderheit der Firmware-Ebene hervor. Erfolgreiche Ausnutzung finde statt, bevor das Betriebssystem geladen werde. Werkzeuge zur Endpunkterkennung und -reaktion, EDR-Agenten und Kontrollen auf Betriebssystemebene blickten deshalb im entscheidenden Moment in die falsche Richtung. Zwar sei Microsofts Widerruf der richtige Schritt, geschützt seien aber nur Systeme, die das Update vom 9. Juni tatsächlich erhalten und eingespielt haben.
Nach Einschätzung von Sehgal dauert das Schließen solcher Lücken in der Firmware in der Praxis deutlich länger als bei Anwendungen – besonders in Unternehmensumgebungen mit Alt-Hardware, isolierten Systemen oder OT-naher Infrastruktur, in der Änderungszyklen sich über Quartale statt über Tage erstrecken. John Strand, CEO von Black Hills Information Security, sieht den eigentlichen Wert solcher Schwachstellen deshalb weniger in unmittelbarer Zerstörung als in dauerhafter Persistenz und unauffälligem Zugriff über lange Zeiträume.