[English]Nachtrag zum Januar 2023 Patchday für Windows. Es gibt in der Windows RE-Umgebung von Windows 10 eine Schwachstelle (CVE-2022-41099), die eine Umgehung der Bitlocker-Verschlüsselung ermöglicht. Zum Fixen muss die Win RE-Umgebung der Clients manuell aktualisiert werden. Das seit November 2022 bekannte Problem wurde nochmals im Januar 2023 von Microsoft aufgegriffen.
Anzeige
Leserhinweise auf Win RE
Das Thema steht schon einige Tage bei mir auf dem Radar, bin aber bisher nicht dazu gekommen, es im Blog anzusprechen. Es scheint bisher aber auch nur wenigen Leuten aufgefallen zu sein, Blog-Leser Martin hatte zum Januar 2023-Patchday folgenden Kommentar unter dem Beitrag zu Windows 10 hinterlassen.
Hallo zusammen, wie handhabt ihr den das WinRE Update, welches wohl manuell eingespielt werden muss?
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.
Microsoft hat das Ganze u.a. beim Sicherheitsupdate KB5022282 mit obigem Text (siehe auch den folgenden Screenshot) kurz angerissen. Mir war der Kommentar beim schnellen Überfliegen nicht aufgefallen, aber ich hatte den Leserkommentar als Lesezeichen abgelegt, um erneut auf das Thema zurück zu kommen.
Ist die Tage etwas untergegangen, aber Blog-Leser Markus K. hat glücklicherweise zwei Mal nachgefragt, weil er das Thema berechtigt für einen Stolperstein hält.
Anzeige
Ich bin gespannt wie viel Freude der Umstand bereitet, dass man auf jedem Rechner das WinRE via selbst erstelltem Skript oder ähnlich patchen darf, weil Microsoft das nicht tut (CVE-2022-41099).
Und in einem weiteren Post meinte er:
Lieber Günter,
leider immer noch nichts dazu in deinem Blog, ich war vermutlich zu "knapp".
Es sind alle betroffen die ihr WinRE nicht patchen, oder besser disablen!
Selbst booten von einem unpatched WinRE Device, ja manche setzen kein BIOS PW , oder sind halt nicht managed, sprich privat.
Ich finde es schlicht schlimm, dass man Bitlocker derart aushebeln kann!
Bitte vielleicht doch noch einen Blick aufs Thema werfen, es zahlt sich aus!
Wie gesagt, Thema war auf der Agenda, aber die letzten Tage lief wenig. Aber heute möchte ich noch kurz einen Blick auf dieses Thema werfen.
Bitlocker Bypassing Schwachstelle CVE-2022-41099
Die Bitlocker Bypassing Schwachstelle CVE-2022-41099 wurde wohl erstmals am 8. November 2022 von Microsoft mit Patches bedacht – aber am 10. Januar 2023 hat man den Artikel aktualisiert und weist in den Supportbeiträgen der Windows 10-Updates auf das Thema hin. Zur Schwachstelle ist folgendes hervorzuheben:
- In allen betroffenen Windows 10-Systemen kann ein erfolgreicher Angreifer die BitLocker Device Encryption-Funktion auf dem Systemspeichergerät umgehen.
- Der Angreifer benötigt aber einen physischen Zugriff auf das Zielgerät, um die Schwachstelle auszunutzen, um Zugriff auf verschlüsselte Daten zu erhalten.
Wegen des erforderlichen physischen Zugriffs auf das Zielgerät hat die Schwachstelle den CVSSv3.1-Index von 4.6 / 4.0 erhalten. Betroffen sind laut CVE-2022-41099 alle Windows 10-Versionen.
Manuelles Patchen ist angesagt
Administratoren könnten Win RE auf den Maschinen deaktivieren. Alternativ sind die Systeme manuell zu patchen. Administratoren und Nutzer müssen das entsprechende Windows-Sicherheitsupdate auf Ihre Windows-Wiederherstellungsumgebung (WinRE) anwenden. Die dazu erforderlichen Schritte sind im Support-Beitrag Add an update package to Windows RE beschrieben.
Ich schätze, dass auf nicht verwalteten Systemen von Consumern und kleinen Firmen die Fähigkeiten nicht ausreichen. Und im administrativen Umfeld von Firmen etc. dürfte das einiges an Aufwand erfordert. Habt ihr das Thema auf dem Radar? Oder ist das längst abgehakt? Ihr könnt ja einen Kommentar hinterlassen.
Ergänzung: Es wurde in nachfolgenden Kommentaren von Markus K. angemerkt, dass ich Windows PE (Preinstall Environment) und Windows RE gemixt habe. Das ist in obigem Text jetzt durchkorrigiert auf Windows RE (Windows Recovery Environment). Dabei ist mir aber beim Korrigieren noch eine Gedanke gekommen.
Das Windows PE (Preinstall Environment, boot.wim) wird bei der Installation verwendet, und Windows RE (Windows Recovery Environment, Winre.wim) beim Booten im Fehlerfall in die Recovery Umgebung. Wenn ich nicht gänzlich daneben liege, steckt das gleiche Image dahinter. Prüft also bei der Neuinstallation, ob das korrigierte Win RE bei einer Neuinstallation auf dem November 2022-Patchstand ist. Andernfalls würden alle Neuinstallationen wieder die Schwachstelle aufweisen. Aktuell habe ich keine Information, ob Microsoft da bereits ein aktualisiertes Image als Media Refresh-Variante bereitstellt. Dürfte vor allem bei den Installations-Images für die Windows 10 LTSC-Varianten ein Punkt sein, der im Auge behalten werden soll. Oder ist mir ein Denkfehler unterlaufen?
Ganz kurz noch für Consumer, die hier vorbei schauen: Win PE bzw. Win RE sind minimale Windows-Umgebungen, die zur Installation oder die Wiederherstellung / Reparatur verwendet werden. Einige Hinweise zu Win RE/PE gibt es im Beitrag Windows PE 4.0: Diese Programme laufen.
Ergänzung: Es gibt noch diesen Nachfolgebeitrag Windows 10: Neues zum WinRE-Patch (Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099).
Ergänzung 2: 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.
Ähnliche Artikel:
Microsoft Office Updates (3. Januar 2023)
Microsoft Security Update Summary (10. Januar 2023)
Patchday: Windows 10-Updates (10. Januar 2023)
Patchday: Windows 11/Server 2022-Updates (10. Januar 2023)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (10. Januar 2023)
Patchday: Microsoft Office Updates (10. Januar 2023)
Windows Patchday-Nachlese Januar 2023
Exchange Server Sicherheitsupdates (10. Januar 2023), dringend patchen
Microsoft Exchange Januar 2023 Patchday-Nachlese: Dienste starten nicht etc.
Windows: November 2022-Updates verursachen ODBC-Verbindungsprobleme bei SQL-Datenbanken
Windows: Microsoft Workaround für ODBC-Verbindungsprobleme (5. Jan. 2023)
Anzeige
Windows PE hat wohl noch andere Probleme, z.B. die Security-Event-Logs abzuschalten. Da ich es hier aber nicht erklären möchte, bleibt nur der Hinweis auf Youtube.
Wenn Du mir einen Link per Mail schickst (Adresse im Impressum/About) schaue ich es mir an und mache ggf. einen Beitrag draus. Adhoc habe ich nichts definitives gefunden – dass die Ereignisanzeige in WinRE fehlt, ist allerdings nachvollziehbar.
Guten Morgen,
ich hätte da vielleicht was passendes:
https://twitter.com/MHimken/status/1615457080235663366
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.
Was genau ist denn das Problem?
Das RE liegt doch auf einer separaten Partition?
Was hindert jemanden mit Hardware-Zugriff daran, eine alte ungepatschte RE einzuspielen?
Wenn man das PE bootet, kann man auf die Platte zugreifen, ohne einen Bitlocker-Key zu verwenden. Wir basteln schon an einem Script, welches das Update erledigen soll, um es später per Softwareverteilung auszurollen. Aber mit niedriger Prio. Schade, dass MS keine fertige Lösung präsentiert.
Aha, ein Zählpixel im Klartext… img src="https://vg05.met.vgwort.de/na/333e22fda75b46899d54a4401ee09f3e" width="1" height="1" alt="">
Danke, war arg unter Zeitdruck und bin auf den letzten Drücker zum Sport – eigentlich sollte ich so was nicht mehr machen – hätte auch gereicht, den Beitrag in 3 Tagen zu machen ;-)
Habe es jetzt korrigiert – wenn es "gut läuft" (noch 1.500 Seitenabrufe, setzt voraus, dass die nicht durch Ad-Blocker über das Zählpixel geblockt werden), bringt mir das irgendwo 2024 vielleicht 40 – 45 Euro von der Verwertungsgesellschaft Wort ;-). Das ist der Grund, warum Zählpixel hier im Blog in den Beiträgen drin sind.
Ich bin seit Tagen an dem Thema.
Dazu einige Links:
https://www.crc-pfalz.de/allgemein/kleiner-cve-grosse-auswirkung/
https://security.stackexchange.com/questions/267720/why-when-does-patching-cve-2022-41099-bitlocker-bypass-require-extra-steps
https://techcommunity.microsoft.com/t5/security-compliance-and-identity/cve-2022-41099/m-p/3715062
Ich fände es super, wenn dazu ganz viel Input kommt.
Der andere "Günter" ;-)
Bios-Passwort: Ja eigentlich gut. Kann ich aber keinem Anwender mehr vermitteln, dass er Bios-Passwort, Bitlocker-Pin und Windows-Kennwort eingeben muss damit er mal langsam anfangen kann zu arbeiten.
Ging mir auch im Kopf herum – aber muss jeder entscheiden. Mir ging etwas anderes durch den Kopf – bei n Passworten steigt die Wahrscheinlichkeit, dass Fehleingaben, vergessene Kennwörter oder ein ohne diese Informationen weitergegebenes Gerät unbrauchbar wird.
Ich glaube, das ist ein Irrtum: das BIOS Passwortr wird (nur) benötigt, wenn man von einer anderen als der internen Platte booten möchte… oder man halt ins Setup möchte.
Kommt darauf an, was man festlegt. Viele UEFIs (BIOS gibt es ja nicht mehr) erlauben auch das Festlegen der "Bei Start erforderlich" Option.
Na toll. Und wie bekomme ich WinRE von Build 10.0.19041 auf ein aktuelles 19044 oder 19045? Ehrlich gesagt, habe ich mich mit WinRE noch nie beschäftigt.
Es hat sich ein paar mal Windows PE statt Windows RE (Recovery Environment) eingeschlichen.
Was allerdings viel wichtiger aus meiner Sicht ist, dass mit aktiviertem Windows RE jeder Rechner unter Fremde Kontrolle gebracht werden kann, denn nach einem Factory Reset kann jeder Admin werden und was wäre wenn diese Person dann auch noch ganz gemein z.b. Computerraum den Rechner so präpariert, dass er aussieht wie alle anderen, bloß dass man sich nicht anmelden kann, aber schön via Keylogger Benutzernamen und Passwort abziehen kann?
Ein Schelm wer böses denkt.
Ich schaue es mir an – war "in the hurry" -> aber am Ende ist es Jacke wie Hose, ob man Pre-Install-Environment (PE) oder Recovery Environment (RE) schreibt – ist imho das gleiche Image.
Update: Ist im Text korrigiert und ich habe noch eine Ergänzung mit einigen Gedanken am Artikelende angehängt.
Also meine ersten Tests mit der Anleitung haben zumindest bei mir fehlgeschlagen, konnte ein neues Image erstellen, aber dann beim Austausch der WinRE gescheitert, warum auch immer… (soll ja einiges geben worauf man achten muss, zB Größe der existierenden Partition usw)
@Michael
wie du in meinem Blogbeitrag im CRC-pfalz sehen kannst hatte ich das gleiche Problem.
Noch mehr, weil nach dem Update von Windows selbst (also nicht das WinRE) ich das nicht einmal mehr aktivieren kann, wenn ich das originale image verwende also deactivate und activate direkt hintereinander mache.
Der "andere" Günter
https://www.crc-pfalz.de/allgemein/kleiner-cve-grosse-auswirkung/ ist dein blog oder wie?
warum bekommt man auf der seite nur
Forbidden
You don't have permission to access this resource.
Hier ist Zugriff problemlos – dürfte aber sein Blog sein.
Ja, Namensvetter Günter,
ich wollte es mir sparen hier alles noch einmal zu schreiben. Da habe ich auch den Weg beschrieben, wei man das Update macht. Wobei es eben bei mir nicht mehr zu aktivieren war.
Ich konnte den Link oben ohne Probleme aufrufen? Keine Ahnung warum es nicht funktioniert. Selbst google hat kein Problem.
Gruß
der "andere" Günter
vielleicht ein geolocation filter. sowohl aus der firma als auch zuhause und über ein vpn im ausland, alles fernab von deutschland bekomme ich den standard apache fehler forbidden.
definitiv geolocation filter drinnen. aus DE, IT klappt es. aus AT forbidden. gerade nochmal getestet
tja windows 10 original mit 21H2 installiert und schon 22H2 drinnen. So beim versuch den Januar 2023 patch in das winre zu installieren online. Kracht es das erstemal wegen veraltetem SSU. Nun gut den letzten SSU installiert. Das Update klappt lässt sich dann aber nicht committen und bricht mit Fehler 70 ab. Vermutlich Partition zu klein.
Läuft mal wieder beim Chaos Verein Redmond
Auch hier. Win10 ganz frisch gerade vor Weihnachten direkt 22H2 auf eine leere 2TB SSD installiert. Mounten und Patchen von WinRE funktioniert aber Unmount bringt Fehler 70 wegen offensichtlich zu klein angelegter Partition :-(
Nach längerer Google-Suche wie man aus der Situation wieder raus kommt, also auch den C:\mount Ordner wieder weg bekommt, notfalls halt zurück zum vorherigen Zustand. Aber so daß danach Recovery überhaupt noch funktioniert war der einzige brauchbare Treffer in einem offensichtlich dubiosen Untergrund-Forum zu finden: Das Reagentc /unmountre-Kommando mit "/discard" statt "/commit" aufrufen um die Änderungen rückgängig zu machen. Man hat dann zwar immer noch das alte Recovery-Image aber man hat wenigstens eines.
Microsoft hat es anscheinend nicht nötig die mount/unmount Optionen überhaupt zu dokumentieren??
https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/reagentc-command-line-options?view=windows-11
Zu kleine Recovery-Partition kann übrigens auch eine Fehlerursache beim Upgrade 10->11 sein!
das legt ja das os bei der installation an und nicht der user. dann soll microsoft die halt dementsprechend gross machen. für solche fehler hab ich kein verständnis.
Exakt. Wenn man wie ich jetzt ein aktuelles Win10 22H2 auf eine leere, nicht partitionierte 2TB SSD installiert dann habe ich kein Verständnis daß dabei die Recovery ohne irgendwelche Reserve angelegt wird. Beim Upgrade eines Alt-Systems mit schon vorhandener Recovery einer älteren Windows-Version könnte man es ja noch verstehen.
es wäre nett von der MS gewesen wenn sie etwas genauer spezifizieren täte wann und wie das ausnutzbar ist….
weil ich glaub nicht das der Bug ein CVE von 4 hätte wenn man damit wirklich Bitlocker "knacken" könnte …wenn man Bitlocker vernünftig implementiert hat (so wie MS empfiehlt), sprich mit TPM + Pin wird man hoffentlich nicht betroffen sein, aber genau die Info fehlt leider…
weia. jetzt erklaer mir doch mal jemand bitlocker. wie um himmelswillen ist das so umgehbar? ich dachte bitlocker kann das was truecrypt seit 20+ jahren oder so macht. bloss weil ich n truecrypt image file (also an die rohdaten) da herankommen z.b. direkt mit physischem access eines bootenden rechners usw… ist allerdings truecrypt (oder veracrypt usw..) absolut sicher solange man nicht mit bruteforce da alles durchprobiert in ewigen zeitraeumen.
wenn ich jetzt aber diesen bitlocker bug ueberfliege, wie um himmelswillen ist das konzeptionell gestrickt wenn eine RE partition oder ein booten von RE medium zum drumherumarbeiten ausreicht um bitlocker da komplett links liegen zu lassen.
dann ist doch Bitlicker NULL und NICHTIG, oder was versteh ich hier noch falsch? anyone? danke vielmals.
Ich versteh das problem nicht ganz. Kann die WinRE Umgebung eine Bitlocker-Verschlüsselung ohne Kennwort aushebeln?
Wenn ja, wie will verhindert werden das der Angreifer einfach eine alte WinRE-Umgebung nutzt?
So wie ich es verstanden habe ist genau das der Fall. Durch eine Sicherheitslücke (gibt anscheinend noch keinen POC) kann auf ein Bitlocker verschlüsseltes Volume zugegriffen werden.
Genau, ein Angreifer kann einfach die WinRE Umgebung austauschen. Das patchen bringt also nichts.
Bin mal gespannt wie Microsoft sich dazu äußern wird.
Wie kann das auf einem vollverschlüsseltem System sein?
Ich würde sehr vereinfacht Verschlüsselung so verstehen, das nur mit dem Passwort die Daten der Disk wieder lesbar sind.
Wenn irgend ein Mechanismus das aushebeln kann, dann erscheint mir solche FullDisk-Verschlüsselung "by Design" unwirksam. Kann es sein das das Problem auf eine Hardware-Based Lücke zurückzuführen ist, ev. in TPM?
Wenn es keine Hardware-based Lücke ist fällts mir schwer zu glauben das soetwas ein versehentlicher Bug sein soll. Microsoft beschäftigt zehntausende Entwickler, da müssen solche "Design-Schwächen" irgendwem auffallen.
Es gibt kein vollverschlüsseltes Windows System. Schau dir mal die Partitionen an. Die Windows Partition und eventuell weitere Daten Partition falls vorhanden sind natürlich mit Bitlocker Verschlüsselt. Aber niemals die versteckte Systempartition wo die Recovery Umgebung liegt.
Sinn und Zweck der Recovery ist ja das man das noch booten kann falls das Hauptsystem streikt.
Natürlich muss man dann wenn die Recovery Umgebung startet den Bitlocker Wiederherstellungsschlüssel eingeben damit man auf die Verschlüsselten Volumes zugreifen kann.
Aber anscheinend kann man das irgendwie umgehen..
Es wäre so nett, wenn irgendjemand wüsste, was denn genau möglich war, ohne das Patchen. WinRE braucht immer das Recoverykennwort, um irgendwas mit dem Volume zu machen – ich habe es nie anders gesehenund es ist hierbei egal, ob man Prebootauthentifizierung einsetzt (TPM+PIN), oder nicht (nur TPM).
PS: warum wird denn der Verdacht gestreut, dass das unter WinRE manuell zu beseitigen ist? MS legt doch nahe, wie man das skriptet – fällt scripted Deployment neuerdings in den Bereich "manuell"?
Letzter Satz: Ja! Update per WU oder WSU oder Intunes – vom scratch -> automatisch
Sobald ich was mounten und mit DISm agieren muss – egal ob in der Konsole oder per Script, ist dies ein manueller Eingriff – auch wenn anderes das vielleicht nicht so sehen.
"Sobald ich was mounten und mit DISm agieren muss – egal ob in der Konsole oder per Script, ist dies ein manueller Eingriff" – Automation ist Automation und hat mit manuell nichts gemein.
Was hier besonders ist: die Admins müssen diese Automation selbst auf den Weg bringen. "Manuell" kannst Du nur das nennen, was der Heimanwender tun muss, denn er hat den vollen Aufwand. Netzwerkadmins haben den genau 1x pro Netzwerk und nicht "manuell" 1x pro PC.
Du reitest gerne Prinzipien – prinzipiell bin ich bei dir. Nur wenn mit jemand mit "Verdacht genährt" kommt, muss ich opponieren – denn der Beitrag spricht ja auch den kleinen Anwender im SoHo-Bereich an, der vielleicht ein W10 Pro hat und mit Bitlocker arbeiten will.
Nein, Prinzipien reiten ist nicht meins. Ich sehe ein, dass der Umstand "Patch installieren reicht nicht" ungewöhnlich und bemerkenswert ist. Ich habe aus Sicht von Firmenadministration gesprochen, du in Bezug auf manuell eher aus SoHo-Sicht.
Also Schwamm drüber :-)
das ist das eine. der manuelle eingriff, er wird mehr und mehr zum standard bei microsoft sec updates.
das andere: es funktioniert ja nicht mal manuell.
1. das update kann ich alleine nicht einspielen, weil ein ssu noch fehlt. also ssu auch noch manuell einspielen. dann klappt es mit dem update.
2. ein comitten des updates und unmounten vom wim ist nicht möglich, weil das wim dann für die, vom os bei der installation erstellte, recovery partition zu klein ist.
und spätestens da hört es dann auf mit der bastelei wenn man dann auch anleitungen aus reddit oder wem auch immer angewiesen ist auf scripts von github, die versuchen die unzulänglichkeiten von microsofts betriebssystem unfällen zu beheben.
Ich bin ja bei dir – alleine, solange hier im Blog noch Leute mit "glühendem Herzen" einschlagen und den letzten Scheiß aus den Microsoft Entwicklerlabors verteidigen und Kritik als Bashing verorten – oder da draußen alles von Microsoft als alternativlos auf die Fahnen heften, wird sich nichts ändern. "Lernen durch Schmerzen" heißt die Devise …
PS: Ich bin ja ein paar Jährchen im Geschäft und habe viele MS-Entwicklungen sehr nahe als IT-Autor verfolgt und in Büchern begleitet. Der Erfolg von Microsoft war immer wieder "gutes Marketing", "lange genug durchhalten, bis die Konkurrenz ausgehungert war" – und in den letzten 10 Jahren in der komfortablen Situation zu sein, dass der potentielle Mitbewerb (Stichwort Linux, LibreOffice etc.) oft zu tief im eigenen Saft gebraten hat, und dadurch die Masse nicht ansprechen konnte. Es sind oft die in meinen Augen besseren Konzepte, die dann aber so lausig umgesetzt werden, dass MS als goldene Alternative erschien. Hab gerade wieder mein deja vue in Hyper-V mit Gästen von Windows 7, Windows 10 und Linux Mint gehabt. Mint heißt auf Konsolenebene mit sudo irgendwas stoppeln – das ist nicht praxisgerecht. Lasse ich Ubuntu in der Microsoft vorkonfigurierten Installation als Hyper-V-Gast installieren, passt es vom Scratch. Es wäre also möglich, dass auch Linux nutzerfreundlicher in der Verwaltung daherkommt – alleine, es ist nur der Fall, wenn sich ein Anbeiter diesem annimmt.
Nun ist der Lock-in in MS-Produkte seit fast 10 Jahren komplett da und der von mir schon mal 2015 zitierte "Nasenring, in der die Nutzer durch die Manage gezogen werden" ist da … Zeit, für große Packungen Schmerztabletten ;-).
Zu Punkt 1.
Das SSU ist im CU enthalten.
Du kannst es mit diesem Befehl extrahieren und anschließend mit dism installieren. Danach dann das SSU installieren.
EXPAND c:\updates\LCU\*.msu /f:ssu*.cab c:\updates\ssu
Zu Punkt 2.
Da hast du leider recht. Vorallem weil selbst nach dem dism cleanup Befehl die unnötigen Dateien nicht gelöscht sondern nur zum löschen markiert werden. Man muss also erst cleanup -> commit (unnötig große Datei) -> export (dadurch werden die als löschbar markierten Dateien gelöscht).
Um das umzusetzen muss man aber erst die winre.wim woanders hinverschieben, dann das alles machen und anschließend die neue Datei wieder auf die Recovery Parition schieben. Wahrscheinlich sogar erst die Recovery Partition vergrößern.
Ich habe bereits ein Paar Links mit Anleitungen gepostet , sind aber noch nicht von Günter freigeschaltet..
Zum letzten Satz: Ich sitze schon eine Weile an der Kommentarmoderation – der Blog ist heute früh regelrecht von Kommentaren geflutet worden und ich habe nach einer Night Session etwas länger geschlafen und auch länger gefrühstückt ;-) Die Kommentare werden jetzt Schritt für Schritt freigegeben. BTW: Sind aktuell ja 3 Blogs, die ich täglich diesbezüglich durchgehen muss …
Ich würde sagen, "manuell" ist, wenn ich zu dem Rechner gehen muß und irgendwie einen Key oder so eintippen muss.
Manuell ist (aus Sicht der Automation), wenn eine Sache extra ausgeführt werden muss, die auch automatisch ohne Zutun laufen könnte.
Ob wer hin läuft oder nicht, spielt eigentlich keine Rolle. Das Ausführen einer wie auch immer aussehenden Aktion reicht um es nicht Automatisierung nennen zu können.
Einfaches Beispiel:
– Windows Update per Autoinstallation (wie bei Windows 10 + 11 üblich), wäre Automation.
– Windows Update "nur" per Policy erzwungen, aber durch den Anwender per Klick auf den "Install" Button gestartet, wäre manuell. -> der Prozess der Update Installation selbst kann dann nach Start der Aktion aber auch wieder automatisch laufen. Es sei denn, es kommt zu dem Umstand, dass Jemand manuell nacharbeiten muss.
Da ist wohl der Server unter der Last zusammen gebrochen, oder wie man sagt "er wurde gebornt".
Hier ist der Server jedenfalls auch unpässlichlich
"Das Windows PE (Preinstall Environment, install.wim) wird bei der Installation verwendet, und Windows RE (Windows Recovery Environment, Winre.wim) beim Booten im Fehlerfall in die Recovery Umgebung."
AUTSCH! Windows PE steckt in \sources\boot.wim. nicht in \sources\install.wim, und es hat SELBSTVERSTÄNDLICH die gleiche Schwachstelle wie Windows RE, denn beide sind fast identisch — sie starten nur verschiedene "Shells", ersteres das Installationsprogramm, letzteres das Wiederherstellungsprogramm.
Asche auf mein Haupt – mit der boot.wim hast Du Recht – hab ich verwürfelt. Mit den Innereien war ich mich unsicher, wie identisch die sind.
@Günter
Hast du denn irgendwelche Informationen darüber, wie das Thema ausnutzbar sein soll? Speziell unter welchen Bedingungen?
Ist es ein Unterschied ob man Bitlocker mit TPM + Pin nutzt oder nur TPM? Oder gar den Software Mode? Ist es ein Unterschied, ob man OPAL Drives nutzt oder per Software die Bits auf dem Drive verschlüsselt?
So wie ich das verstehe ist das seitens Microsoft der zweite Anlauf, die Lücke zu fixen. Da es erst regulär im laufenden System angewendet wurde und im zweiten Anlauf jetzt auch für die WinRE Umgebung gelten soll. -> gab es da beim ersten mal Informationen, wie sich das Thema ausnutzen lässt?
Aus meiner Sicht dürfte das eigentlich gar nicht funktionieren, wenn TPM + Pin verwendet wird. Denn mit dem Pin wird ein weiteres Merkmal in die Verschlüsslung gestreut. Egal ob irgendwer durch Fehler in der WinRE Umgebung jetzt an den TPM Key kommt und irgendwie die Disk mit seinen Rohbits lesbar ist – ohne Pin darf meines Wissens nach kein Zugriff in die reguläre Windows Umgebung gehen. Bestenfalls via Brutforce?
Der Dieb kommt an die TPM Daten auch mit dem richtigen Equipment durch physisches Abgreifen der Signale. (bei einem TPM Chip extern wie auch in der CPU), die Disk hat er auch. Das wäre broken by Design, wenn sich das umgehen lassen könnte, einfach mit "Boardmitteln".
Schwieriger sind aber meiner Ansicht nach alle Umgebungen mit TPM only oder ggf. eben im Modus ohne TPM mit nur einem Token, wenn der Angreifer Zugriff auf jene hat. Wer das aber nutzt, hat eh ganz andere Probleme – denn das System ist normal dann über mehrere Wege angreifbar, sofern das OS einmal vollständig gebootet ist. Und vor allem die ganzen Schnittstellen (USB und Co.) alle aktiv sind.
Sollte es sich hier aber um die Möglichkeit handeln, wie man den eigentlich notwendigen Pin bei der TPM + Pin regulären Version als zweiten Faktor umgehen kann, wäre das ein ziemlicher Supergau. Das lässt sich nämlich nicht! patchen.
-> Die Recover Partition ist unverschlüsselt auf der Disk
-> Die Recover Umgebung kann auch extern zugeführt werden (über einen USB Stick bspw.)
-> Patchen der WinRE Umgebung bringt exakt gar nix, da die auf der Disk befindliche schlicht austauschbar ist.
Wenn das also so wäre, wäre die einzige Lösung eine andere Verschlüsslung zu nutzen. True/VeraCrypt im Software Modus bspw.
Ich habe keine Informationen – Microsoft hält den Daumen drauf. Aber ein wenig Phantasie: Es kann über die WinRE-Umgebung etwas als "Man in the Middle" injiziert werden, so dass die Bitlocker-Verschlüsselung im Klartext mitgelesen werden kann. Oder die Verschlüsselung lässt sich blockieren, so dass Daten trotz aktiviertem Bitlocker unverschlüsselt auf dem Medium landen. Ist aber nur ein Blumentopf, den ich auf den grünen Tisch stelle ;-).
Zum Thema "unknackbares Bitlocker" – ich habe es nicht verfolgt, aber es gab mal vor Jahren einen Beitrag, wie sich Bitlocker knacken ließe. Beachtet auch meinen Beitrag Windows Bitlocker-Verschlüsselung trotz TPM ausgehebelt aus 2021.
Den Beitrag kenne ich, es war halt Bitlocker mit TPM only. Als Infrastruktur Betreiber sage ich dazu, selbst schuld wer das macht…
Der Punkt dabei ist eigentlich, dass der Pin eben für den zweiten Faktor sorgt und genau dieser der Einfallsvektor zum Brechen der Verschlüsslung ist, da das der einzige der Faktoren ist, die nur der Nutzer kennt/kennen sollte. Und nur durch diesen (zzgl. des TPM Schlüssels) kann die Disk gelesen werden.
Das meine ich mit, egal ob wer an den TPM Key kommt oder nicht, es darf eigentlich ohne den zweiten Faktor des Pins nicht möglich sein, die Verschlüsslung zu brechen.
Eine gebootete WinRE Umgebung hat normalerweise in keiner Weise Zugriff auf die Daten und sollte, sofern da nicht irgendwas fatal falsch gelaufen ist, auch den Pin im Klartext nicht kennen. (sollte, wohlgemerkt)
Die einzigen beiden Dinge, die ich mir theoretisch vorstellen kann:
A) Wenn man irgendwie über Ruhezustand/Standby ran kommt. Standby triggert die Pinabfrage meines Wissens nicht?
B) Wenn aus einem gebooteten Windows heraus die WinRE Umgebung nach einem Restart erzwungen wird, sodass das Gerät möglicherweise "entschlüsselt" ohne weitere Pin Eingabe direkt WinRE bootet. Vielleicht über Fastboot oder wie dieses schnelle Starten ohne echten Boot sich nennt?
-> In beiden Fällen wäre man über den Pin als zweiten Faktor hinweg.
was wäre wenn?
Was wäre wenn es eine absichtlich eingebaute Backdoor gäbe?
Sind die Daten einmal per Bitlocker verschlüsselt benötige ich entsprechende Informationen um das lesen zu können. TPM + PIN oder Wiederherstellungsschlüssel sind nicht so einfach zu "erraten".
Der verwendete Algorithmus sollte sicher sein. Wie also umgehe ich die Verschlüsselung? Wie komme ich durch das "Mini Windows" an die Schlüssel, die ich zum Entschlüsseln benötige?
Ich denke hier liegt der Schlüssel um zu verstehen wie der Angriff funktioniert.
Leider haben wir aber keine Info und so wird diese Sicherheitslücke wahrscheinlich in ca. 2 Wochen aus den Medien wieder verschwunden sein.
Der "andere" Günter
Die PIN hat doch nix mit der Verschlüsselung zu tun. Die Platte wird vorher verschlüsselt, und der Wiederherstellungsschlüssel erstellt. Die PIN ist optional und wird danach eingerichtet. Sie dient nur der Sicherung des Schlüssels im TPM.
Wenn WinRE gebootet wird, pfeift das halt auf die PIN und holt sich den Schlüssel aus dem TPM – so als wäre keine PIN vorhanden.
Im Firmenumfeld wird die Systemwiederherstellung einfach abgeschaltet und gut ist. Wenn der Rechner zickt kommt halt ein neues Image drauf, macht mehr Sinn. Dann gibts auch keine Sicherheitslücke.
@JuergenK
Wenn dem so ist wie du sagst, ist das aber ein unlösbares Problem. ;)
Denn warum solltest du als Angreifer/Dieb auf die WinRE Umgebung angewiesen sein die auf der Disk ist? Oder eben nicht ist?
A) ist die unverschlüsselt und damit extern beeinflussbar, wenn sie drauf ist.
B) man kann sie von extern zuführen, wenn sie nicht drauf ist. Bspw. durch nen angesteckten Stick – die Disk kann man auch an einen anderen PC stecken, die TPM Information kann extern ausgelesen werden mit dem richtigen Equipment – Link zu so einem Beleg hatte Günter oben gepostet.
Sprich, wenn dem so ist wie beschrieben, dann ist das ein unlösbares Problem…
Der Sinn des Pins/Passworts ist, dass du da nicht ran kommst. Ich bin der Ansicht, dass die Eingabe Teil des Schlüssels ist, damit man an die Daten kommt. Ob dabei jetzt der TPM Inhalt verschlüsselt wird, der Zugriff authentifiziert oder das Ding jetzt Teil des echten Schlüssels ist, ist eigentlich irrelevant. Relevant ist, ob man ohne den Pin an die Daten kommt. Und genau das stelle ich ehrlicherweise aktuell in Frage. Ne Sicherheitslücke IN einer extern zu bootenden Software kann aus Sicherheitssicht nicht die Notwendigkeit der Eingabe eines zweiten Faktors umgehen, weil ohne diesen Faktor die Informationen im TPM gar nicht in verwertbarer Form zur Verfügung stehen sollten.
Denn wäre dem nicht der Fall, wäre das ganze TPM Konstrukt Broken by Design, weil man eben mit Diebstahl des Gerätes die Schlüssel ebenso entwendet. TPM steckt in aller Regel auf dem Board oder ist in der CPU. Bis jetzt hat es meines Wissens nach Niemand geschafft, ein nicht gebootetes Windows zu knacken, WENN die Pin Abfrage gesetzt wurde. Geschafft wurde, den Datenstrom zum/vom TPM Modul auszulesen – und damit eine TPM only Installation zu öffnen, da damit das System selbstständig die TPM Daten "öffnet", sofern Windows gebootet wird. Logisch, sonst geht das auch gar nicht.
Unabhängig davon ob jetzt Microsoft eine Sicherheitslücke hat in ihrer Software oder nicht – das Problem ist rein die angebliche! Möglichkeit so eines Zugriffs. Wenn das mit einem WinRE geht, geht das auch mit einer selbst geschriebenen Software. Wie will man das verhindern? Das ist technisch nicht verhinderbar, dem Dieb so eines Gerätes kannst du kaum vorschreiben nur aktuelle WinRE Versionen zu "versuchen".
Und exakt das ist eben die Frage. Trifft das auch Systeme mit gesetztem Pin/Password oder nicht.
@P.B.
Ich bin da ganz bei Dir – broken by Design scheint mir schlüssig. Ich habe jetzt soviel über das Thema gelesen, irgendwo stand was, dass sowohl Bitlocker mit und ohne PIN betroffen wären. Aber tatsächlich weiß wohl immer noch niemand wie genau die Lücke ausgenutzt werden könnte; einfach nur durchs booten reicht aber wohl nicht :-) es muss wohl noch spezieller Code "mitgegeben" werden.
Vereinfacht gesagt denke ich schon, dass hier im Prinzip die PIN umgangen wird und der Schlüssel dann auch ohne sie aus dem TPM ausgelesen werden kann. Das wäre dann nicht unbedingt mit selbst geschriebener Software möglich, da es ja wohl direkt in die Tiefen des Bitlockers geht, welcher die PIN verwaltet.
Und wie gesagt, die PIN wird erst nach der abgeschlossenen Verschlüsselung (optional) erstellt und ändert auch an der Verschlüsselung oder dem Wiederherstellungsschlüssel nichts. Also kann sie kein notwendiger Teil davon sein sondern nur zur Sicherung des Schlüssels dienen.
Alles weitere ist aber schon irgendwie Spekulation weil wirs halt nicht genau wissen wie's funktioniert….
Ist aber auch unglücklich, ohne WinRE kannst du Windows aus Intune nicht zurücksetzen/neuinstallieren. Wenn das jetzt ein Kollege ist der irgendwie hunderte Kilometer vom HQ entfernt ist dann darf der erstmal anreisen und zwischenzeitlich Kundentermine absagen.
@JuergenK
Ich glaube der entscheidende, wenn auch recht unscheinbare Punkt ist der hier:
"Are both offline images and WinRE in a running environment affected by this vulnerability?
No. Only a WinRE image on a running PC is vulnerable. This can be any time a recovery or reset operation is invoked from the main OS."
-> ich interpretiere das so, dass NUR aus einem laufenden Windows heraus die WinRE Umgebung in der Lage ist, den Schlüssel zu nutzen. Nicht die Offline Version, die man extern bootet. Im Endeffekt ist das sogar die Antwort auf die Frage des WIE. Denn das schließt den Kreis zu meiner Eingangs gestellten Frage, ob man die Pin Abfrage damit umgehen kann. Nein, offenbar nicht… Das ist zwar nicht gut, aber gibt der Thematik damit doch deutlich weniger Risiko. Denn durch simples Deaktivieren der WinRE Umgebung ist der Punkt zumindest fixbar.
Das Patchen der WinRE auf einem System ist offenbar aber nur eine halbgare "Lösung", denn man kann es, da unverschlüsselt auf dem Datenträger existent, auch wieder auf einen alten Stand zurück setzen. Sogar von extern. Möglicherweise über SEDs lösbar – aber das gibt wieder ganz andere Baustellen auf.
Schränkt den Angriffsvektor aber definitiv massiv ein, da eine zweistufige Maßnahme notwendig ist. Erst Offline die WinRE zurück setzen, dann warten, bis der User den PC sauber mit Pin/Password hochfährt über den POA Screen hinaus, und erst danach Online den WinRE Reboot erzwingen + die (noch) unbekannte Magic innerhalb der WinRE Umgebung ausführen.
Mit aktiviertem Pin/Password als POA wird der zweite Schritt nicht möglich sein direkt mit durchzuführen. Oder der Angreifer muss in der Lage sein, im laufenden Betrieb die Daten zu tauschen. Firewall und Zugriffsrechte sollten das aber verhindern.
Ich lästere ja ungern über MS. Aber das ist schon mal wieder typisch. Microsoft hat es verbockt, der User soll es nach irgendwelchen Anleitungen aus dem Netz richten und die funktionieren dann nicht. – Selbst ich als gelernter Admin, der sich tag täglich mit Software-Deployment und OS-Deployment beschäftigt, musste erstmal genau hinschauen, was da eigentlich jetzt zu tun ist.
Mal abgesehen davon, dass man sich die Updateversionen und Anleitungen erstmal zusammen suchen muss, hat MS nicht mal beachtet, dass ja möglicherweise die WinRE-Parition nach MS-Vorgaben eingerichtet und zu klein ist.
Hat schon jemand ne Lösung? Kann man die Partition vergrößern und wie groß müsste die eigentlich sein? (Das ist natürlich endgültig nix, was man dem Heimanwender zumuten kann!!)
Hi,
ich habe es vorest an einem Rechner ausprobiert und es funktioniert. Ist halt umständlich weil man die Recovery Partition vergrößern muss. Das geht nur nicht ohne weiteres weil diese am Ende der Platte liegt. Man muss also die Windows Partition verkleinern. Dann die Recovery Partition löschen, dann eine größere neue Recovery Partition anlegen. Zumindest wenn man mit Boardmitteln arbeitet.
Hier ein paar Links:
Nach dieser Anleitung habe ich es gemacht (Vorallem der Hinweis auf ein dism export nach dem cleanup ist wichtig da die Wim Datei ansonsten unnötig groß wird):
Hier ein Script (habe es selbst nicht ausprobiert):
https://github.com/halsey51013/UpdateWindowsRE-CVE-2022-41099
Und noch eins:
https://gist.github.com/jones948/2473df8eced9cc5728d349a58edd1e1e
Mit diesem Powershell Script kann man im Netzwerk checken ob bereits gepatchte Winre.wim verwendet werden:
https://gist.github.com/PCAssistSoftware/abd053091eb297e5b9e4bf8742d83e08
un jetzt frag ich mich was die bei ms generell machen.
windows 10 mit 21h2 installiert und auf 22h2 aktualisiert hat in sich ein recovery system auf buildstand windows 10 2004. abgesehen das die anleitung so nicht funktioniert, für welchen windows build level soll man hier denn dann die updates also das cu und das ssu einspielen?
die haben den dreck, wenn überhaupt, nur auf win 11 getestet wo noch alle versionen scheinbar unter support stehen und updates bekommen.
Deine Vermutung kann ich bestätigen!
Window 10 2004, 20H2, 21H1, 21H2, 22H1, 22H2 bringen alle das WinRE mit der Build 10.0.19041 im install.wim mit. Ich habe noch keine Quelle für ein neueres WinRE aus Windows 10 gefunden. Hier schießt sich Microsoft selbst ins Knie, denn der Upgrade-Katalog listet nur CUs für im Support befindliche Windows Versionen. Windows 10 2004 ist seit 12/2021 nicht mehr dabei.
Also Microsoft, wie aktualisiert man ein WinRE 10, 2004?
ziemliche Flickschusterei, eigtl. ist Bitlocker nun kaputt.
https://github.com/o0MattE0o/CVE-2022-41099-Fix
https://github.com/halsey51013/UpdateWindowsRE-CVE-2022-41099
Die Scripte funktionieren schon wegen unterschiedlicher Sprachausgabe und dem parsing nicht. Das ist so ein Desaster, Microsoft soll da einfach mal ein Tool rausbringen was jede Sprache unterstützt und auch prüft ob die winre evtl. älter als das installierte Windows ist, dann braucht man ggf. das dynamic update einer ältere Version.
Update auf einem PC habe ich geschafft, aber nun möchte ich alle PCs updaten.
Bin leider neu und mir fehlt der Rest, wie z.B. benutze ich nun ein Compliance Item und eine Baseline? Wie finde ich überhaupt heraus, ob unsere PCs compliant sind oder nicht?
Mit folgendem Befehlt finde ich zwar die Version vom ServicePack, aber wie weiss SCCM, ob der PC nun compliant ist?
Dism /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1
Es gibt wohl nun ein Skript von MS für dieses Problem:
KB5025175: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2022-41099
Ich habe es selbst noch nicht getestet, dies will ich kommende Woche mal probieren.
———————-
GB: Parallelität der Ereignisse – siehe den Nachtrag im Artikel am Textende, den ich wohl eingepflegt habe, während Du den Kommentar schriebst. Das Thema ist mittlerweile in einem Folgebeitrag eingepflegt.