[English]Im März 2024 wurde bekannt, dass das BlackLotus UEFI-Bootkit den Secure Boot in Windows 11 überwinden könne. Microsofts Versuch, da etwas per Update zu patchen, ist ziemlich in die Hose gegangen. Weiterhin läuft im Oktober 2026 noch ein UEFI-Zertifikat Microsofts ab, welches beim Secure Boot benutzt wird. Das dürfte nicht nur Windows-Nutzer betreffen, sondern auch Linux-Administratoren sollten sich mit dem Thema befassen. Droht uns da ein Desaster, oder juckt das bestehende Installationen nicht – das ist die Frage, die einen Blog-Leser und mich umtreibt. Ich stelle das Thema daher hier in der Leserschaft zur Diskussion, die Kommunikation seitens Microsoft ist für nicht alles andere als klar.
Anzeige
Rückblick auf das BlackLotus-/UEFI-Thema
Sicherheitsforscher von ESET haben im Frühjahr 2024 eine BlackLotus getaufte Malware in freier Wildbahn entdeckt, die sich des UEFI bemächtigt. BlackLotus ist wohl die erste UEFI-Bootkit-Malware in freier Wildbahn, die Secure Boot unter Windows 11 (und wohl auch Windows 10) aushebeln kann. Damit kann Malware dann auch den Defender oder Bitlocker und HVCI in Windows deaktivieren. Ich hatte im März 2024 im Beitrag BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11 berichtet.
Im Mai 2024 versuchte Microsoft dann diese Schwachstelle zu patchen (siehe KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)), was aber auf einen Alptraum für Administratoren hinaus lief, da viel Handarbeit erforderlich ist. Ich hatte diesen Punkt im Blog-Beitrag Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status? nochmals angesprochen. Das ist der eine Punkt.
Der zweite Punkt, den ich hier im Blog bereits angesprochen hatte, betrifft ein UEFI-Zertifikat von Microsoft, welches für den Secure Boot zuständig ist. Dieses Zertifikat wird nach 15 Jahren, am 19. Oktober 2026 definitiv ungültig. Microsoft plant, ein Windows UEFI CA 2023-Zertifikat auszurollen, um das ablaufende Zertifikat zu ersetzen. Ich hatte das im Blog-Beitrag Achtung: Microsofts UEFI Zertifikat läuft am 19. Okt. 2026 aus – Secure Boot betroffen angesprochen.
Was droht uns im Okt. 2026?
Die oben skizzierte Gemengelage ist das, was auch Blog-Leser Daniel umtreibt, und ihn bewogen hat, mir zum 19. August 2024 eine E-Mail mit dem Betreff "BlackLotus Bootloader Schwachstelle" zu schreiben. Hier sein Problem:
Anzeige
Hallo Herr Born,
wir stehen hier gerade vor einem Problem, das vermutlich viele Administratoren betrifft. Evtl. wäre das ja einen Artikel wert, um mit Hilfe der anderen Administratoren Licht ins Dunkle zu bringen.
In der Mail führt er aus, dass es um die BlackLotus Bootloader Schwachstelle (CVE-2023-24932) geht. Microsoft werde das alte UEFI-Zertifikat aus 2011 (Windows Production PCA 2011) sperren und ein neues Zertifikat aus 2023 (Windows UEFI CA 2023) hinzufügen, so der Leser. Microsoft hat dann im Support-Beitrag KB5025885 die aufwändigen, manuellen Schritte beschrieben, um die Schwachstelle abzumindern und die Änderungen zu testen. Daniel treiben nun folgende Fragen um:
- Muss das neue Zertifikat (Windows UEFI CA 2023) wirklich manuell zur UEFI-Datenbank hinzugefügt werden oder passiert das irgendwann automatisch durch ein Windows Update? Wenn ja, mit welchem Update könnte das geschehen? Natürlich kann man das Ganze auf einigen Geräten testen, aber das auf allen auszuführen, ist ohne Softwareverteilung unmöglich.
- Laut Microsofts Anleitung soll im zweiten Schritt der Boot-Manager aktualisiert werden. Muss dies auch manuell getan werden oder wird das ebenfalls per Update geschehen?
Der letzte Schritt (Sperren des 2011-Zertifikats) wird laut obiger Anleitung wohl mit einem zukünftigen Update passieren, und Administratoren müssten man dann nicht manuell tätig werden, merkte Daniel in seiner E-Mail an.
Blog-Leser Karl Wester-Ebbinghaus hat zu den sich abzeichnenden Problemen diesen Kommentar in Microsofts Techcommunity gepostet, ohne Antworten zu bekommen. Auf patchmanagement.org habe ich ebenfalls eine Diskussion gesehen, wo gefragt wurde: "Verweigern die ungepatchten Maschinen nach dem 19. Oktober 2025 das Booten, weil das Zertifikat abgelaufen ist?" Dort heißt es zusätzlich:
Verwenden Sie Linux mit SecureBoot? Dann ist dieses UEFI SecureBoot Knock-Out-Datum für Sie relevant: Samstag, 27. Juni 2026. Gleiche Geschichte: nach 15 Jahren Gültigkeit läuft diese CA aus. UEFI 3rd-Party BootLoader-Geräte benötigen ein Firmware/DB-Update, sonst wird nicht mehr gebootet
Hat mich dann etwas aufgeschreckt. In der patchmanagement.org-Liste hat dann jemand auf den Artikel Even Linux users should take a look at this Microsoft KB article vom Internet Storm Center (ISC SANS9 verwiesen, der das Thema aufgreift. Die Aussage aus diesem Artikel interpretiere ich so:
- Alle UEFI-Firmware, die vor dem Ablaufdatum 19. Oktober 2026 des Microsoft-Zertifikats signiert wurde, bleibt gültig. Es wird also an diesem Stichtag nicht zu beim Booten streikenden Systemen kommen.
- Aber Administratoren laufen in das Problem, dass sich ab diesem Stichtag keine UEFI-Firmware-Updates mehr installieren lassen, wenn das Microsoft-Zertifikat nicht aktualisiert wurde.
Microsoft habe die neuen Zertifikate zwar in sein Juli 2024-Update aufgenommen. Die Zertifikate werden jedoch nicht automatisch installiert. Nutzer müssen die Anweisungen im Microsoft-Artikel KB5025885 befolgen, um sicherzustellen, dass zukünftige Firmware-Updates installierbar sind.
Linux stützt sich auf dieselbe Zertifikatshierarchie, besagt der SANS-Beitrag . Zur Überprüfung der Boot-Integrität wird ein Linux-SHIM verwendet, das mit neuen Zertifikaten aktualisiert werden muss. Dieser Prozess ist sei bereits im Gange, und Administratoren sollten bei ihrer lokalen Linux-Distribution nach Updates suchen. Diese enthält wahrscheinlich bereits die neuen Zertifikate. Außerdem sollten Administratoren überprüfen, ob die Firmware Ihres Systems aktuell ist.
Das ist jetzt die Zusammenfassung dessen, was ich glaube in der Angelegenheit verstanden zu haben. Frage an die Leserschaft: Wurde etwas übersehen? Wie haltet ihr es mit diesem Thema?
Ähnliche Artikel:
Achtung: Microsofts UEFI Zertifikat läuft am 19. Okt. 2026 aus – Secure Boot betroffen
BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status?
Anzeige
Die Knowledge-Base hat heute endlich auf 2 PCs funktioniert.
Denke das Update am Dienstag oder eine Whitelist hat es endlich den 2 Heim-PCs mit Pro gestattet.
Keine Ahnung welchen magischen Schalter MS umgelegt hat, die Anleitung habe ich ja vor einer Weile exakt ausgeführt.
Für mich ist das Problem damit vom Tisch.
Außer das TPM+Sicherer Start in tpm.msc/msinfo32 aktiv sind gibt es ja nichts zu tun.
Dumpf reg keys setzen
2x neustart
nächsten key
2x neustart
AD NAUSEAM!
Tatsächlich bin ich gerade am Testen vom Ganzen, es funktioniert bisher, ja, aber es fühlt sich absolut undurchdacht und unausgereift an.
Für mich war zB die Anleitung um einen Win11 Installer USB Stick kompatibel zu machen irgendwie unvollständig (Win Install Media) – nach einigen Versuchen habe ich es dann doch hinbekommen.
Momentan hadere ich noch das Ganze selbst zu automatisieren oder per Handarbeit in kontrollierter Weise auszurollen. Mir kommt es schon sehr seltsam vor, dass nicht zumindest das 2023 CA Cert automatisch ausgerollt wird.
Im Endeffekt hat man aber nur die Änderungen, die uns 2026 erwartet hätten, um ein paar Jahre vorgezogen.
neben der Frage "läuft das weiter" (in unseren Tests ja …)
muss man noch folgende Dinge beachten:
– 1. hat man sein System auf das neue Zertifikat umgestellt und das alte 2011er in die Sperrliste übernommen, kann man nicht mehr von den aktuellen MS ISO's booten da dort das alte 2011 drin ist !
-2. hat man sein System auf das neue Zertifikat umgestellt und macht im BIOS ein Secure Boot Reset (rücksetzen) kann man danach nicht mehr booten, da das Neue 2023'er Zertifikat dann wieder raus ist. Hier soll man dann mit dem USB Stick und diesem rettungs Loader operieren. (noch nicht durchgespielt …)
-3. das ganze sollte man auch im WDS betrachten, auch dort gibt es das 2011 Zertifikat zum UEFI Netzwek booten !
>kann man nicht mehr von den aktuellen MS ISO's booten da dort das alte 2011 drin ist
>
Das ist falsch:
[https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/winpe-create-usb-bootable-drive?view=windows-11#update-the-windows-pe-add-on-for-the-windows-adk]
Bei unserem Test ist das Zertifikat im ADK das alte. Nach Schritt 3 geht zumindest das PE nicht auch wenn es aus dem neuen ADK gekommen ist. Leider sind die Windows ISO auch noch nicht mit dem neuen Zertifikat. somit habe ich das dann erstmal nicht weiter verfolgt das PE umzustellen weil die MS ISO eh noch alt ist. Geprüft habe ich Windows 11 23H2.8 dort gibt es im Download keine V2 mit dem neuen Zertifikat. merkwürdig
Mein EFI_EX auf einem Produktivsystem hat die 2023er, von dort sollte xcopy auch laufen um Bootmedien zu aktualisieren.
C:\Windows\Boot\EFI_EX
die
bootmgfw_EX.efi
Ist wie erwartet 2023.
Hoffe es hilft Ihnen. Die ISOs habe ich aufgegeben als Quelle zu nutzen. MS will halt nicht wie der Nutzer will.
ich bezog mich auf aktuelle MS ISOs, nicht auf selbsterstellte …
Selbst im W11 iot LTSC 2024 Ent ISO ist das 2011er noch drin.
Zertifikate machen alles sicherer, haben sie gesagt.
Heh wie undifferenziert. Die sichern so ziemlich alles ab, z.B. die Seite die Sie gerade lesen.
Secureboot abschalten und Linux nutzen scheint ja dann doch genug Leute zu filtern, als das sie klein beigeben. Die einen Frickeln, die anderen kaufen neu. Am Ende geht beides.
Jeder ist happy.
Ich denke der Schaden wird sich in Grenzen halten.
Ich fürchte mich ja mehr von dem NTP Epoch Wechsel 2036 und zwei Jahre später dem Unixtime Epoch Wechsel 2038. Da wird alles, was noch auf 32Bit läuft kaputt gehen. Von Timestamps in SQL Queries bis hin zu heute noch eingesetzten Win32 DLLs.
Da fällt mir ein… die bescheidene Vectorsoft Concept16 Middleware mit Windows 3.1ish Icons, die aktuell bei einem Kunden für ein ERP deployed wird läuft in 32Bit. Schnell mal schauen, wann ich in Rente bin…
Du weist, dass das "mit der Rente" so eine Sache ist … ;-)
Hängt aber viel davon ab ob man "Lohnsklave" oder sein eigener Herr ist ;-P
Ich kenne wenige Lohnsklaven die länger machen als notwendig (wenn sie das Rentenalter überhaupt erleben); zu Rente aufstocken ist da wieder was anderes.
Wer selbst sein Herr ist und gar ne eigene Firma hat macht schon mal länger…
Nur bleibt die Frage ob man von den eigenen "Dämonen" aufgefressen wird.
Aus meiner Sicht wäre die einzige Nachhaltige saubere Lösung ein BIOS update, welches das neue Zertifikat fix integriert.
Unbedarfter privater Nutzer macht einen BIOS reset und dann wars das. Das kanns doch nicht sein!
Ich werde die nächsten 1-2 Monate mich intensiv mit dem Thema auseinander setzen, da es bei uns knapp 8000 Geräte betreffen wird, wobei eine große Menga davon via BIOS für mich nicht erreichbar sind.
Ich seh mich schon ein WinPE basteln, das als erstes mal das Zertifikat ins BIOS schießt, aber mit automatisch ist dann garantiert nicht mehr viel…
Ich nenn das Ganze eine geplante Vernichtung gut funktionierender Hardware.
Ich frage mich nur wo die CO2 Kleber da sind, denn da geht es wirklich um Masse….
Ich hoffe hier auf die OEMs (HP/Lenovo/Dell) die in einem zukünftigen Bios-Update das Zertifikat dann drinnen haben, verteilt wird dies eh über die optionalen Windowsupdates.
Der Ablauf ist so:
1. "Windows UEFI CA 2023" in die DB des BIOS
2. Neuer Bootloader (mit dem neuen Zertifikat signiert)
3. Das alte Zertifikat "Microsoft Windows Production PCA 2011" in die DBX des BIOS
Meiner Meinung nach wird das alles automatisch durch die Windows-Updates erleditgt.
Die Fragen sind..
a) Was wird wann genau gemacht?
und
b) Wie stellt man sicher, dass es erfoglreich war? Ggf. mit "UEFIv2" auslesen?!
Ich haben heute einmal auf einem Client (23H2 22631.4112) nachgesehen
1. DB/Bios: kein 2023
2. Bootloader: 2011
3. DBX: auch nichts neues
Automatisch scheint mit KB5041587 noch nichts zu kommen.
Erst kommt noch das KEK 2023 CA. Die Umsetzung erfolgt nicht automatisch. An der Timeline wird aber noch gearbeitet. Das DB-Update vom Mai 2023 gibt es nicht mehr.
Aus verlässlicher Quelle weiß ich, dass MS selbst noch in der "Findungsphase" ist. Derzeit weiß noch niemand, ob das auf mehrere Updates aufgeteilt wird oder das Doing an den Admins hängenbleibt. Genauso gibt es noch keine aktualisierten Bootimages für Enterpriseumgebungen, die man benötigt, um das Szenario auf allen Hardwareplattformen zu testen. Die Rechner können danach nicht mehr PXE deployed werden.
Ein weiterer Sachverhalt ist die benötigte Anzahl an Reboots. Führt man alle Schritte durch sind es 8 (in Worten acht) Reboots. Wir haben das hier mal mit einer ConfigManager Tasksequenz getestet. Das funktioniert soweit, aber wie verkauft man einem Anwender 8 Reboots ohne dass nach dem 5. Reboot der Rechner hart ausgeschaltet wird?