[English]Im Windows Setup-Prozess gab es eine Elevation of Privilege-Schwachstelle (CVE-2020-16908), die Microsoft zum 13. Oktober 2020 adressiert hat. Die Schwachstelle wurde durch eine Aktualisierung des Setups für Windows 10 Version 1903 und 2004 beseitigt (relevant für WSUS und ConfigMgr).
Funktionsupdates für 1903 und 2004 verworfen
Den Kollegen von deskmodder.de war der Techcommunity-Beitrag Windows 10 Feature Update Downloaded status reverted to No vom 16. Oktober 2020 aufgefallen. Microsoft weist Nutzer (von Verwaltungslösungen wie WSUS und den ConfigMgr etc.) auf eine Besonderheit nach der Synchronisierung von Updates, die am Patch-Dienstag (13. Oktober 2020) veröffentlicht wurden, hin. Windows 10 Feature-Updates für die Versionen 1903 und 2004, die zuvor mit der betreffenden Verwaltungslösung heruntergeladen wurden, werden anschließend unter dem Knoten Alle Windows 10-Updates den Status Heruntergeladen = Nein oder No anzeigen.
Der Grund, warum die alten Funktionsupdates verworfen wurden: Der Inhalt für diese Windows 10 Feature-Updates wurde überarbeitet, um ein Sicherheitsproblem zu beheben. Infolge dieser Inhaltsüberarbeitung müssen alle zuvor heruntergeladenen Feature-Updates erneut heruntergeladen werden. Das soll automatisch erfolgen, Administratoren können die aktualisierten Pakete aber auch manuell laden.
Schwachstelle CVE-2020-16908 im Setup
Im Sicherheitshinweis zu CVE-2020-16908 legt Microsoft zum 13. Oktober 2020 weitere Details offen. In Windows Setup gab es eine Elevation of Privilege-Schwachstelle. Diese besteht in der Art und Weise, wie Setup mit Verzeichnissen umgeht, was zu einer Erhöhung der Berechtigungen führen könnte.
Ein lokal authentifizierter Angreifer könnte nach Ausnutzung der Schwachstelle beliebigen Code mit erhöhten Systemprivilegien ausführen. Der Angreifer könnte dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit vollen Benutzerrechten erstellen.
Diese Schwachstelle besteht nur im Windows 10 Setup, welches dann ausgeführt wird, wenn ein Kunde von einer früheren Version von Windows 10 auf eine neuere Version aktualisiert (z. B. von Windows 10 Version 1909 auf Windows 10 Version 2004). Ein System ist nur während eines Upgrades auf eine neuere Version von Windows anfällig. Zu jedem anderen Zeitpunkt ist das Gerät nicht anfällig. Die Schwachstelle ist also kaum ausnutzbar.
Microsoft hat aber Sicherheitsupdates für Windows 10 Version 1803 bis Version 2004 freigegeben, die die Sicherheitsanfälligkeit beheben. Es wird sicherstellt, dass Windows Setup Verzeichnisse korrekt behandelt. Alle ab dem 13. Oktober 2020 unterstützten Feature-Update-Bundles wurden mit den gepatchten Setup-Binärdateien aktualisiert, so dass diese Schwachstelle nicht mehr besteht. Im MSRT-Portal lassen sich aktualisierte Setup Dynamic Update (DU)-Pakete bei Bedarf herunterladen.
Microsoft weist noch auf folgendes hin: Die bestehenden Feature-Updates für Windows 10, Versionen 1809 und 1909 wurden nicht überarbeitet. Für diese Versionen wurden neue Funktions-Updates veröffentlicht, die die vorherigen Versionen ersetzen und den Sicherheits-Fix enthalten. Da das Erstellungs-/Veröffentlichungsdatum für diese neuen Funktions-Updates das gleiche Datum/die gleiche Uhrzeit wie die Vorgängerversionen verwendet, laufen in einigen Umgebungen die ersetzten Funktions-Updates sofort ab.
Wie schön sich Feature-Upgrades mit Bordmitteln auf Clients verteilen lassen, habe ich kürzlich beim Upgrade von 1809 auf 1909 erleben dürfen (Danke an MS/Covid-19 für die Supportverlängerung von 1809, so ist mir das nicht schon eher auf die Füße gefallen).
– Automatischer Download per WSUS: keine Installation wie ein normales Update, Eingriff durch den Benutzer in der Einstellungen-App nötig (aber abgeschaltete Update-Hinweise für Benutzer, das sollen die auch gar nicht aufrufen müssen)
– Aufruf der WindowsUpdateBox.exe (wie z. B. in c:WindowsSoftwareDistributionDownloadsFeature-Update-Verzeichnis vorhanden) für den Windows Update-Download funktioniert nicht zuverlässig (per Hochfahrskript) (wird im Technet als Verfahren in Verbindung mit SCCM beschrieben)
– Download per BITS/BITSAdmin als Hochfahrskript (per SMB; HTTP/S nicht getestet) funktioniert nicht (um unabhängig zu werden von Kopierlast per copy/robocopy oder von Unterbrechungen einer Netzwerkverbindung per VPN oder WLAN))
– Aufruf der Setup.exe aus einer Kopie des Inhalts einer Windows-ISO per Hochfahrskript funktioniert nicht.
Bin dann dazu übergegangen, per Skript die ISO auf den PC zu kopieren (= bei Unterbrechung keine Datei auf der Platte), anschließend per 7-Zip zu entpacken (wollte mich nicht auf die Windows-ISO-Mount-Funktion verlassen) und, falls die entpackten Dateien vorhanden sind, die setup.exe mit Silent-Parametern per geplantem Task (in der Nacht) auszuführen.
Falls die neue Version als installiert erkannt wurde („wmic os get version /value“), werden die ggf. noch vorhandenen Dateien (ISO/entpackt) gelöscht.
Fies: Wenn mann die ISO irgendwo in c:windows kopiert/entpackt, so findet sich diese nach dem Feature-Update in c:windows.oldwindows. Ein Löschskript für die temporären Dateien findet diese dann nicht mehr in c:windowstemp … – also nach c:win10-1909 (oder ähnlich) entpackt.
Randnotiz zum Wake-On-LAN:
– einige Hersteller bieten Werkzeuge an, mit denen sich BIOS-Einstellungen auch per Skript setzen lassen (z. B. HP, Dell, Fujitsu – wobei nicht alle Einstellungen bei allen Modellen gesetzt werden können, z. B. Einsteigergeräten)
– dann fehlt noch die Einstellung im Treiber der Netzwerkkarte, damit das Magic Packet auch das Aufwecken triggert. In einem Treiber für ein älteres Lenovo-Gerät habe ich mal ein VB-Skript gefunden, welches das aktiviert, so ähnlich dürfte aber auch in oder https://community.spiceworks.com/scripts/show/240-script-to-enable-wake-on-lan-windows funktionieren (die beiden habe ich aber nicht selbst getestet!)
hier werden auch die Windows Feature Updates über WSUS verteilt (Windows 10 Pro 1909), ein Eingriff des Users ist hier überhaupt nicht nötig, per GPO wurden alle wichtigen Einstellungen gesetzt, dass das System zB nicht während der Arbeitszeit neustarten darf. Würde nochmals die GPO kontrollieren, den Aufwand den du da treibst halte ich für schwer übertrieben.
Wenns so einfach wäre, hätte ich das gemacht. Erste Versuche mit PSWindowsUpdate haben aber gezeigt, dass zwar immer wieder das Feature-Update per WSUS heruntergeladen und „installiert“ wird, abgesehen von den wiederholten Einträgen im Update-Verlauf aber nichts passiert.
Die beschriebenen Versuche sind dabei nicht übermäßig kompliziert, sondern nur eine Auflistung der nacheinander versuchten Wege. Zu sehen, was alles nicht funktioniert, macht einen nicht dümmer, hilft im Gegenteil aber solche Fallen zu vermeiden.
Schlussendlich funktioniert hier also ISO kopieren – entpacken – setup.exe ausführen.
Wenn/Falls mir die Erleuchtung kommt, warum es nicht per WSUS funktioniert, werde ich das hier ergänzen.
Hatte Microsoft also zuvor nicht in den Griff bekommen. Siehe https://www.borncity.com/blog/2020/08/18/windows-schwachstellen-cve-2020-1464-cve-2020-1571-beim-august-2020-patchday-geflickt/ bzw. https://web.archive.org/web/20200830151523/https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1571