Massive Probleme beim Microsoft Januar Patchday

Diese Woche hatte ich massive Probleme nach dem Microsoft Januar Patchday am 11.01.2022. Die ausgelieferten Sicherheitsupdates haben auf den von mir betreuten Windowsservern einen Katastrophalen Schaden angerichtet. Dies scheint auch nicht nur mir so gegangen zu sein. Es gibt im Netz zahlreiche Berichte von anderen betroffenen und Günter Born hat einen Artikel bei Heise dazu geschrieben: Sicherheitsupdates vom Januar 2022 mit massiven Kollateralschäden in Windows. Gerade Installationen auf der Basis von Windows 2012R2 sind umfänglich betroffen.

Insbesondere von der Installation des Update KB5009624 auf Domain Controllern sollte man aktuell absehen. Es hat alle von mir betreuten Domain Controller in einee Boot-Loop (Boot-Schleife) geschickt und damit das gesamte Windowsnetzwerk lahmgelegt. Grund scheint ein Fehler im Modul lsass.exe zu sein. Auch darüber findet man weitere Details im Blog von Günter Born im Artikel Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife.

Nach der Deinstallation des Update KB5009624 auf den Domain Controllern funktionierten diese prinzipiell wieder, allerdings war einer der Domain Controller so beschädigt, dass er nicht mehr richtig funktionierte und sich auch standhaft weigerte mit den anderen zu replizieren. Alle Versuche diesen wieder zu reparieren blieben erfolglos. Erst als dieser von Hand gelöscht und komplett neu aufgesetzt wurde, nahm er wieder fehlerfrei seine Arbeit auf.

Nachdem alle Domain Controllern wieder einwandfrei arbeiteten, lief das Windowsnetzwerk prinzipiell wieder. Es gab aber haufenweise weitere Probleme im Windowsnetzwerk. Das gesamte IT Team war zwei Tage lang damit beschäftigt die Folgeprobelme und andere Fehlfunktionen des Microsoft Patchday zu lösen. Neben dem Boot-Loop auf Domain Controller traten bei uns auch noch folgenden Kollateralschäden durch den Microsoft Januar Patchday auf:

  • Nach dem Einspielen von KB5009624 und KB5009595 startete Hyper-V auf Windows 2012R2 nicht mehr. Informationen dazu findet man bei Microsoft im Artikel Virtual machines (VMs) in Hyper-V might fail to start
  • Nach dem ein Einspielen von KB5009624 auf den Windows 2012R2 Exchange Servern funktioniert ReFS nicht mehr. Sobald das Update deinstalliert wurde funktioniert dies zwar wieder. Mit Pech kann die Exchangeinstallation aber so beschädigt sein, dass man die Datensicherung zurückspielen muss.
  • Nach dem Einspielen der Updates funktionierte ein Cluster mit Windows 2012R2 Terminalservern nicht mehr. Selbst eine Deinstallation aller Updates und die anschließend komplette Neueinrichtung der Rollen konnte den Cluster nicht wieder richtig reparieren. Es gab andauernde nicht zu erklärende Fehlfunktionen. Deshalb wurde der Cluster von uns aufgegeben und die User auf einen neuen Cluster mit Windows 2019 Terminalservern migriert.

Ich habe Verständnis dafür, dass Hersteller wie Microsoft heute Sicherheitslücken sehr schnell schließen müssen, um die daraus resultierenden Gefahren für die Kunden schnell abzustellen. Ich finde die Informationspolitik zu den durch das Update verursachten Problemen von Microsoft jedoch völlig unzureichend. Warum gibt es nach wie vor keine offizielle Stellungnahme mit einer Auflistung der Probleme? Warum wurde auch drei Tage nach dem Erscheinen der Updates und den vielen Berichten über die Probleme die Update bis jetzt nur halbherzig zurückgezogen? Diese werden zwar aktuell nicht mehr automatisch ausgeliefert. Sie lassen sich im aber immer noch finden und ohne Warnung installieren. Siehe auch hier die Zusammenfassung von Günter Born Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?

Bis jetzt scheint es nur im Blog von Günter Born vernünftige Erklärungen, Zusammenfassungen und den aktuellsten Stand zu den massiven Problemen mit den Sicherheitsupdates des Microsoft Patchday vom 11.02.2022 zu geben. Vielen Dank von meiner Seite für diese gute Arbeit! Und der Weltkonzern Microsoft sollte sich fragen, warum das eigene Security Team so etwas nicht geschafft hat.

