Ich hoffe Ihr habt in Zukunft Glück und euer Windows Bootvorgang startet wie gewohnt und Ihr erlebt keine böse Überraschung. Aber nun zur Erklärung. Eigentlich sollte Secure Boot, so wie der Name es verspricht, eine sichere Bootumgebung sein und nein, ist es nicht. Warum? Natürlich weil sich die Welt weiterentwickelt und es ausgefeilte Tools gibt welche die so sichere Bootumgebung nicht mehr ganz so sicher machen. Eigentlich sind es eher Konstruktionsfehler welche so nicht absehbar waren oder man wusste davon und hat sie dann eher ignoriert.
Was hat nun Microsoft damit zu tun? Der Bootvorgang ist doch eher unabhängig von Microsoft, da ja schließlich damit auch andere Betriebssystemumgebungen gestartet werden können? Stimmt, nur hat dies einen kleinen Haken, da für den Bootvorgang i.d.R. Microsoft Zertifikate genutzt werden. Dies schauen wir uns später an. Kommen wir nun zu den Details und schauen uns die Grundlagen des Startvorgangs an.
Grob unterschieden wird zwischen einen normalen Bootvorgang mit dem "legacy BIOS" und UEFI. Das CSM - Compatibility Support Module lassen wir mal aussen vor.
Ein Bootvorhang mit dem Legacy BIOS läuft nach dem Muster ab, das mit dem Einschalten des Rechners das BIOS gestartet wird, welches im Mainboard implementiert ist und somit Einstellungen am Rechner vorgenommen werden können. Dieses BIOS ist also Hardwareabhängig vom jeweiligen Motherboard und natürlich gibt es auch verschiedene Hersteller von diesem "rudimentären" Software. Das BIOS startet ein Bootloader und der Loader startet dann das entsprechende Betriebssystem.
Bei einem UEFI Bootvorgang läuft dies ähnlich ab. Nach dem Startvorgang vom Rechner wird das BIOS inistialisiert und danach startet UEFI als Firmware und übernimmt die weiteren Prozesse, also auch den Bootvorgang.
Beim UEFI Secure Bootvorgang wird zudem bei Windows eine bestimmte Datei geladen, welche abhängig von der jeweilgen Architektur ist. Hier gehen wir einfachhalber auf die gebräuchlichste 64-Bit Variante der Intel Architektur ein, also die bootx64.efi ein, welcher der Bootloader ist. Von dieser Datei wird dann das klassische 64-Bit Windows gestartet. Diese Datei liegt auf einer separaten Bootpartition (ESP) im Ordner EFI/Boot, welche für den "normalen" Anwender nicht sichtbar ist. Dort werden die grundlegenden Aufgaben wie das Bootmenü anzeigen oder die initiale Bitlocker-Entsperrung vorgenommen um danach den Windows-Loader zu starten, welcher dann das Betriebssystem initialisiert.
Klingt auch recht plausibel, jedoch wo genau soll da ein "sicherer" Bootvorgang sein?
Jetzt wird es spannend und interessant.
Um sicherzustellen das der BIOS Code nicht manipuliert wurde und auch der Bootloader vertrauenswürdig ist und nicht in irgendeiner Form verändert wurde, kommen dafür Zertifikate und digitale Signaturen zum Einsatz. D.h. das die Dateien welche für den Bootvorgang digital signiert sind und nicht manipuliert werden können. Die Zertifikate stellen sicher das die Signaturen auch von einem vertrauenswürdigen Anbieter kommen. Natürlich müssen diese Signaturen auch überprüft werden, ansonsten würde das wenig Sinn machen. Jetzt kommt Microsoft ins Spiel, denn im Flash Speicher von den gängigigen BIOS Distributionen wird ein Zertifikat in der BIOS-DB hinterlegt, welches die Signaturen prüft und tadaaa ... es ist ein Microsoft Zertifikat. Sollten zbsp. Updates am BIOS vorgenommen werden, werden diese mit einem Microsoft Zertifikat hinterlegt um die Signatur zu überprüfen. Dies funktioniert auch ganz anständig bei Viren, Trojaner und anderes Zeugs was wir nicht haben wollen.
Gehen wir aber davon aus, das es eine Sicherheitslücke im Bootloader gibt, dann sieht die Welt etwas anders aus. Dem Bootloader wurde ja bereits ein vertrauenswürdiges Zertifikat hinterlegt und hat dementsprechend eine gültige Signatur. Also was machen sprach Zeus? Klar kann man das Zertifikat zurückrufen, blöd nur das dies dann auch alle anderen Bootloader betreffen würde und das wäre vermutlich nicht wirklich hilfreich oder um es anders auszudrücken, das wäre ein super GAU. Aber dafür gibt es ja Microsoft Updates, welche vertrauensvoll die Zertifikate pflegen und das ganz bestimmt ohne Probleme? Dies wird in der Tat durchgeführt nur das mit "ohne Probleme" funktioniert manchmal nicht ganz so gut. Zum einem werden nur die Betriebssysteme geupdatet, welche noch supportet sind und im Privatbereich sind es Windows 10 / 11 Versionen, welche nach 2022 erschienen sind. Und zum anderen kann man ein Problem beim Update einer "alten" Windows Version bekommen, wenn man zbsp.von einer DVD installiert, bei welchem der Bootloader bereits nicht mehr vertrauenswürdig ist.
Aber wie erkennt man denn jetzt welcher Bootloader nicht mehr vertrauenswürdig ist?
In jedem Motherboard gibt es einen sogenannten Flash Speicher, welcher dafür zuständig ist, u.a. Prüfsummen zu speichern. Nur macht es keinen Sinn alle Prüfsummen von jedem x-beliebigen Bootloader zu speichern. Dort geht man den Weg, nur die Prüfsummen von nicht vertrauenswürdigen Signaturen zu speichern und dies geschieht in einer DBX Schlüssel-Datenbank, wo die Prüfsummen der widerrufene Signaturen aufbewahrt und aktualisiert werden.
Klingt doch super, oder?
Eigentlich schon wenn da seid 2020 nicht das kleine Problemchen wäre, das diese Schlüsseldatenbank seid Bekanntwerden der Sicherheitslücke "Boothole" im Juli 2020 keine neuen Sperrlisten mehr aufnehmen konnte, da diese auf 30kb begrenzt ist und Microsoft in diesem Zusammenhang auch keine neuen Signaturen für UEFI Secure Boot herausgab. (https://www.heise.de/news/UEFI-Secure-Boot-Microsoft-legt-Signaturvergabe-offenbar-bis-2021-auf-Eis-4950810.html)
Kann es schlimmer werden?
Na aber sicher doch. Dank des "UEFI-Bootkit BlackLotus" welches zum ersten mal August 2022 gesichtet wurde, war es möglich das Secure UEFI BIOS zu umgehen aufgrund der Tatsache, das diese "ungültigen" Signaturen nicht in die Sperrliste aufgenommen wurden. Dramatisch hingegen ist dabei die Tatsache, das Microsoft einen Patch herausgebracht hat, welcher jedoch inaktiv war. Kleiner Fun Fakt: das Rootkit wurde auch auf Github, einer Microsoft Plattform veröffentlicht. (https://www.golem.de/news/viele-windows-systeme-ungeschuetzt-uefi-bootkit-blacklotus-auf-github-aufgetaucht-2307-175866.html)
Auch weniger lustig, das natürlich ältere Versionen von Windows nicht gepatcht werden und daher immer noch anfällig sind, wobei hingegen noch ältere Bootloader wie bei Windows 8 und die darunterliegenden Versionen nicht betroffen sind, da sie zu diesem Zeitpunkt nicht zwingend Secure Boot unterstützt haben, jedoch darf dann eigentlich jeder Bootloader starten.
Also muss eine Lösung her, nur wie soll diese aussehen?
Die Lösung von Microsoft heißt: Code-Integritäts-Boot-Richtlinie. Microsoft hat bereits damit begonnen diese Strategie mit dem dem Windows Security Update vom 11.Juli 2023 umzusetzen. Dazu wird eine spezielle Datei benötigt, welche die Angaben der blockierten Bootlader enthält. Die Datei welche zwingend mit den Namen SkuSiPolicy.p7b benannt wurde wird unter der Bootpartition unter \EFI\Microsoft\Boot abgelegt und enthält nun die Prüfsummen und Versionsinformationen von den zu blockierenden Bootloadern. Dies ist jedoch nur die halbe Miete, denn woher soll das BIOS wissen das es das UEFI mit dieser Datei starten soll? Also kommen Variablen ins Spiel, in welchen der Speicherort, der Name und die Versionsnummer hinterlegt sind. Diese Varaiablen werden durch Windows verwaltet und verändert das Bootverhalten, was eine gravierende Änderung mit sich bringt, da dies nicht mehr das bekannte Verhalten beim Systemstart sein wird, sondern ein zusätzlicher Schritt hinzukommt.
Grundlegend wird nach einem Systemstart das Bios aufgerufen und dies prüft ob der Bootloader signiert ist und überprüft die Prüfsumme in der DBX-Datenbank. Danach übernimmt der Bootloader und wird weitergereicht an den Windowsloader welcher nun das Betriebssystem startet und anhand der Datei SiPolicy.p7b überprüft wird, ob der Bootloader hätte gestartet werden dürfen. Genau, die Prüfung nach der Prüfung.
Was wenn der Bootloader hätte nicht gestartet werden dürfen?
Tja, dann bekommen wir sehr wahrscheinlich einen Bluescreen mit einer Meldung das die Signatur nicht überprüft werden konnte, woran man erkennen kann, das dies bereits schon über die Secure Boot Fehlermeldung hinaus geht und dies nicht vom Secure UEFI kommen kann. Nur hilft uns das nicht wirklich weiter.
Microsoft hat die Code-Integritäts-Boot-Richtlinie bereits seid 2023 implementiert und wird mit jedem darauffolgenden kumulativen Update mitgeliefert. Diese Richtlinie bzw. das Update KB5025885 ist jedoch noch nicht aktiv. Zum Glück.
Nur wenn man jedoch sehr risikofreudig ist, dann kann man dies bei einem bereits aktualisierten Windows mit Hilfe eines Registryschlüssels spontan aktivieren.
Und wenn man nicht so risikofreudig ist, dann wird freundlicherweise Microsoft dies spätestens ab 08. Oktober 2024 übernehmen, da dies dann zwangsweise mit der "Obligatorischen Erzwingungsmaßname" einhergeht.
Microsoft hat dazu einen Artikel zu Verfügung gestellt, welchen man sich unbedingt anschauen sollte: (https://support.microsoft.com/de-de/topic/kb5025885-verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-secure-boot-%C3%A4nderungen-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d)
Ja warum sollte man dies nicht spontan aktivieren? Das klingt doch echt gut.
Stimmt, wenn man im Vorfeld weiß welche Bootloader gesperrt werden, dann schon. Nur scheint dies jedoch ein Würfelspiel zu sein welche gesperrten Loader in der DBX (ja, auch in der DBX Datenbank werden weiterhin Prüfsummen abgelegt) und welche Prüfsummen in die SkuSiPolicy.p7b abgelegt werden. Zudem ist auch nicht sichergestellt, das dieses Update auch auf jedem Rechner lauffähig ist und gesetzt den fall das dieses Update eingepflegt wird und funktioniert, kann es durchaus sein, das u.a. ältere Versionen nicht mehr funktionieren.
Was auf jeden Fall nicht schaden kann, ein Backup von seinem System anzufertigen. Dabei ist jedoch zu bedenken, das es u.U. schwierig sein kann, nach einem geupdaten System mit dem aktualisierten Bootvorgang ein älteres Backup ohne den Security Fix einzupflegen (zbsp. Systemstatebackup).
Und zum Abschluß noch einige Hinweise von Microsoft, welche auch im o.g. Artikel zu finden sind:
HINWEIS: Sicherungen von Windows, die vor der Installation von Updates erstellt wurden, die am oder nach dem 9. Mai 2023 veröffentlicht wurden. Diese können nicht direkt zur Wiederherstellung Ihrer Windows-Installation verwendet werden, nachdem die Sperrungen auf Ihrem Gerät aktiviert wurden.
HINWEIS: Die Funktion „Wiederherstellungslaufwerk erstellen“ wird in den am oder nach dem 9. Mai 2023 veröffentlichten Updates nicht unterstützt und kann nicht zur Wiederherstellung von Geräten mit aktivierter Sperrung verwendet werden. Wir arbeiten an einer Lösung und werden in einer zukünftigen Veröffentlichung ein Update bereitstellen.
Wissenswertes über den Artikel:
https://www.pcwelt.de/article/1148575/uefi__so_funktioniert_der_bios-nachfolger-hardware-schnittstelle.html
https://www.borncity.com/blog/2021/01/30/windows-10-insides-zum-secure-boot-auf-uefi-systemen/