[English]Noch ein Nachtrag zum Blog-Beitrag Windows 10: "Schlagloch" Win RE-Patch zum Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099. Zum Schließen der Schwachstelle (CVE-2022-41099), die eine Umgehung der Bitlocker-Verschlüsselung in Windows ermöglicht, muss die Win RE-Umgebung der Clients (Windows 10) manuell aktualisiert werden. Dabei gibt es aber Probleme, wie mir ein Blog-Leser mitteilte. Zudem bin ich auf ein Script gestoßen, welches das Patchen der WinRE-Umgebung automatisieren soll.
Anzeige
Worum geht es?
Ich hatte es im Blog-Beitrag Windows 10: "Schlagloch" Win RE-Patch zum Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099 bereits aufgegriffen. Seit November 2022 ist bekannt, dass es eine Bitlocker-Bypass-Schwachstelle CVE-2022-41099 im Windows Recovery Environment (WinRE) gibt. Microsoft hatte das Thema im Januar 2023 nochmals im Sicherheitsupdate KB5022282 mit folgendem Text aufgegriffen.
Important: For Windows Recovery Environment (WinRE) devices, see the Special instructions for Windows Recovery Environment (WinRE) devices in the How to get this update section to address security vulnerabilities in CVE-2022-41099.
Das betreffende Update muss manuell installiert werden – was einerseits viele Nutzer überfordern dürfte. Andererseits berichten Leser von Problemen beim Update.
Leserhinweise auf Neuerungen
Blog-Leser Markus K. hat mich die nochmals per Mail kontaktiert, und wies darauf hin, dass Microsoft seine FAQ zur BitLocker Security Feature Bypass Vulnerability CVE-2022-41099 aktualisiert habe. Es ist folgende wichtige Ergänzung hinzu gekommen.
Are there additional steps that I need to take to be protected from this vulnerability?
Yes. You must apply the applicable Windows security update to your Windows Recovery Environment (WinRE). For more information about how to apply the WinRE update, see Add an update package to Windows RE.
IMPORTANT: End users and enterprises who are updating Windows devices which are already deployed in their environment can instead use the latest Windows Safe OS Dynamic Updates to update WinRE when the partition is too small to install the full Windows update. You can download the latest Windows Safe OS Dynamic Update from the Microsoft Update Catalog.
In der als wichtig gekennzeichneten Ergänzung schreibt Microsoft, dass ein dynamisches Update im Microsoft Update Catalog zum Download bereitsteht. Dieses muss im Prinzip nur heruntergeladen werden und sollte sich dann installieren lassen. Dazu merkte Markus K. in seinen letzten Mails folgendes an:
Anzeige
Soweit so nett.
Habe am WSUS das Product hinzugefügt, gesynct, alles was nicht benötigt wird declined und den rest approved.
Nun habe ich ein Windows 10 21H2 mit ungepatchtem WinRE und KB5021043 wird als "not applicable" an den WSUS reported.
Ich behaupte mal, dass das ganze nicht so gut funktioniert, es sei denn ich habe was falsch gemacht.
In einer ergänzenden Mail schrieb Markus K. dann noch:
Ich habe gestern noch versucht KB5021043 in ein gemountetes WinRE image einzuspielen, was angeblich auch geklappt hat. Nur hat sich wenig geändert:
Version : 10.0.19041
ServicePack Build : 1
ServicePack Level : 0Entweder funktionieren die Safe OS Dynamic Updates nicht so recht, oder ich mache etwas falsch. Wäre jedenfalls interessant für mich ob damit jemand Erfolg hat (im Idealfall Windows 10 21H2 damit der Vergleich auch passt).
Diese Frage gebe ich an die Leserschaft weiter. Vielleicht hat jemand mehr Erfolg.
Update-Scripte
Im englischsprachigen Blog hat sich Mark Berry mit einem Kommentar gemeldet und weist darauf hin, dass Susan Bradley AskWoody-Newsletter von im Januar 2023 auf die GitHub-Seite Update Windows RE – CVE-2022-4109 von Brandon Halsey verweist. Dieser hat ein Script zur Installation veröffentlicht und schreibt:
Update Windows RE – CVE-2022-41099
Script to update Windows Recovery Environment to patch against CVE-2022-41099. The script pulls the January CU for each build, mounts WinRE, updates it, saves WinRE, then verifies the build number matches what the January CU is. Win10-21H1's last CU was Dec 2022 so that version pulls the Dec 22 CU
Supported OS and Builds: Windows 11 (22H2 & 21H2) & Windows 10 (22H2, 21H2, 21H1, & 20H2). Unsure if LTSC will work.
Built with help from comments of reddit users /u/shiz0_ and /u/DrunkMAdmin and u/JoseEspitia_com
No warranty implied. Do your own testing prior to running.
Vielleicht hilft das Script Leuten die Probleme haben. Beachtet aber, dass der Einsatz auf eigenes Risiko erfolgt und das Ganze vorher zu testen ist.
Zudem hat Martin Himken sich mit diesem Kommentar zum Blog-Beitrag Windows 10: "Schlagloch" Win RE-Patch zum Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099 gemeldet:
Guten Morgen,
ich hätte da vielleicht was passendes:
Martin verweist in seinem Tweet auf die seinen Beitrag Modify WinRE (Patches, Drivers and CVE-2022-41099), wo er Details zu seiner Lösung (in Englisch) verrät. Auf GitHub hat er dann noch den Beitrag WinRE-Customization mit weiteren Hinweisen veröffentlicht. In obigem Kommentar schrieb Martin aber noch:
Ich möchte allerdings anmerken, dass aktuell lt. Microsoft Ticket _nicht_ das CU angewendet werden soll. Wir haben das mit dynamischen Updates (wie durch MS empfohlen) getestet, kommen allerdings zu dem Schluss, dass der Payload wahrscheinlich nicht ausreicht. Auch die Versionsnummer ändert sich dadurch nicht. Das CU anzuwenden ändert auch passend die Versionsnummer.
Also letztendlich die Beobachtung von Markus K. weiter oben. Aktuell interpretiere ich die Hinweise von Markus K. und Martin H. so, dass das dynamische Update wahrscheinlich nicht funktioniert. Aber andererseits rät Microsoft davon ab, das kumulative Update (CU) mit der geänderten PE anzuwenden. Vielleicht helfen die Hinweise hier im Beitrag einigen Administratoren die Dinge richtig zu sortieren.
Ergänzung: Microsoft hat ein PowerShell-Script zur Unterstützung des Patchens veröffentlicht, siehe Windows 10/11: Microsoft veröffentlicht Script für den WinRE BitLocker Bypass-Fix.
Anzeige
hat funktioniert. lesen hilft was die überprüfung der installation betrifft.
Note
The WinRE version number will only change after you add an LCU. If you add a DU package, use DISM /get-packages as described in the steps above to ensure that the package has been added to the image.
sprich wer das Windows Safe OS Dynamic Update vom Update Catalog einspielt, sollte bei gemounten winre prüfen mit dism /get-packages ob es da aufscheint. die andere prüfung mit der buildnummer ist ungeeignet dafür
Mal wieder äußert undurchsichtig.
Anhand der Releasedates würde ich vermuten, dass das nur mit aktuellem Windows 11 funktioniert. Die Release-Dates der anderen Versionen sind vom November.
das passt ja auch. das winre hat ja keine patches bekommen danach. hab bei meinem windows 10 22h2 anstandslos das cab file installieren können vom november.
Bei 2-3 Testclients mit Win10 Pro 22H2 schlagen die Scripte fehl und bei uns ist unter keine C:\Windows\System32\Recovery\WinRE.wim vorhanden. In welchen Konstellationen von Windows Installationsarten existiert das? Wir installieren per MDT und entsprechenden Anpassungen sowie importierten ISO..
Das Script parsed z.B. den output von dism oder reagentc, das Script sucht da nach englische Rückmeldungen der Befehle. Wenn du das auf einen Deutschen Windows nutzen möchtest, dann musst du die Texte übersetzen.
Ob Microsoft das auch in seine Medien integriert bzw. der Admin muss ja immer im Kopf behalten, wenn er jetzt mit einer Win10 22H2 iso neue Maschinen macht, dass er diesen Patch für Bitlocker integrieren muss.
Also durchdacht ist das ganze so nicht wirklich.
Die Images aus dem MSDN mit Stand Januar 23 haben das Dynamic und CU Update schon dabei.
Sagt mir doch mal eines: was bringt ein Patch für WinRE, den jeder unauthorisierte Nutzer zurückrollen kann? Die Recoverypartition ist doch unverschlüsselt und in keinster Weise geschützt.
Admin patcht, Angreifer nimmt die Platte aus dem PC, spielt die verwundbare Version einfach wieder ein und baut die Platte zurück.
Also: was soll das nun bringen? Ich habe es schon getestet, Bitlocker recovery Mode wird davon nicht getriggert.
Ja, da hast du Recht. Das ist prinzipiell ein Design-Problem, dass große Teile von Windows erstmal unverschlüsselt vorliegen und ich kann nur vermuten, dass hier auch das eigentliche Problem liegt. Zugriff auf den Datenträger kann den Bitlocker-Pin/Key kompromitieren durch Modifikation des Systems.
Eine echte Abhilfe sehe ich hier nicht. Die Frage ist, wie es zu 4.6 CVE-Score kommt.
Mein Senf zu dieser MS CVE-2022-41099 Dschungel Kommunikation:
Es gibt hier mehrere Fallstricke. Man muß schon sehr genau die Details beachten bzw. auch finden.
Wie MOM20xx schon angemerkt hat wird das SP Build im WinRe nicht geändert sobald das SafeOS DU eingespielt ist.
Das sollte laut MS-CVE Info ausreichen…hoffentlich.
Ob das SafeOS DU im WinRe eingespielt ist lässt sich vermutlich nur Dism mount und dann get-packages überprüfen.
Wer sich doppelt absichern will hat folgende Möglichkeiten:
1. – Januar CU + Safe OS in die WinRE.wim einspielen. Wer Bitlocker aktiv hat wird vermutlich beim reagentc /enable auf den Error 70 laufen da bei den meisten die Recovery Partion zu klein ist. Windows versucht alternativ dann die RE auf der OS Platte abzulegen was aber nicht geht da Bitlocker verschlüsselt und die RE damit nicht bootfähig ist -> folglich Error 70.
Lösung a:) Recovery Partition vergrößern um min. 500MB
Lösung b:) Inhalte aus der WinRe.wim entfernen bis sie etwa wieder die gleiche größe wie vor dem CU hat.
Beides nicht so prikelnd und mit Risiken verbunden.
2. – die passende WinRe aus den Januar 2023 MSDN's Windows ISO's extrahieren und mit der im LiveSystem WinRe austauschen.
Hier ist das CU + Safe OS update bereits enthalten. Error 70 springt dir eventuell wieder entgegen und wer in der LiveSystem WinRe auch noch Treiber injiziert hat muß vorab erneut Hand anlegen.
3. – WinRe via GPO deaktivieren.
Letzteres hat Markus K. in seiner Umgebung gemacht.
Wie macht man das denn? Habe ich es hier überlesen? Im Bitlocker-Abschnitt in den GPOs finde ich dazu nichts.
Als immediate Task (apply only once) deployen:
reagentc.exe /disable
(Executor: System)
ist der Patch noch aktuell oder inzwischen von Microsoft über Update behoben?