Sicherheitslücke Log4Shell CVE-2021-44228

Vor einer Woche hat das BSI zum ersten mal die Warnstufe Rot ausgerufen. Durch die Sicherheitslücke Log4Shell CVE-2021-44228 im weit verbreiteten Framework Log4J sind potenziell fast alle Java-Anwendungen angreifbar. Log4J ist der De-facto-Standard für das Loggen von Java-Anwendungen. Deshalb sind weltweit sehr viele Anwendungen betroffen.

Für mich bedeutete die Sicherheitslücke jetzt erst mal eine anstrengende Arbeitswoche. Es galt alle Java-Anwendungen zu identifizieren, für die ich verantwortlich bin und das ist eine große Menge. Danach musste ich rausfinden, ob die entsprechende Anwendung tatsächlich Log4J verwendet. Und zu guter letzt musste ein Update eingespielt werden, sofern dies der Fall war.

Inzwischen habe ich alle Anwendungen überprüft und kann beruhigt Weihnachten feiern. Dazu bin ich wie folgt vorgegangen.

Wie findet man raus, ob eine Software betroffen ist?

Informationen des Herstellers

Informationen des Herstellers oder Programmierers sind natürlich der einfachste und beste Weg, um die Anfälligkeit eines Programms für diese Sicherheitslücke zu überprüfen. Ich persönlich habe bei betroffenen Anwendungen die folgenden Webseiten der Hersteller dazu genutzt:

Liste der Betroffenen Anwendungen auf GitHub

Sollte man bei Hersteller oder Programmierer solche Informationen nicht direkt finden, gibt es eine weitere Möglichkeiten, um diese zu feinden. Der französische Sicherheitsspezialist SwitHak pflegt bei GitHub eine Liste mit Aussagen der Hersteller die betroffen sind. Sofern eigene Anwendungen auf dieser Liste aufgeführt sind kommt man über einen Link zu den jeweiligen Informationen.

log4j-detector

MergeBase hat auf gitlab das Programm log4j-detector veröffentlicht, mit dessen Hilfe man nach verwundbaren Versionen von Log4J innerhalb von Java-Anwendungen suchen kann. Wenn man dieses auf dem Server mit einer Anwendung laufen lässt, durchsucht es alle Java Classen und meldet einem, wenn es dort eine verwundbare Version von Log4J findet.

Netzwerkscann

Eine weitere Möglichkeit für das aufspüren von verwundbaren Log4J Lücken ist das Scannen der Serverdienste über das Netzwerk mittels eines Vulnerability Scanners. Einer der bekanntesten Vulnerability Scanners ist OpenVAS von Greenbone, welchen ich für diesen Scann verwendet habe. Wie man dem Forumsbeitrag Testing for CVE-2021-44228 (Log4j/Log4Shell vulnerability) entnehmen kann, kann diese die Log4J Lücke auch bereits finden.

Um OpenVAS von Greenbone zum scanne zu verwenden, habe ich mir diesen schnell auf einer virtuellen Maschine mit Kali Linux installiert. Wie dies geht schildert der Blogbeitrag OpenVAS on Kali GNU/Linux Part 1: How to install OpenVAS von Staf Wagemakers.

Debian: Upgrade von 10 (Buster) auf 11 (Bullseye)

Am 14. August 2021 wurde Debian 11 (Bullseye) veröffentlicht. Dieser Artikel erläutert kurz, was zu tun ist, um ein Upgrade von Version 10 (Buster) auf Version 11 (Bullseye) bei einer bestehenden Installation durchzuführen. Im Prinzip ist das vorgehen dabei seit Jahren gleich. Schon bei dem Upgrade von Version 6.0 (Squeeze) auf Version 7.0 (Wheezy) war das Vorgehen nahezu identisch. Lediglich das aptitude wurde inzwischen durch apt ersetzt.

Datensicherung

Als erstes sollte das bestehende System mit einer Datensicherungssoftware gesichert werden. Dazu kommen eine ganze Reihe von Programmen wie cpio, tar, amanda oder rsnapshot infrage. Nähere Infos zu Backupsoftware unter Linux kann man in meinem Artikel Backup-Software für Linux nachlesen.

