[Update 19.01.2024]: Microsoft hat den Zeitplan noch einmal überarbeitet und setzt das finale Datum jetzt auf den 8. Oktober 2024. Updates danach lassen keine Maßnahmen mehr zu diese zu deaktivieren. Also bleibt es wie bisher angekündigt beim 4. Quartal.
Sieht so aus, als wenn Microsoft gezielt dieses Datum gewählt hat, weil dort dann die 24H2 erscheint / erscheinen könnte und diese dann direkt abgesichert ist, ohne dass man noch Änderungen vornehmen kann. Die dann “älteren” Versionen werden dann gleich mitgesichert.
[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 Änderung nicht mehr deaktiviert werden kann.
[Update 12.07.2023]: Microsoft hat noch einmal darauf hingewiesen, dass jetzt die zweite Stufe für die Umgehung von Secure Boot (CVE-2023-24932) durch den BlackLotus UEFI-Bootkit begonnen hat.
Wichtig ist für die Nutzer weiterhin, dass mindestens das Sicherheitsupdate Mai, oder höher (also vom gestrigen Patchday) installiert wurde. Weiterhin sollte eine ISO auf einem bootfähigen Stick oder DVD auch mindestens von Mai 2023 oder höher sein. Eigene Änderungen müssen nicht mehr durchgeführt werden. Die deutsche Microsoft-Seite wird sicherlich auch bald dahingehend aktualisiert.
[Original 10.05.2023]: Microsoft hat gestern einen sehr langen Beitrag unter der KB5025885 veröffentlicht, der sich um die Sicherheitslücke CVE-2023-24932 dreht. Dabei handelt es sich um eine Sicherheitslücke durch Umgehung der Secure Boot-Sicherheitsfunktion. Diese Schwachstelle betrifft alle Windows Versionen von 10, 11, Server und auch Linux.
Angreifer, die Zugriff auf den Rechner haben, egal ob direkt oder über Remote, kann unter Verwendung des BlackLotus UEFI-Bootkits die Secure-Boot Funktion aushebeln. Dafür ist auch ein Exploit in Umlauf. Daher ist es eine Lücke, die ernst genommen werden muss.
Microsoft hat mit dem gestrigen Patchday angefangen, diese Lücke zu schließen. “Aufgrund der für CVE-2023-24932 erforderlichen und in diesem Artikel beschriebenen Sicherheitsänderungen müssen Sperren auf unterstützte Windows-Geräte angewendet werden. Nachdem diese Sperrungen angewendet wurden, können die Geräte 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öffentlicht wurden. Dazu gehören sowohl bootfähige Medien, wie z. B. Discs, externe Laufwerke, Netzwerk-Boot-Wiederherstellung und Wiederherstellung von Images.”
Wichtig ist also, dass auch die Bootmedien auf einem Stick oder einer externen Festplatte erneuert werden und das Update vom 9. Mai oder höher enthalten. In unserer rechten Sidebar unter Download-Bereich findet ihr ja die aktuellen ISOs für Windows 10 und Windows 11. In dem Zusammenhang beschreibt Microsoft auch noch weitere Vorgehensweisen. Die lest euch bitte ganz genau durch.
Mit dabei ist auch die Anwendung der Code-Integritäts-Boot-Richtlinie. Die Code Integrity Boot Policy (SKUSiPolicy.p7b) verwendet die Code Integrity-Funktion von Windows, um zu verhindern, dass nicht vertrauenswürdige Windows-Bootmanager geladen werden, wenn Secure Boot aktiviert ist. Diese kann manuell über die Eingabeaufforderung (Administrator) durchgeführt werden. Diese kopiert die Code Integrity Boot Policy in die EFI-Partition des Geräts.
mountvol q: /S xcopy %systemroot%\System32\SecureBootUpdates\SKUSiPolicy.p7b q:\EFI\Microsoft\Boot mountvol q: /D
Durch den Befehl wird es dann scharf geschaltet Update Mai 2023:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x10 /f
Nach dem Update Juli 2023 wird dieser Befehl nötig sein.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f
Hinweis: Solange die SKUSiPolicy.p7b nicht manuell ausgeführt wurde und auch der Reg-Befehl nicht ausgeführt wurde, brauchen auch die Installationsmedien nicht aktualisiert werden. Erst wenn man beide Befehle ausführt, kommt es dazu, dass Windows nicht von Bootdateien starten kann. Das sollte man derzeit nicht machen. Microsoft bereitet die Änderung nur vor.
Microsoft wird diese Lücke in drei vier Phasen schließen
- 9.05.2023
- Updates für Windows, die am oder nach dem 9. Mai 2023 veröffentlicht werden, um die in CVE-2023-24932 beschriebenen Sicherheitslücken zu schließen. (KB5026361 Windows 10, KB5026368 Windows 11 21H2, KB5026372 Windows 11 22H2)
- Änderungen an den Windows-Boot-Komponenten.
- Zwei Sperrdateien, die manuell angewendet werden können (eine Code-Integritäts-Richtlinie und eine aktualisierte Secure Boot Disallow List (DBX)).
- 11.07.2023
- Ermöglicht eine einfachere, automatische Bereitstellung der Sperrdateien (Code Integrity Boot policy und Secure Boot disallow list (DBX)).
- Neue Ereignisprotokoll-Ereignisse werden verfügbar sein, um zu melden, ob die Bereitstellung der Sperrdateien erfolgreich war oder nicht.
- Dynamisches SafeOS-Update-Paket für Window Recovery Environment (WinRE).
- NEU 9. Januar 2024 Updates für Windows, die am oder nach dem 9. Januar 2024 veröffentlicht werden, enthalten Folgendes: Neue Abhilfemaßnahmen, um zusätzliche anfällige Bootmanager zu blockieren. Für diese neuen Abhilfemaßnahmen müssen die Medien aktualisiert werden.
- Neu Enddatum: Geändert vom 9. Juli 2024 auf den 8. Oktober 2024: Wenn die Updates für die Durchsetzungsphase veröffentlicht werden, wird folgendes hinzugefügt: Der Widerruf (Code Integrity Boot policy und Secure Boot disallow list) wird nach der Installation von Windows-Updates auf allen betroffenen Systemen automatisch durchgesetzt und kann nicht mehr deaktiviert werden.
[Update 12.05.23]: Microsoft hat jetzt noch eine weitere Anleitung freigegeben, wie man die anfälligen Bootmanager blockieren kann.
Windows 11 Tutorials und Hilfe
- In unserem Windows 11 Wiki findet ihr sehr viele hilfreiche Tipps und Tricks.
- Falls ihr Fragen habt, dann stellt diese ganz einfach bei uns im Forum.
- Installationsmedien: Aktuelle Windows 11 ISOs findet ihr hier: 21H2, 22H2 (22621), 22H2 (22624) Ansonsten immer in der rechten Sidebar.
- Windows 11 neu clean installieren Tipps und Tricks.
- Windows 11 mit lokalem Konto auch Offline installieren.
- Windows 11 Inplace Upgrade Reparatur oder Feature Update.
- Automatisch anmelden Pin entfernen Windows 11.
- Alle Beiträge zu Windows 11 im Blog findet ihr über diese Seite. Wobei auch alle anderen Artikel interessant sein können.
Tatsächlich?
Nun müssen wir alle USB-Stifte neu machen?
So wie ich das lese würde ich sagen ja aber so einen usb stick neu machen ist doch schnell und keine arbeit.
Nein es reicht doch die drei Befehle in die CMD einzugeben.
muss ich das auch machen ?
Edition Windows 11 Pro
Version 22H2
Installiert am 10.05.2023
Betriebssystembuild 22624.1755
Leistung Windows Feature Experience Pack 1000.22642.1000.0
kann man das nicht alles zusammenfassen ? Irgendwie .
Muss ich meine system os etwa neu machen ( nvme m.2 ) steige da langsam nicht mehr durch.
SORRY
Nein du hast ja ein Update dafür bekommen . Was die meinen ist wenn du es neu installieren willst dann musst du eine aktuelle ISO nehmen und da raus ein Boot Stick machen oder dir die brennen.
gepostet mit der Deskmodder.de-App für iOS
Finde ich suspekt bzw. nicht logisch.
Wenn ich von einem alten Medium neu installiere erhalte ich die Aktualisierung beim ersten Mal online gehen ebenfalls per Windowsupdate.
Ich vermute daher die USB-Stick Geschichte betrifft vorrangig die WindowsToGo Sticks.
Doch, logisch. Denke an die geleakten UEFI-Zertifikate von Intel und MSI. Die müssen zurückgezogen werden und es muss neue geben. Die Alten werden von den neuen Bootmedien nicht mehr aktzeptiert und alte Medien kennen die neuen Zertifikate nicht, beides hat zur Folge, dass von dem Medium nicht gebootet werden kann. Das gillt für Windows, Linux, usw.
Vorgehensweise: Ankündigen, dass was kommt, dabei das neue Zertifikat herausgeben, das passiert jetzt. Dann den Leuten genug Zeit geben, ihre Bootmedien umzustellen, solange werden beide Zertifikate aktzeptiert. Dann altes Zertifikat zurück ziehen, das passiert Anfang 2024.
Notbehelf: Secureboot abschalten. Ist für Privat auch nicht tragisch, es sei denn man benutzt Windows 11.
Hallo
das heist nach den Update alle Backups neu machen?Was ist mit der Wiederherstellungsumgebung von Aomei,die beim Start angezeigt wird,funktioniert die noch?
Muß man die Codes umbedingt manuell eingeben,oder kann man warten bis neue Updates kommen?
Hat das mit den Codes eingeben schon einer gemacht,vieleicht eine keine Anleitung wäre nett.
gruß Pokonon
Es wird aber wohl Microsofts Geheimnis bleiben, wie ich ein Windows-Backup von vor einem halben Jahr *heute* noch einmal erstellen soll. Einfach nur ein großer Witz.
Meine Hoffnung ist (kann das jemand definitiv bestätigen?), dass man das alles unbeachtet lassen kann, wenn man Secure Boot ausschaltet.
Für das aktuelle AOMEI-Backupper habe ich gerade einen neuen bootfähigen USB-Stick erstellt.
(Lenovo X240, i5-4.Gen., AOMEI: nicht Linux, sondern WinPE-
nicht neu runtergeladen, sondern von dem bestehenden System erstellt)
Die gute Nachricht: der Laptop bootet in das AOMEI rein.
Die schlechte Nachricht: Es dauert ein paar Minuten.
Fast dachte ich, die alte Rumpel macht jetzt wohl gar nix mehr?
Aber dann ging es doch.
Sorry, kenne mich in dem Bereich kaum aus.
Annahme, ich mache nichts ausser Windows-Zwangsupdates in physischen und virtuellen Maschinen anzuwenden.
– Gilt das nur, wenn Secure Boot eingeschaltet ist, oder habe ich auch Probleme zu erwarten, wenn das aus ist?
– Was ist mit Dual-Boot-Systemen (Grub) — werden die weiter funktionieren?
– Was ist mit Bootmedien, die unter Linux erstellt wurden — funktionieren die weiter?
Ich habe > 20 Bootmedien als USB-Sticks, .iso-Dateien und DVDs und sehr wenig Lust, die alle zu erneuern…
Ok, ich lese gerade “All Windows devices with Secure Boot protections enabled are affected by this issue”. Das beantwortet meine erste Frage.
Heisst das, ich kann die vorhandenen Boot-Medien weiterverwenden, wenn ich vor ihrem Gebrauch Secure Boot jeweils deaktiviere?
Secureboot deaktivieren, dürfte ein gangbarer Weg sein, aber nicht bei Windows 11…
Danke für die Bestätigung. Win11 habe ich nicht.
kenn mich da auch nicht aus,werde meine 5 PCs updaten,und neue Backups anlegen.Denn Rest wird Microsoft schon über die Updates hin kriegen,hoffe ich.
Eine Sache die mich hier verwirrt ist, das Microsoft sagt das man die Police Datei nicht auf Bootfähigen USB Sticks oder Festplatten kopieren soll und sie nur für Active Systeme Gedacht ist, somit wird oben im text dieser Anweisung zuwidergehandelt.
Zitat:
Important Do NOT apply the updated SKUSIPolicy.p7b file (containing the revocations) on your bootable media (ISO, USB, DVD, and so on). The SKUSIPolicy.p7b file from updates released on or after May 9, 2023 should only be applied to your Windows devices.
Leicht OT und, wie gesagt, ich kenne mich mit der Thematik nicht aus. Folgende Verständnisfrage:
– Wenn durch ein Betriebssystem-Update Bootmedien unbenutzbar werden, heisst das, dass das Betriebssystem das BOIS/UEFI manipulieren kann. Richtig?
– Wenn ich vom Betriebssystem aus das BIOS/UEFI manipulieren kann, welchen Sinn hat dann Secure Boot? Kann dann ja durch jede Schadsoftware ausgehebelt werden.
Was habe ich nicht verstanden?
Microsoft hat und wird das laufende System absichern. Dadurch kann es dann dazu kommen, dass ältere Bootmedien nicht mehr starten können.
Es ist keine Manipulation, sondern wenn du so willst eine Blockade im System gegen Angreifer. So auch Bootmedien.
Das verstehe ich schon. Aber wenn man vom Betriebssystem aus (und nicht, beispielsweise, nur durch ein UEFI-Update oder gar einen Hardware-Eingriff) festlegen kann, was booten darf und was nicht, wo bleibt denn dann der Schutz? Dann kann doch auch jede Schadsoftware, die ich mir eingefangen habe, ihrer eigenen “Betriebssystem-Variante” Bootrechte einräumen. Oder nicht?
MS legt fest was booten kann richtig. Aber um genau den Eingriff von Schadsoftware zu unterbinden.
Schon klar. Aber wenn MS das festlegen kann, dann muss das doch grundsätzlich auch ein anderer Betriebssystem-Anbieter können. Oder eben Schadsoftware, die in irgendeinem Betriebssystem läuft. Womit der Schutzmechanismus hinfällig ist.
Sehe das, wie Du. Wenn ich selbst den TüV-Stempel aufs Kennzeichen kleben kann, dann kommt mein Auto immer über den TüV. Ganz egal, wie sehr es rostet, quitscht und kracht. Und so ist das auch beim Bios.
Das Bios hat nur auf eine Art Beschreibbar zu sein. Im Flash-Modus, der kein Netzwerk erlaubt und nur physisch erreicht werden kann. Von mir aus über einen Jumper auf dem Mainboard. Wenn das OS ein Update ausspielt, dass auf Daten zugreift, die das BIOS benötigt, dann ist da bereits ein fataler Fehler im Design. Und bei Zertifikaten wäre ich da äußerst vorsichtig. Wie Du nämlich schon richtig vermutest, kann man dann auch auf SecureBoot gänzlich verzichten.
Manche Lücken gibt es nur, weil versucht wurde, Lücken zu schließen, die es vorher garnicht gab. BIOS-Viren sind meines Wissens nach gänzlich unbekannt. Das EFI-Bios sollte alles besser machen. Nun ist der Boot-Screen schon ein Einfallstor, wegen alter Bibliotheken, die befallene Bilddaten nutzen können um Schadcode ins UEFI zu bringen. Und so weiter…
BIOS-Viren sind mir seit 1995 bekannt. Schau mal bitte in eine alte C’T-Archiv-DVD Schon um 1997 gab es da mal so viele Vorfälle, dass die lokale Tageszeitung mit unserem offiziellen IT-Chef (mein Job nannte sich damals IT-Koordinator) sogar ein Interview zu dem Thema machte. Wir hatten damals PC von NEC, Compaq, Auva, DEC, DELL, Unisys, Siemens und HP sowie Server von Compaq, DEC, Siemens und ALR, aber auch noch CC und CUT. Der Hongkong-Virus hat uns allerdings nie erwischt. Erst 1999 fand der neue BIOS-Virus “Tschernobyl “weltweit hunderttausende PC als Opfer, bei uns aber keine. Unser BIOS-Passwort war für den Virus ein zu großes Problem.
*
heute ist alles anders. Auch bei meinem Acer-Notebook und bei der hiesigen AsRock-BeeBOX konnte diverse Software das UEFI-BIOS ändern. So hat sich das testweise mal installierte ChromeFlexOS bei beiden dauerhaft und bleibend gleich 2 mal in die BIOS-Bootauswahl eingetragen.
Du kannst den Mechanismus nicht missbrauchen weil da überall mit Signaturen gearbeitet wird.
Bei SecureBoot werden nur Bootloaderdateien mit Signaturen die von den im (U)EFI hinterlegten Root-Zertifikaten stammen überhaupt geladen. Und es gibt zusätzlich eine Sperrliste in der (U)EFI Variable “dbx”.
Wenn das Mai-Update installiert ist kann man diese Sperrliste massiv vergrössern (Anleitung siehe oben im Artikel), von 77 resp. 267 Einträgen auf 421 resp. 423 Einträge.
Damit sind u.a. alle Bootloaderdateien gesperrt die zum BlackLotus UEFI-Bootkit gehören.
Um das Ganze in einem Enterprise-Umfeld überwachen zu können hilft entweder Tenable Nessus oder Handarbeit mit PowerShell und einer aus dem UEFIv2-Projekt von Michael Niehaus extrahierten Funktion namens ‘Get-UEFISecureBootCerts’:
Hier meine Notizen dazu:
# verify Changes in UEFI Forbidden List
# https://www.powershellgallery.com/packages/UEFIv2
# (Get-UEFISecureBootCerts -Variable ‘dbx’).Signature.Count
# Results:
# 77 / 267 as of 2023-01 / -04
# 421 / 423 as of 2023-05
Das heisst ich prüfe aktuell ob zumindest 421 Einträge vorhanden sind.
Es können jederzeit erweiterte Sperrlisten in einem Windows Cumulative Update erscheinen, die dann wieder wie oben beschrieben einzupflegen sind – vielleicht gibt es auch irgendwann einen einfacheren Weg mit einem fixfertigen PowerShell-Cmdlet.
Den aktuellen Schwellwert für die Überwachung wird man aber jeden Monat überprüfen müssen.
(Get-UEFISecureBootCerts -Variable ‘dbx’).Signature.Count
Hi,
also ich habe meine gesamten Bootmedien einfach mal ausprobiert: starten alle ganz normal. Alle = Macrium Rescue, Win11-Install von ca. Feb., Linux-Mint 21.1 Live, uralte WIN10-Install, alle von USB-Srtick. Secure-Boot ist auf meinem PC aktiv.
Hast Du auch TPM 2.0 und das Ganze manuell aktiviert? Weil bei mir bootet gerade keine ältere ISO mehr.
Ja, TPM 2.0 (AMD)
Mainboard = Asus TUF X570 Gaming plus mit Bios 4602. Meinst Du mit manuell aktivert Secure Boot? Dann “ja”, vor ca. einer Woche wollte ich Linux Mint neu parallel zu WIN 11 installieren und bin beim booten vom LinuxUSB-Stick ständig über den Fehler “Falsche Shim-Signatur…” gestolpert. Daraufhin habe ich Secure Boot deaktivert und alles funktionierte wie gewünscht. Ich wollte aber Secure Bot aktiv haben, also wieder aktivert und im Bios (nach einigem Zögern) sämtliche Secure-Keys gelöscht – danach klappte das Booten, Installieren und Staren von Linux Mint mit Secure Boot und auch win11 startet ganz nornmal. Meine sämtlichen Windows-Partitonen sind mit Bitlocker verschlüsselt.
Nachtrag:
Ich habe nochmals alles geprüft:
Win11 Version 22621.1702, Kum-Update KB5026372 ist installiert, XCOPY SKUSiPolicy.P7b wurde ausgeführt, Datei ist im EFI-Verzeichnis \EFI\Microsoft\Boot vorhanden, TPM 2.0 ist aktiviert (fTPM), Secure-Keys im Bios sind auf Werkseinstellungen zurückgesetzt, UEFI-Boot ist aktivert.
Habe ich was übersehen? Warum kann ich immer noch von meinen alten USB-Medien booten?
In der Registry hast Du das Update aktiviert? In der Ereignisanzeige sollte unter “System” dann stehen:
EventID:1035; Quelle TPM-WMI; Das Dbx-Update für den sicheren Start wurde erfolgreich angewendet.
Dann ist das scharf gestellt. Allerdings würde ich im Moment noch davon abraten, da ich gerade nicht weiß, wo genau das Dbx-Update auf realer Hardware abgelegt wird und ob man das Rückgängig machen kann. Eventuell reicht, TPM zurückzusetzen. Wenn das aber im UEFI abgelegt wird, dann weiß ich auch nicht weiter.
Das war’s. Das habe ich übersehen…
Danke für den Hinweis. Ich warte dann doch lieber noch ab…
Hast du ein MSI Mainboard? Evtl. werden hier gerade die geklauten MSI Zertifikate für UEFI / Secureboot zurück gezogen…
Ich habe TPM 2.0 nicht aktiviert und boote nur über die SSD. Ist die Maßnahme dann für mich sinnvoll?
Ich frage ich da auch gerade, ob das ohne TPM überhaupt greift, zumal das Dbx-Update wird über die TPM-WMI installiert. Aber wo das Update landet, weiß ich nicht.
Die Abkürzungen verwirren mich. Ich glaube, ich brauche das nicht vorzunehmen.
Bei mir tauchen die Dateien auch auf allerdings habe ich SecureBoot ausgeschaltet und TPM auch.
Bei mir lassen sich die Backups damit starten die vor dem 09.05.2023 erstellt wurden.
https://ibb.co/wQTMw7C
Solange SecureBoot nicht aktiver wurde (TPM eventuell auch), dann ist das egal, ob die Dateien da liegen oder nicht. Die .bin müssen in der UEFI eingespielt werden und .p7b in den angegeben Ordner der Systempartition. Ansonsten passiert da im Moment nichts weiter.
Die Dateien gibt es bei mir auch in Windows 10 auf einem Laptop, der überhaupt kein UEFI besitz, nur klassisches BIOS. Hier sind die Dateien völlig nutzlos. Aber halt durch ein Update vorhanden.
Zitat: “Erst wenn man beide Befehle ausführt, kommt es dazu, dass Windows nicht von Bootdateien starten kann. Das sollte man derzeit nicht machen. Microsoft bereitet die Änderung nur vor.”
Ok, immer Ruhe bewahren. Ich lese mir in Ruhe alles durch, auch von Microsoft. Zur Zeit ändere ich da lieber nichts.
Also so wie ich das lese wird es im 1. Quartal 2024 durch Windows-Updates auf allen betroffenen Systemen programmatisch durchgesetzt.
Ja so habe ich das auch gelesen. Windows Update soll sich darum kümmern.
hi,
das ganze betrifft ja Windows 11 und mit Windows 10 ist 2025 Schluss
da nach, so nach Microsoft, sollte es nur noch Windows 11 geben mit aktiven SecureBoot und TPM
nun gab es wegen SecureBoot ja viele Proteste aus der Linux Gemeinschaft und Microsoft hat wohl einige Zertifikate raus gerückt
das selbe wird nun wohl jetzt passieren denn auch davon sollen einige Zertifikate betroffen sein
ich würde mich nicht wundern wenn “irgendwann” man im UEFI kein SecureBoot oder TPM hat was man “abschalten” kann
Wenn ich diese Sicherheitsfunktion aktiviere, funktionieren dann noch Linux Live USB Sticks?
Ich benutze PartedMagic.
Tja, das sind so Fragen, die auch mich umtreiben.
Was ist mit Boot-Medien, die nicht unter Windows, sondern unter Linux erstellt wurden? Wenn ich die jetzt neu erstelle, bekommen die ja keine Änderungen durch irgendein Windows-Update mit, sehen also genau gleich aus.
Was ist mit Boot-Medien, die ich aus einer VM heraus erstellt habe bzw. neu erstellen würde?
Was ist mit dem Boot-Loader eines Dual-Boot-Systems? Ist das auch ein “Boot-Medium”? Wird das System weiter funktionieren und falls nicht, was müsste ich tun? Wird der Bootloader möglicherweise schon durch das Mai-Windows-Update zerschossen?
Was muss ich z.B. bei einem Ventoy-Stick neu machen? Ventoy (unter Linux)? Oder die .iso-Dateien? Oder beides? Und wo bekomme ich ggf. aktualisierte .iso-Dateien eines Bertiebssystems her, das es seit Jahren offiziell nicht mehr gibt?
Für mich alles völlig unklar. Ich fürchte, dass der Schuss zumindest für mich nach hinten losgeht und ich künftig wegen dieser anscheinend wenig durchdachten Anpassungen ganz auf Secure Boot verzichten muss.
Für das Boot-Medium finde ich da derzeit noch keine Updates, außer für den Ordner .\sources. Das Boot-Medium wird auch nicht über das Windows Update aktualisiert. Das liefert Microsoft als Ganzes aus, aber vermutlich nur für aktuelle Windows Versionen. Aber muss man abwarten.
Ich habe das mal in der VM getestet und keine Microsoft ISOs ließen sich mehr booten, da ich keine Ahnung habe, was im Ordner EFI aktualisiert werden muss, damit das wieder funktioniert. Teil der Linux ISO funktionierten auch nicht mehr. Kommt wohl auf die Zertifikate an, mit denen die Bootdateien versehen sind. Einige gehen, andere nicht und unsignierte wohl gar nicht mehr. Die GParted ISO ließ sich auch nicht mehr starten.
Dual-Boot in der VM habe ich nicht getestet, da nicht vorhanden.
Hi @dk2000. Ich habe unter Win 10 den UEFI Secure Boot aktiviert. TPM hat mein Rechner leider nicht. In den betr. MS-Artikeln ist allerdings nirgendwo die Rede von TPM, sondern nur von Secure Boot. Da aber TPM ein zusätzliches Feature von Secure Boot ist, müsste das doch bedeuten, dass diese Sicherheitsmaßnahmen auch ohne TPM notwendig und möglich sind. Sehe ich das richtig?
Mein einziges Sicherungs- bzw. Wiederherstellungsmedium ist der erstellte USB-Stick mit dem Media Creation Tool (da alle eigenen Dateien, Reg-Einstellungen und Programm-Backups auf meiner externen Festplatte sind). Darüber hinaus habe keine weiteren bootfähigen Medien. Also bräuchte ich ja somit lediglich den Windows-Bootstick erneuern. Dabei gibt es jedoch folgendes Problem. Zitat MS:
“HINWEIS: Herunterladbare Windows-Medien (ISO-Dateien) von Microsoft, die mit den neuesten kumulativen Updates aktualisiert wurden, stehen BALD ZUR VERFÜGUNG über vertraute Kanäle wie Microsoft Softwaredownload, Visual Studio-Abonnements und das Volume Licensing Service Center. Wenn diese Medien mit Ihrem Gerät und Ihrer Konfiguration funktionieren, müssen Sie die unten angegebenen manuellen Schritte nicht ausführen, um aktualisierte startbare Medien zu erstellen.”
Jetzt frage ich mich, was “bald” bedeutet, bzw. wie ich erfahre, wann das Media Creation Tool auf die neue Sicherheitsmaßnahme angepasst wurde, damit ich einen aktualisierten Bootstick erstellen kann. Weißt Du da Näheres?
Die zwei angelegten PE-Partitionen booten und der Stick nicht.
https://s20.directupload.net/images/230511/2f5ytqu8.png
Hallo,
ich habe mountvol q: /S in der Eingabeaufforderung (Admin) ausgeführt. Die EFI System Partition wird aber nicht
angezeigt.
Woran kann das liegen?
Danke.
Sind externe Festplatten, die Backups und Dateien enthalten auch betroffen? Im Grunde muss Microsoft meine Backups bei der Verwendung von einem neuem Clonezilla-Stick wieder herstellen. Oder Microsoft muss jedem ein Zweitlaufwerk zum Auslagern bzw Umlagern bezahlen.
Aber Microsoft übt ja an meinem PC schon fleißig, indem die Festplatten mit HDD-Sperren belegen, absichtlich Bluescreens of death rein hauen, das sich bei mir das Betriebssystem und die Festplatten sperren, das ich mir dann ewig mit chkdsk und diskpart, list disk, select disk n (n bedeutet die Datenträgernummer des schreibgeschützten Laufwerks) attributes disk clear readonly wieder frei schalte und siehe da das Experiment von Windows ist gescheitert mich zum neu aufsetzen zu zwingen und der Pc läuft die nächsten paar Wochen normal weiter. Also nichts mit Linuxübergriffig die Festplattensperre im MBR ablegen mit Stoppcode.
Als ich mit Clonezillastick mein Backup wieder herstellen wollte wurde es absichtlich in Secureboot geblockt mit Ausreden, das das Passwort nicht stimmt oder es wurde nur die Hälfte der Windowsfestplatte wieder hergestellt. Als ich dann UEFI und Secureboot zur Wiederherstellung kurz deaktivierte, wurde mein Passwort richtig erkannt und mein Windows ohne Probleme vollständig wieder hergestellt. Danach habe ich es wieder zum Teil aktiviert. Das heist UEFI im BIOS an, TPM 2.0 an und Secureboot auf manuell. So kann jedes Betriebssystem selbst entscheiden mit was es bootet und es gibt dann null Bootprobleme. Die Schlüssel aus dem Bios löschen schadet auch nicht, da Linux auch schadsoftware reinschmuggeln kann nicht nur Hacker, die werden nach rücksetzen auf Werkseinstellungen eh erneuert. Man muss halt eventuell den Bootloader in der EFI auf Festplatte neu erstellen mit dem Stick. Aber da sieht man mal wie zuverlässig hier Bootängste verbreitet werden um sein verschärftes Sicherheitssystem zu rechtfertigen. Warum ziehen die solche Exploitsoftware nicht aus dem Verkehr und machen die Programmierer und die Benutzer solcher Software nicht haftbar. Warum werden hier Löcher gestopft von Schadsoftware die schon längst aus dem Verkehr gezogen werden muss und härter das ausspionieren und zerstören von geistigem und Materiellem Eigentum unter Strafe gestellt werden muss. Da versteh ich Microsoft und unsere Gesetzgeber nicht. Die Sache stinkt für mich nach Linuxbootreperaturblockade 😁 indem niemand mehr in Linux an die eigene Efi ran kommen soll, wenn Microsoft vielleicht selbst Tracksoftware rein gibt um diese zu löschen.
Jeder der hier meckert hat das Konzept von SecureBoot nicht verstanden!
In Bezug auf Backups:
Die Risiken von SecureBoot hätten den Betroffenen schon vor Einsatz der Backup-Lösung bekannt sein müssen. Sinn und Zweck von Secure-Boot ist es manipulierte oder als nicht sicher geltende Bootloader zu unterbinden.
Für diejenigen denen SecureBoot zu komplex ist: Einfach deaktivieren und eben auf die Sicherheitsfunktionalitäten verzichten.
Die Kollegen hier, die in dem Vorgehen von Microsoft ein Vendorlockin sehen, welches sich gegen die Linux-Community richtet, haben das Konzept von SecureBoot auch nicht verstanden.
Um es kurz zu fassen spare ich mir weitere Erläuterungen und zitiere Debian hinsichtlich SecureBoot und Microsoft:
“UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here”
Quelle: https://wiki.debian.org/SecureBoot
Meine Sicherungen mache ich (fast immer) mit Clonezilla-Live, mindestens schon 15 Jahre. Bei WIN10/11 stecke ich dazu erst eine externe USB-HDD an das System und dann boote ich das System kalt von einem USB-Stick erstellt mit Rufus und dem Clonezilla-Live darauf. 2 der älteren PC mit WIN10 kennen gar keine UEFI … , die vielen anderen mit WIN10 und W11 nutzen es. Und bisher haben sich UEFI, Rufus und Clonezilla auch nicht gebissen. Und bisher hat auch das Rückspielen der Datenträger oder Partitionen immer bestens funktioniert. Die aktuellen Infos verwirren mich aber. Denn immerhin mache ich DS mit mehreren Generationen und das noch aufgeteilt auf Halbjahr/Quartal/Monat/Woche. Und ich habe keinesfalls für jeden PC einen eigenen USB-Stick.
Also bitte wer von Euch hat aktuelle Praxis zu der DS mit Booten des Clonezilla vom Rufus-USB-Stick ? Danke vorab.
Noch ist der Spaß ja nicht aktiviert. Das erfolgt automatisch ers irgendwann 1Q/2024. Zu Zeit muss man das noch manuell machen. Und das hatte ich auch schon damals getestet, als der Artikel und Update herauskamen und die damals aktuelle Clonezilla ISO ließ sich nicht mit UEFI booten, so wie auch die nicht aktualisierten MVS ISOs Microsoft.
Aber allgemein mache ich mir da auch eine Sorgen. Die Boot ISOs, welche auf Linux basieren, werden nach und nach aktualisiert, so dass es dann auch in Zukunft keine Probleme in der Richtung geben dürfte. Problematisch wird es halt nur mit Boot ISOs, welche keine Aktualisierung mehr erfahren werden, weil zu alt bzw. niemand kümmern sich mehr darum.
Ich bin nach wie vor genauso verwirrt wie „Kritischer“.
Was ist mit Dual Boot (Linux/Windows) Systemen? Werden die ab 2024 weiter funktionieren, oder muss ich etwas machen? Falls ja, was?
Was ist mit Boot-Medien, die ich unter Linux erstellt habe? Werden die an einer Windows-Maschine weiter funktionieren? Falls nein, was muss ich tun?
Wäre schön, wenn da ein Kundiger etwas Licht ins Dunkel bringen könnte.
Das muss halt alles aktualisiert werden, wenn es nicht laufen sollte. Linux ist da keine Ausnahme. Du musst halt mal bei Deiner Linux Distribution nachschauen, was dort zu dem Thema steht. Die meisten Distributionen sollten die Aktualisierung aber bekommen.
Wenn du ein UEFI hast, welches die Möglichkeit bietet, die DBX wieder zurückzusetzen, kannst Du es ja mal ausprobieren. Wenn das geht, würde ich das derzeit noch nicht machen, zumal Du dass dann nicht mehr Rückgängig machen kannst. Hilft dann nur, Secure Boot zu deaktivieren.
Für die Nachwelt: Aufgrund der sehr wenigen Informationen, die ich gefunden habe (z.B. https://access.redhat.com/security/blacklotus_uefi_bootkit), würde ich vermuten, dass Linux von dem Exploit nicht direkt betroffen ist und kein Update benötigt. Woraus ich wiederum folgern würde, dass alle Linux-Medien bzw. unter Linux erstellten Medien weiter funktionieren sollten. Zu Grub habe ich gar nichts gefunden; auch hier daher nur die Vermutung, dass das weiter funktionieren sollte.
Meine Arbeitshypothese ist also: An Linux und Linux-Medien sind keine Änderungen nötig; es betrifft rein Windows Boot-Medien.
Falls jemand mit mehr Wissen diese Hypothese verifizieren oder falsifizieren könnte, wäre das natürlich nach wie vor willkommen.
Uefi und SecureBoot ist ein guter Gedanke der aber leider vom Microsoft-Team “schlecht” umgesetzt wurde, das soll kein Vorwurf an die MS-Entwickler sein, es ist ja allen bekannt wo dort bei MS genau das Problem liegt. Ich hoffe auf “Pluton” und die “next generation” von Windows-Safe-Boot 2.0
nicht böse sein.. die sicherheit ist nur vorgeschobene begründung (wie bei vorratsdatespeicherung der terrorismus), es geht darum grundsätzlich dem benutzer seine freiheiten zu nehmen.
denn wenn windows was im uefi ändern kann… kann das jede software und somit ist der sicheheitsfaktor weg.
>> denn wenn windows was im uefi ändern kann… kann das jede software und somit ist der sicheheitsfaktor weg.
Das war auch mein Gedanke, nachdem ich in diesem Kontext hier mit großen Augen erfahren musste, dass das geht. Und falls da irgendwo ein Denkfehler meinerseits ist, hat ihn mir noch niemand gezeigt.
Muss das dynamische SafeOS-Update-Paket für WinRE wieder manuell (evtl. mit Hilfe eines Scriptes) in die WinRE.wim integriert werden wie „damals“ beim Bitlocker-Problem, oder geht das diesmal automatisch?
Wenn die Wiederherstellungspartition groß genug ist, dann spielt das Windows Update die SafeOS-Updates automatisch in die WinRE.wim ein. Ist sie zu klein, wird der Vorgang nicht unterstützt.
Hallo Leidensgenosse,
darf ich fragen woher du die Infos hast?
Irgendwie finde ich da nicht wirklich etwas über die Dynamic SafeOS Updates und WinRE.
Waren es die KB5028311, KB5028312, KB5028314 richtig?
Sind die zusammen mit dem letzten monatlichen Rollup gekommen?
Danke und Grüße,
Martin
well… wat is wenn ich den krempel “secureboot” nicht nutze (abgeschaltet ist)…
es ist eh etwas suspekt das microsoft, auf ufi zugreifen kann, da dadurch der sicherheitsaspekt adodsurdum geführt wird und zum unsicherheitsfaktor wird. die sicherheitslücke ist also generell das widows zugriff hat.
da lasse ich mich auch nicht von abbringen, denn soein verhalten des betriebsystems sehe ich als versuch der beschneidung der “benutzerfreiheit”… da uefi generell (wenn man bestimmte funktionen nicht einstellen kann wie zB beim laptop) als benutzerfeindlich und generell als sicherheitslücke angesehen werden muß.
Ich habe es gerade mal getestet. Scharf geschaltet und dann den Registry-Key und die SKUSiPolicy.p7b im Boot-Ordner wieder gelöscht. Ist alles so wie vorher. Zur Not hilft auch ein BIOS-Reflash.
Wo ist der Sicherheitsgewinn?
Hallo,
In eurer Anleitung steht noch der Reg Dword Wert 0x10.
Auf der MS Seite zu Anleitung von
KB 5025885 steht ein Reg Dword Wert 0x30.
Was ist korrekt?
Danke.
Im Zweifelsfall dass, was Microsogt schreibt. Ich bin aber auch der Meinung, da stand wirklich mal 0x10. Die Siete wurde am 2023-07-11 überarbeitet. Kann also sein, dass 0x10 durch 0x30 ersetzt wurde.
Aber würde ich im moment noch nicht ausführen, da man das nicht mehr rückgängig machen kann, außer man hat ein UEFI, welches die Möglichkeit bietet, die DBX zurückzusetzen.
Ja ich werde da nichts aktivieren. Das soll Windows Update selbst machen.
Ich habe eine Frage zum DBX zurücksetzen.
DBX= UEFI Verbotsliste/Sperrliste/verbotene Signaturen???
Ich habe ein Mainboard aus dem Jahr 2018 Gigabyte Intel H370 und bei Secure Boot nachgeschaut.
Da gibt es diverse Einstellmöglichkeiten, ich liste mal auf:
Neben den Einträgen steht noch eine Zahl mit Key bezeichnet, wohl noch die Anzahl der Keys
Restore Factory Keys
Platform Key(PK) | 1 Key
Key Exchange Keys | 1 Key
Authorized Signatures | 2 Key oder Signaturen
Forbidden Signatures | 77 Key oder Signaturen
DBX zurücksetzen müsste ja der Eintrag “Forbidden Signatures” sein.
Wenn ich Forbidden Signatures auswählen kommen mehrere Möglichkeiten:
Details, Export, Update, Append, Delete.
Die DBX Sperrliste löschen wäre ja der Eintrag delete.
Ist das so richtig?
Aber ist das wirklich möglich, dass ein normaler Heimanwender die DBX Sperrliste im UEFI löschen kann?
Das wäre ja krass und würde alle Sicherheitsvorkehrungen von MS bezüglich Secure Boot zunichte machen.
Ich könnte mir vorstellen, bei neuen Boards aus 2023 gibt es so eine Möglichkeit aus Sicherheitsgründen nicht mehr.
> Forbidden Signatures | 77 Key oder Signaturen
Das sind genau die 77 Einträge die ich in meinem Beitrag weiter oben erwähne:
# verify Changes in UEFI Forbidden List
# https://www.powershellgallery.com/packages/UEFIv2
# (Get-UEFISecureBootCerts -Variable ‘dbx’).Signature.Count
# Results:
# 77 / 267 as of 2023-01 / -04
# 421 / 423 as of 2023-05
Wenn man das Cumulative Update vom Mai installiert und das Prozedere im Artikel durchspielt wird dort anstelle 77 entweder der Wert 421 oder 423 stehen.
Großen Dank, werde ich nachher ausprobieren.
Alles wird Gut, klaut euch die Datei aus EasyUEfi.
Kopiert die Dateien wo sie hingehören und gut ist.
https://i.postimg.cc/52MyV5LH/Japson.png
Iso aufmachen Iso zumachen.
UltraEditmacht das ohne den bootloader zu beschädigen.
auf der hauptseite ist das programm mittlwerweile in der v 5.2 verfügbar.
Ich hab hier noch einen etwas älteren Rechner mit Windows 10 am Start.
Dieser scheint noch den MBR Bootloader zu haben.
Muss ich da auch was updaten oder betrifft das nur UEFI und Secureboot?
Du musst nur die aktuellen Updates installieren. Mehr nicht.
da mein HP 470 G8 Win 11 fähig ist und alle Voraussetzungen erfüllt, ich aber erst mal noch bei Windows 10 bleiben möchte, Frage am Rande:
wie oft muß ich denn jetzt einen neuen Windows 10 Installation USB Stick erstellen??
Heute habe ich erst mal einen neuen erstellt. ( knapp 5GB belegt ) .
Im Prinzip reicht der. Weil bei der Installation die aktuellen Updates mitinstalliert werden.
Aber ab und an mal den Stick aktualisieren schadet nicht.
In der Registry steht bei mir folgender Eintrag (Win 10 Pro 22H2 19045.3930):
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Standard nicht gesetzt
AvailableUpdates Wert 0 (Hexadezimal)
Steht das bei Euch auch?
Bin unsicher ob ich den Wert damals aus einem falschen Verständnis gesetzt habe. Daher habe ich die Registry geprüft. Das wäre doof. Denn Ich habe kein UEFI und auch secure Boot abgeschaltet.
Danke!
Ja, sobald das Update ausgeführt wurde, wird der Wert auf 0x0 zurückgesetzt.
Wenn Du kein UEFI hast oder Secure Boot abgeschaltet, ist die Frage, ob es wirklich ausgeführt wurde. Ansonsten den Wert 0x30 noch einmal eintragen, Neustart und dann in der Ereignisanzeige nach Ereignis-ID 1035 (TPM-WMI) vorhanden ist.
Du meinst via Regedit den Wert per Doppelklick auf 0x30 ändern? Wenn ich den Text richtig verstehe wird es doch empfohlen den wert nicht zu setzen?
Kann ich denn auch alte Backups die ich mit Macrium gemacht habe vor der Änderung gemacht habe restoren? Macrium erstellt ja eh eigene Bootmedien.
oder beides:
mountvol q: /S …..
und
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f
Rückgängig kann man das nur machen, wenn man ein UEFI besitzt, dass es zulässt, die DBX wieder zu löschen oder die Datenbank auf Werkseinstellungen zurückzusetzen. Ansonsten bleibt die neue DBX im UEFI, egal was man so mit Windows noch macht.
hat man ein UEFI, Secure Boot aktiviert und das DBX-Update eingespielt, muss man zwingend auch die neue SKUSiPolicy.p7b in den o.g. Ordner kopieren, da ansonsten Windows nicht mehr booten mag.
D.h. es sieht so aus das ich das aktiviert habe? Ich bin mir ja nicht sicher ob ich das gemacht habe. War Dein Vorschlag mit dem Setzen des Registry eintrags und Reboot der Check um das zu prüfen? Oder kann ich das irgendwo prüfen?
Aber nochmal kann ich alte Backups restoren oder ist das damit auch erledigt?
Werkseinstellung? Entspricht das dem “normalen “Factory Reset”? Was, wenn ich ein Re-Flash durchführe oder ein BIOS-Downgrade durchführe? Das geht ja bei manchen Herstellern.
Das Thema ist zwar schon eine Weile her, aber ich hoffe es liest jemand.
Ab dem Juli 2023 Update ist der Befehl mit 0x30 zu verwenden. Aber bei der Anleitung KB5025885 fehlt der xcopy Befehl und nur der Befehl 0x30 ist zu verwenden. Kann es sein, dass beim Mai 2023 der Befehl mit 0x10 zusammen mit xcopy verwendet und ab Juli 2023 Update nur 0x30 ohne xcopy?
Hallo,
ich habe es ausprobiert.
Ab Juli 2023 Update ist allein nur der Reg Befehl mit 0x30 notwendig. Befehl xcopy für die skusipolicy braucht man nicht mehr.
Hallo,
Microsoft hat die Anleitungsseite zu KB5025885 (Secure Boot) komplett geändert.
Die Befehle mit AvailableUpdates 0x10 und 0x30 gibt es nicht mehr.
Ich hoffe ich habe alles soweit richtig erklärt.
Mit Befehl 0x40 wird das Zertifikat “Windows UEFI CA 2023” in der UEFI DB installiert.
Mit Befehl AvailableUpdates 0x100 wird dann ein neuer Start-Manager installiert, der mit dem Zertifikat
“Windows UEFI CA 2023” signiert ist.
Mein Mainboard vom Hersteller Gigabyte bietet die Optionen, die Datenbanken im UEFI Secure Boot
zu löschen oder zurück zusetzen.
Wenn ich die UEFI Secure Boot Datenbanken zurücksetze und das Zertifikat “Windows UEFI CA 2023”
lösche, startet dann mein Computer nicht mehr, weil ich ja den neuen Boot-Manager benutze, der mit
diesem Zertifikat signiert ist?
Zur UEFI Sperrliste DBX.
Früher wurde mit Befehl 0x30 die DBX Sperrliste mit neuen Zertifikaten/Hashes aktualisiert.
Vom Hersteller Gigabyte sind ab Werk 77 Einträge in der DBX Sperrliste vorhanden.
Nach der Aktualisierung mit 0x30 waren 421 Einträge vorhanden.
Microsoft hat ja geschrieben, dass der Platz im UEFI BIOS begrenzt ist.
Die neue Anleitung zu KB5025885 ist komplett anders.
Habe ich die neue Anleitung richtig verstanden?
Jetzt wird nicht mehr jeder einzelne Bootmanager / oder jeder einzelne Hash in die DBX Sperrliste eingetragen.
Mein Frage:
Jetzt wird mit Befehl AvailableUpdates 0x80 das Zertifikat “Windows Production CA 2011” in die DBX
Sperrliste eingetragen. Dieses Zertifikat soll jetzt alle gefährlichen Bootmanager sperren.
Ist das so richtig mit dem Zertifikat und das die DBX Sperrliste nicht mehr mit jedem Bootmanager aktualisiert wird?
Zitate von Microsoft aus KB5025885:
“HINWEIS: Anstatt die anfälligen Start-Manager vollständig aufzulisten und als nicht vertrauenswürdig einzustufen, wie es in den vorherigen Bereitstellungsphasen der Fall war, fügen wir das Signierungszertifikat “Windows Production PCA 2011″ der Secure Boot Disallow List (DBX) hinzu, um die Vertrauenswürdigkeit aller Start-Manager aufzuheben, die mit diesem Zertifikat signiert sind. Dies ist eine zuverlässigere Methode, um sicherzustellen, dass alle vorherigen Start-Manager als nicht vertrauenswürdig eingestuft werden.”
“Ein Kontrollmechanismus zum Hinzufügen von “Windows Production PCA 2011″ zum DBX für den sicheren Start, durch das alle Windows-Start-Manager blockiert werden, die mit diesem Zertifikat signiert sind.”
Danke euch.