{"id":177993,"date":"2025-01-30T06:24:29","date_gmt":"2025-01-30T05:24:29","guid":{"rendered":"https:\/\/www.deskmodder.de\/blog\/?p=177993"},"modified":"2025-02-04T12:52:32","modified_gmt":"2025-02-04T11:52:32","slug":"cve-2023-24932-windows-bootmedium-sollte-aktualisiert-werden-wegen-secure-boot-aenderungen","status":"publish","type":"post","link":"https:\/\/www.deskmodder.de\/blog\/2025\/01\/30\/cve-2023-24932-windows-bootmedium-sollte-aktualisiert-werden-wegen-secure-boot-aenderungen\/","title":{"rendered":"CVE-2023-24932: Windows Bootmedium sollte aktualisiert werden wegen Secure Boot-\u00c4nderungen [5. Update]"},"content":{"rendered":"

[Update 30.01.2025]:<\/strong> Kurzer Hinweis. Die Bereitstellungsphase wurde im Juli 2024 abgeschlossen und 6 Monate sp\u00e4ter sollte dann die Durchsetzungsphase beginnen. Diese Durchsetzungsphase hat Microsoft jetzt auf nicht vor Januar 2026<\/strong> gesetzt.<\/p>\n

Damit wird die Umsetzung, das „Windows Production PCA 2011“-Zertifikat zu blockieren um ein weiteres Jahr verschoben. Sicherlich eine gute Entscheidung von Microsoft, auch wenn es sich hier um ein Sicherheitsproblem handelt. Denn die Installationsmedien, die ben\u00f6tigt werden m\u00fcssen erst noch nach und nach freigegeben werden. Der Zeitplan wurde unten aktualisiert.<\/p>\n

F\u00fcr den Abschluss der Bereitstellungsphase hat Microsoft diesen Hinweis ver\u00f6ffentlicht: „Die Bereitstellungsphase ist jetzt in Kraft und in der aktualisierten KB5025885 dokumentiert. Das Windows-Sicherheitsupdate vom Juli 2024 f\u00fcgt Unterst\u00fctzung f\u00fcr Secure Version Number (SVN) hinzu, um \u00e4ltere Boot-Manager zu blockieren…Der neue Boot-Manager, der mit dem Juli-Update bereitgestellt wird, verf\u00fcgt \u00fcber eine neue Funktion f\u00fcr den automatischen Widerruf. Wenn der Bootmanager ausgef\u00fchrt wird, f\u00fchrt er eine Selbstpr\u00fcfung durch, indem er die in der Firmware gespeicherte SVN mit der im Bootmanager integrierten SVN vergleicht.“<\/em><\/p>\n

[Update 19.01.2024]: Microsoft hat den Zeitplan noch einmal \u00fcberarbeitet und setzt das finale Datum jetzt auf den 8. Oktober 2024. Updates danach lassen keine Ma\u00dfnahmen mehr zu diese zu deaktivieren. Also bleibt es wie bisher angek\u00fcndigt beim 4. Quartal.<\/p>\n

Sieht so aus, als wenn Microsoft gezielt dieses Datum gew\u00e4hlt hat, weil dort dann die 24H2 erscheint \/ erscheinen k\u00f6nnte und diese dann direkt abgesichert ist, ohne dass man noch \u00c4nderungen vornehmen kann. Die dann „\u00e4lteren“ Versionen werden dann gleich mitgesichert.<\/p>\n

[Update 21.11.2023] Nur zur Info: Vor einiger Zeit hat Microsoft den Zeitplan konkretisiert und noch eine vierte Stufe integriert. Anstatt 4. Quartal wird jetzt der 9. Juli 2024 als finales Datum angegeben, nachdem die \u00c4nderung nicht mehr deaktiviert werden kann.<\/p>\n

[Update 12.07.2023]: Microsoft hat noch einmal darauf hingewiesen, dass jetzt die zweite Stufe f\u00fcr die Umgehung von Secure Boot (CVE-2023-24932) durch den BlackLotus UEFI-Bootkit begonnen hat.<\/p>\n

Wichtig ist f\u00fcr die Nutzer weiterhin, dass mindestens das Sicherheitsupdate Mai, oder h\u00f6her (also vom gestrigen Patchday) installiert wurde. Weiterhin sollte eine ISO auf einem bootf\u00e4higen Stick oder DVD auch mindestens von Mai 2023 oder h\u00f6her sein. Eigene \u00c4nderungen m\u00fcssen nicht mehr durchgef\u00fchrt werden. Die deutsche Microsoft-Seite<\/a> wird sicherlich auch bald dahingehend aktualisiert.<\/p>\n

[Original 10.05.2023]: Microsoft hat gestern einen sehr langen Beitrag unter der KB5025885 ver\u00f6ffentlicht, der sich um die Sicherheitsl\u00fccke CVE-2023-24932 dreht. Dabei handelt es sich um eine Sicherheitsl\u00fccke durch Umgehung der Secure Boot-Sicherheitsfunktion. Diese Schwachstelle betrifft alle Windows Versionen von 10, 11, Server und auch Linux.<\/p>\n

\"http:\/\/www.stockvault.net\/photo\/174251\/cyber-security-concept\"<\/a><\/p>\n

Angreifer, die Zugriff auf den Rechner haben, egal ob direkt oder \u00fcber Remote, kann unter Verwendung des BlackLotus UEFI-Bootkits die Secure-Boot Funktion aushebeln. Daf\u00fcr ist auch ein Exploit in Umlauf. Daher ist es eine L\u00fccke, die ernst genommen werden muss.<\/p>\n

Microsoft hat mit dem gestrigen Patchday angefangen, diese L\u00fccke zu schlie\u00dfen. „Aufgrund der f\u00fcr CVE-2023-24932<\/a> erforderlichen und in diesem Artikel beschriebenen Sicherheits\u00e4nderungen m\u00fcssen Sperren auf unterst\u00fctzte Windows-Ger\u00e4te angewendet werden. Nachdem diese Sperrungen angewendet wurden, k\u00f6nnen die Ger\u00e4te mithilfe von Wiederherstellungs- oder Installationsmedien absichtlich nicht mehr gestartet werden, es sei denn, diese Medien wurden mit den Sicherheitsupdates aktualisiert, die am oder nach dem 9. Mai 2023 ver\u00f6ffentlicht wurden. Dazu geh\u00f6ren sowohl bootf\u00e4hige Medien, wie z.\u00a0B. Discs, externe Laufwerke, Netzwerk-Boot-Wiederherstellung und Wiederherstellung von Images.“<\/em><\/p>\n

Wichtig ist also, dass auch die Bootmedien auf einem Stick oder einer externen Festplatte erneuert werden und das Update vom 9. Mai oder h\u00f6her enthalten. In unserer rechten Sidebar unter Download-Bereich<\/a> findet ihr ja die aktuellen ISOs f\u00fcr Windows 10 und Windows 11. In dem Zusammenhang beschreibt Microsoft auch noch weitere Vorgehensweisen. Die lest euch bitte ganz genau durch<\/a><\/strong>.<\/p>\n

Mit dabei ist auch die Anwendung der Code-Integrit\u00e4ts-Boot-Richtlinie<\/a>. Die Code Integrity Boot Policy (SKUSiPolicy.p7b) verwendet die Code Integrity-Funktion von Windows, um zu verhindern, dass nicht vertrauensw\u00fcrdige Windows-Bootmanager geladen werden, wenn Secure Boot aktiviert ist. Diese kann manuell \u00fcber die Eingabeaufforderung (Administrator) durchgef\u00fchrt werden. Diese kopiert die Code Integrity Boot Policy in die EFI-Partition des Ger\u00e4ts.<\/p>\n

mountvol q: \/S \nxcopy %systemroot%\\System32\\SecureBootUpdates\\SKUSiPolicy.p7b q:\\EFI\\Microsoft\\Boot \nmountvol q: \/D<\/pre>\n
Durch den Befehl wird es dann scharf geschaltet Update Mai 2023:<\/p>\n
reg add HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Secureboot \/v AvailableUpdates \/t REG_DWORD \/d 0x10 \/f<\/pre>\n
Nach dem Update Juli 2023 wird dieser Befehl n\u00f6tig sein.<\/p>\n
reg add HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Secureboot \/v AvailableUpdates \/t REG_DWORD \/d 0x40 \/f<\/pre>\n
Hinweis:<\/strong> Solange die SKUSiPolicy.p7b nicht manuell ausgef\u00fchrt wurde und auch der Reg-Befehl nicht ausgef\u00fchrt wurde, brauchen auch die Installationsmedien nicht aktualisiert werden. Erst wenn man beide Befehle ausf\u00fchrt, kommt es dazu, dass Windows nicht von Bootdateien starten kann. Das sollte man derzeit nicht machen. Microsoft bereitet die \u00c4nderung nur vor.<\/p>\n
Test der Zertifikate<\/h3>\n
Um zu testen, welche Zertifikate derzeit von Windows genutzt werden, kann man PowerShell (Administrator) nutzen.<\/p>\n
Altes Zertifikat:<\/p>\n
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows Production PCA 2011'<\/pre>\n
Neues Zertifikat:<\/p>\n
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'<\/pre>\n
Wird f\u00fcr beide True ausgegeben, dann kann noch von alten Bootmedien gebootet werden. Steht nur Windows UEFI CA 2023 auf True, dann geht es nur ohne SecureBoot, oder eben mit neuen Bootmedien.<\/p>\n
Microsoft wird diese L\u00fccke in drei<\/del> f\u00fcnf Phasen schlie\u00dfen<\/h3>\n