Danach sollte eine Liste der Installierten Software-Pakete erstellt werden, damit man im Notfall wieder ein System mit identischer Software installieren kann. Eine Anleitung dazu ist in meinem Artikel Ubuntu/Debian: Die gleiche Software auf einem neuen Computer installieren zu finden.

Einspielung aller Updates für das bestehende Debian

Bevor das eigentliche Upgrade auf die Version 11.0 gemacht wird sollten alle Updates für die alte Version eingespielt werden. Dazu muss zunächst die source-list aktualisiert werden:

sudo apt update

Danach können die Updates installiert werden:

sudo apt upgrade

Anpassen der sources-list

Damit die neuen Pakete gefunden werden, muss in der source-list das Wort buster gegen bullseye getauscht werden. Die source-list befindet sich in der Datei /etc/apt/sources.list. Die Datei sollte nach den Änderungen etwa wie folgt aussehen:

deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://ftp.debian.org/debian bullseye-backports main

Upgrade
Nun muss erneut die source-list aktualisiert werden:

sudo apt update

Zum Schluss wird dann der Rest der Pakete aktualisiert:

sudo apt full-upgrade

Während der Aktualisierung der einzelnen Software-Pakete wird dann ab und zu noch die ein oder andere Frage gestellt, bevor der abschließende Neustart fällig wird. Nach dem Neustart ist das Upgrade abgeschlossen.

Synology Diskstation Manager 7.0

Endlich ist die bereits sehnsüchtig erwartete Version 7.0 des DSM (DiskStation Manager) von der Firma Synology erschienen.

Für diejenigen von Euch die das DSM nicht kennen: Der DSM ist das Betriebsystem für die NAS Systeme der Firma Synology. Es beinhaltet eine Weboberfläche und diverse Anwendungen für die Verwaltung von Daten wie Dateien, Fotos, Videos, usw.

Bei der Version 7 verspricht der Hersteller das bislang größte Update für sein Betriebssystem. Dies war allerdings auch dringend nötig, da die Version 6.0 jetzt bereits vor mehr als 4 Jahren veröffentlicht wurde. Sie sollte eigentlich auch schon viel früher erscheinen. Synology hatte sich aber wiederholt entschieden, den Erscheinungstermin zu verschieben. Gerade bei einer Software für ein NAS (Network Attached Storage) ist dieses Vorgehen sicherlich auch sinnvoll, wenn die Software noch nicht wirklich stabil läuft. Schließlich kann eine Fehlfunktion hier auch immer gleich zu einem sehr unschönen Datenverlust führen.

Was sind die Neuerungen bei Version 7.0?

Das Motto des Launch-Events lautete “Smart. Simple. Reliable“. Damit unterstreicht Synology, dass neben diversen internen Erneuerungen und Verbesserungen auch die Oberfläche grundlegend überarbeitet und die Stabilität verbessert wurde. Die neue Benutzeroberfläche soll ein flüssigeres und intuitiveres Arbeiten ermöglichen. Zudem wurde auch der Speicher-Manager optisch aufgefrischt und hinsichtlich der Arbeitsgeschwindigkeit optimiert. Eine neue Live-Ansicht der Systemauslastung und das zentrales Analyse-Tool “Active Insight” liefern deutlich detaillierte Informationen und werden die Administration deutlich vereinfachen. Die vielen Apps für Fotos, Musik und Videos wurden zu zwei Apps zusammengefasst und um viele neue Funktionen wie automatische Zusammenstellung von Alben und Sortierung nach erkannten Personen erweitert.

Wie wird das Update eingespielt?

Der DSM 7.0 läuft auf allen Modellen ab dem Jahr 2015. Falls Ihr das Update installieren möchtet, findet Ihr unter folgendem Link auf der Synology Seite: DSM7. Zudem erkläre ich in dem folgenden Video im Detail, wie man seine Synology aktualisiert. Getestet habe ich das Update auf meiner bereits 2017 erworbenen DS416play, über die ich in diesem Blog in dem Artikel “Test einer Synology DS416play mit DSM 6.1” bereits berichtet hatte.

Debian: Upgrade von 6.0 (Squeeze) auf 7.0 (Wheezy)

Ein Upgrade eines Debian Systems von Version 6.0 (Squeeze) auf Version 7.0 (Wheezy) ist so simpel geblieben wie das vorherige Upgrade. Ich habe das Upgrade für diverse Server wie folgt durchgeführt.

Datensicherung
Als erstes sollte das bestehende System mit einer Datensicherungssoftware gesichert werden. Dazu kommen eine ganze Reihe von Programmen wie cpio, tar, amanda oder rsnapshot infrage. Nähere Infos zu Backupsoftware unter Linux kann man in meinem Artikel Backup-Software für Linux nachlesen.

Danach sollte eine Liste der Installierten Software-Pakete erstellt werden, damit man im Notfall wieder ein System mit identischer Software installieren kann. Eine Anleitung dazu ist in meinem Artikel Ubuntu/Debian: Die gleiche Software auf einem neuen Computer installieren zu finden.

Einspielung aller Updates für das bestehende Debian
Bevor das eigentliche Upgrade auf die Version 6.0 gemacht wird sollten alle Updates für die alte Version eingespielt werden. Dazu muss zunächst die source-list aktualisiert werden:

aptitude update

Danach können die Updates installiert werden:

aptitude upgrade

Anpassen der sources-list
Damit die neuen Pakete gefunden werden, muss in der source-list das Wort lenny gegen squeeze getauschen werden. Die source-list befindet sich in der Datei /etc/apt/sources.list. Die Datei sollte nach den Änderungen etwa wie folgt aussehen:

deb http://ftp.de.debian.org/debian/ wheezy main
deb http://ftp.de.debian.org/debian/ wheezy contrib
deb http://ftp.de.debian.org/debian/ wheezy non-free
deb-src http://ftp.de.debian.org/debian/ wheezy main

# Security-Updates
deb http://security.debian.org/ wheezy/updates main contrib
deb-src http://security.debian.org/ wheezy/updates main contrib

Upgrade
Nun muss erneut die source-list aktualisiert werden:

aptitude update

Danach werden zuerst die Update-Werkzeuge aktualisiert:

aptitude install apt dpkg aptitude

Zum Schluss wird dann der Rest der Pakete aktualisiert:

aptitude full-upgrade

Während der Aktualisierung der einzelnen Software-Pakete wird dann ab und zu noch die ein oder andere Frage gestellt, bevor der abschließende Neustart fällig wird. Nach dem Neustart ist das Upgrade abgeschlossen.

(SP1)-Installationsfehler: 0x800F0A13 bei der Installation des SP1 für Windows 2008R2

Ich bin extra am Wochenende in die Firma gefahren, um eine Datensicherung eines Windows 2008R2 Servers zu machen und das ServicePack 1 zu installieren. Leider stieg die Installation gleich am Anfang mit folgender Meldung aus:

(SP1)-Installationsfehler: 0x800F0A13

Laut Microsoft Hilfe und Support kann der Fehler durch folgenden, vier Gründe verursacht werden, die bei mir aber nicht zutrafen:

  1. Während des Setup wird die Systempartition nicht automatisch eingebunden bzw. für Windows zugänglich gemacht.
  2. Die Festplatte, auf der sich die Systempartition befindet, wurde vor der Installation von SP1 entfernt.
  3. Windows wird in einem Storage Area Network (SAN) ausgeführt, und der Zugriff auf die Systempartition wurde deaktiviert.
  4. Ein Tool zur Datenträgerverwaltung eines anderen Softwarehersteller wurde zum Kopieren (oder Klonen) des Datenträgers oder der Partition verwendet, auf dem bzw. der SP1 installiert werden soll.

Nachdem ich Google befragt habe, bin ich aber auch auf einen Post im Technet-Blog von joscon gestoßen, der empfahl zuerst das Systemupdate-Vorbereitungstool auszuführen. Falls die Installation danach immer noch nicht funktioniert, gibt es dort auch noch einige andere Lösungsvorschläge. Jedoch keiner dieser Vorschläge hat geholfen.

Die Lösung brachte letztendlich ein Heise Artikel. Nachdem ich wie in den Artikel beschrieben die aktive Partition gesetzt hatte und den Server neu gebootet hatte, funktionierte die Installation des ServicePacks.

Update:
Bei einem anderen Windows 2008R2 Server lief die Installation erst, nachdem ich der vom System reservierten 100 MB Partition einen Laufwerksbuchstaben gegeben hatte. Dazu wurde im Technet Forum geraten.