Microsoft Produkte ohne Sicherheits-Updates

[time_until date="14.01.2020"]

#Microsoft wird keine Sicherheits-Updates mehr für die folgenden Betriebssysteme und Produkte liefern:

• Alle Produkte, die die Jahreszahl 2010 im Namen haben (#Exchange 2010, #Office 2010)
• Produkte mit 2008 R2 im Namen: #Windows Server 2008 R2
• Windows 7

Wie bereits im Detail-Artikel beschrieben, besteht kurzfristig Handlungsbedarf und diese Software und Betriebssysteme müssen ersetzt werden.

(Post ID:1423)

Windows Updates mit neuer Verschlüsselung

Alle Server und Arbeitsplätze mit #Windows 7 Service Pack 1 und Windows #Server 2008 R2 SP1 müssen bis zum 13. August die „Servicing Stack Updates“ KB4474419 und KB4490628 installiert bekommen, ansonsten erhalten diese beiden Betriebs-Systeme bereits im September 2019 keine Sicherheits-Updates mehr.

Bekanntlich ist für diese beiden Betriebs-Systeme das Ende des erweiterten Supports und damit der Sicherheits-Patches ohnehin für Januar 2020 festgelegt. Ohne das oben genannte Update verkürzt sich die Zeit, in der Sie auf Windows 10 Pro/Enterprise bzw. Windows Server 2016 oder 2019 umstellen können, um weitere vier Monate.

Zusätzlich sind auch Windows Software Update Services (WSUS 3.0) betroffen. Die Software stellt keine Updates mehr bereit, wenn sie nicht auch auf den aktuellen Stand gebracht wird. Für WSUS 3.0 ist das Update KB4484071 am 12.03.2019 erschienen. Dieses Update muss manuell aus dem Windows Update-Katalog heruntergeladen und installiert und genehmigt werden.

Handlungsbedarf

Prüfen Sie bitte, ob oben genannte Updates installiert sind. Wenn nicht, oder Sie uns mit der Prüfung und Installation beauftragen möchten, nehmen Sie bitte Kontakt über einen Vorgang mit Bezug auf diesen Artikel mit uns auf.

Hintergrundinformation

Microsoft stellt ihren Update-Mechanismus auf SHA-2 verschlüsselte Pakete um. Dies ist bereits im Vorfeld bei neueren Betriebs-Systemen wie Windows 10 und Windows Server 2016/19 geschehen. Da darüber hinaus lediglich Windows 7 und Server 2008 R2 noch kein Support-Ende haben, müssen diese Plattformen aktualisiert werden.

Für Windows Server 2008 und Windows Vista ist das Update zwar auch erhältlich, beide bekommen aber bereits seit 2018 keine Sicherheits-Updates mehr. Wer also noch „Vista-Server“ Windows Server 2008 im Einsatz hat, kann das Update zwar installieren, sollte aber lieber auf die oben genannten neuen Betriebs-Systeme wechseln.

Mittlerweile sind viele Softwareprodukte ohnehin nur unter den aktuell unterstützten Windows Umgebungen lauffähig (Windows 10 und Server 2016 oder 2019).

Details und Stichtage

WSUS 3.0 SP2:
Sicherheitsupdate für SHA2-Unterstützung 12.03.19 erschienen, SHA2 erforderlich am 16.06.19

WinServer2008SP2:
Sicherheitsupdate für SHA2-Unterstützung 09.04.19 u. 14.05.19 erschienen , SHA2 erforderlich am 16.07.19

Windows 7 SP1:
Sicherheitsupdate für SHA2-Unterstützung 12.03.19 erschienen, SHA2 erforderlich am 13.08.19

WinServer2008R2SP1: Sicherheitsupdate für SHA2-Unterstützung 12.03.19

erschienen, SHA2 erforderlich am 13.08.19

Mehr Informationen hier

(Post ID:1398)

RDP-Lücke BlueKeep in Windows wird aktiv genutzt

Warum zeitnahes Patchen so wichtig ist, zeigt sich mal wieder anhand der derzeit aktiv ausgenutzten BlueKeep Lücke im RDP-Protokoll aller Windows Versionen <8.1: In #Server 2008 R2 und Server 2012 (ohne R2), sowie in #Windows 7 wurde jüngst eine Sicherheitslücke geschlossen, die es ermöglichte, einem Angreifer volle Kontrolle über das Zielsystem zu erlangen und Schadcode auszuführen. #Microsoft stuft diese Lücke als kritisch ein. Nur wer zeitnah (mit WSUS Unterstützung oder direkt) alle Server und Arbeitsplätze der oben genannten Versionen patcht, ist sicher. (CVE-2019-0708) (Post ID:1394)

SHA2-Update für Windows Update und Server 2008 R2

Alle Server und Arbeitsplätze mit #Windows 7 Service Pack 1 und Windows #Server 2008 R2 SP1 müssen bis zum am 13. August das im April 2019 erschienene „Servicing Stack Update“ KB4493730 installiert bekommen, ansonsten erhalten diese beiden Betriebs-Systeme bereits im September 2019 keine Sicherheits-Updates mehr.

Bekanntlich ist für diese beiden Betriebs-Systeme das Ende des erweiterten Supports und damit der Sicherheits-Patches ohnehin für Januar 2020 festgelegt. Ohne das oben genannte Update verkürzt sich die Zeit, in der Sie auf Windows 10 Pro/Enterprise bzw. Windows Server 2016 oder 2019 umstellen können, um weitere vier Monate.

Handlungsbedarf

Prüfen Sie bitte, ob das Update 4493730 installiert ist und installieren das Update.

Hintergrundinformation

Microsoft stellt ihren Update-Mechanismus auf SHA-2 verschlüsselte Pakete um. Dies ist bereits im Vorfeld bei neueren Betriebs-Systemen wie Windows 10 und Windows Server 2016/19 geschehen. Da darüber hinaus lediglich Windows 7 und Server 2008 R2 noch kein Support-Ende haben, müssen diese Plattformen aktualisiert werden.

Für Windows Server 2008 und Windows Vista ist das Update zwar auch erhältlich, beide bekommen aber bereits seit 2018 keine Sicherheits-Updates mehr. Wer also noch „Vista-Server“ Windows Server 2008 im Einsatz hat, kann das Update zwar installieren, sollte aber lieber auf die oben genannten neuen Betriebs-Systeme wechseln.

Mittlerweile sind viele Softwareprodukte ohnehin nur unter den aktuell unterstützten Windows Umgebungen lauffähig (Windows 10 und Server 2016 oder 2019).

(Post ID:1389)

Hyper-V Replika - genial aber mit versteckten Fallen

Seit Server 2012 R2 ist die Funktion, virtuelle Maschinen auf einen anderen Hyper-V-Host auch über WAN-Leitungen (oder eben über das lokale Netzwerk) zu replizieren, funktionsfähig und verfügbar.

Für alle, die das Vorhaben haben, bei Hardware-Ersatz-Investition den alten Server als Replika Ziel zu verwenden, hat Microsoft ganz am Ende der Einrichtung eine nette Falle eingebaut: Das Ziel-Betriebssystem (also der Host, auf den repliziert wird) muss das gleiche Betriebssystem haben wie der Quellhost.

Möchte man also einen alten Server für diesen Zweck nutzen, ist es notwendig, eine Betriebssystem-Lizenz des neuen Servers auch für den alten zu erwerben. Da die Host-Betriebssysteme meist aus kaufmännischen Gründen als OEM-Version erworben werden, bedeutet das den Neukauf der Windows Server Lizenz (und je nach Anzahl der replizierten Maschinen auch der additional Core Licenses).

Seit Server 2016 sind im Basis-Paket 16 Cores (virtuelle Prozessoren) lizensiert. Das entspricht einer 2-Prozessor-Maschine mit jeweils einem 8-Core XEON Prozessor.

Hat man die Lizenz für den Replika-Server erworben, müssen beide Hosts (Quell-Host und Ziel-Host noch in der selben Domäne Mitglied sein). Solange man nur im lokalen Netzwerk repliziert, kann man sich die Verschlüsselung mit Zertifikaten sparen und verwendet stattdessen die Kerberos-Authentifizierung des Active Directory, damit sich die Hosts verstehen.

Wer den Replika-Host hiter einer WAN-Leitung betreibt, sollte ein VPN als äußere Schutzschicht verwenden. Auch in diesem Fall müssen nicht zwingend Zertifikate eingesetzt werden.
Spätestens bei Übertragung der Replika-Daten über das Internet, sind HTTPS-Verschlüsselung und Zertifikate erforderlich, um gesetzlichen Vorschriften zu genügen.

Die Einrichtung selbst ist dann ein Klacks. Replikaserver empfangsbereit machen, Quell-Server die virtuellen Maschinen, die man benötigt über die rechte Maustaste per Assistent für die Replizierung aktivieren. Der gängige Praxiswert ist die Replikation der Deltas alle 15 Minuten.

Hardware-Virtualisierung mit UEFI und GPT- Disks

zur Virtualisierung von Hardware gibt es aus dem Hause Microsoft zwei Programme:

1) Disk2VHD - der Klassiker, erzeugt eine VHD oder VHDX aus einem physikalischen System
2) Microsoft Virtual Machine Converter (MSVC), konvertiert von vmware oder Hardware nach Hyper-V

Ausgangssituation

Beide Lösungen haben folgendes Problem:

Solange die Quellmaschine das klassische Partitionierungsschema mit Master Boot Record (MBR) hat, ist alles in Ordnung. Ist die Quellmaschine auf GPT Partitionierungsschema (UEFI-Standard, wenn keine BIOS Emulation genutzt wird) formatiert, scheitern beide Tools.

Nummer 2 scheitert schon beim Beginn und erstellt erst gar keine VHDX auf dem Zielsystem

Nummer 1 erstellt einen Volume Snapshot und eine VHDX am angegebenen Pfad. Diese lässt sich jedoch nicht auf der neuen Hyper-V-Maschine starten. Weder in Gen1 VM, noch in Gen2 VM wird ein Bootsektor bzw. die UEFI Bootpartition gefunden.

Konvertierung in MBR ohne Datenverlust

Die nach Praxistests am Besten funktionierende Methode (ohne Datenverlust der Quellmaschine) ist es derzeit, mit einem kostenlosen Werkzeug:

Minitool Partition Wizard Free die erzeugte VHDX von GPT in MBR umzuwandeln und dann mit einer Recovery-CD in der Windows-Partition einen Bootsektor anzubringen.

Legt man dann eine Generation 1 VM in Hyper-V an, startet diese, erkennt die virtuelle Hardware neu und alle Einstellungen bleiben erhalten.

Achtung! Bei der Installation des Tools aufpassen, da es Adware unterjubeln möchte. Den Lizenzvertrag der Zusatzsoftware daher ablehen (Haken rausnehmen). Außerdem läuft das Tool in der kostenlosen Version nur auf Client Windows Betriebssystemen (Windows 10)

Vorgehensweise

• Die VHDX auf einen Windows PC kopieren und per Doppelklick "mounten".
• Nun den Mini-Partition Wizard aufrufen und auf der "Disk", die die VM darstellt alle Partitionen löschen, außer der Windows Systempartition und ggf. der Datenpartition. Oben links "Ausführen" am Ende nicht vergessen.
• Rechte Maustaste auf die Disk und Convert GPT to MBR auswählen, oben links wieder Ausführen.
• Die verbleibenden Partitionen nach links verschieben, so dass das Systemlaufwerk ganz am Anfang erscheint.
• Die VHDX auswerfen (Im Explorer auf eines der logischen Laufwerke klicken, rechte Maustaste, Auswerfen)
• Nun die Disk auf den Hyper-V-Host kopieren und eine Gen1- Maschine erzeugen, die diese Disk verwendet
• Über Medien im Hyper-V-Manager eine ISO mit dem passenden Betriebssystem mounten (z.B. Windows Server 2016)
• Die virtuelle Maschine über diese ISO starten (Recovery CD) und in die Computer Reparaturoptionen zur Befehlszeile
• Die folgenden Befehle eingeben, um einen MBR Bootsektor zu erzeugen:
  • diskpart
  • list disk
  • select disk 0
  • list partition
  • select partition 1
  • active
  • exit

bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

* Reboot und erneut von der Recovery CD starten in die Eingabe-Aufforderung:
cd recovery
startrep.exe

(Post ID:1382)

Wie bekommt man die amtliche Zeit im Netzwerk

In der Windows Domäne gelten strenge Regeln für die Uhrzeit. Dadurch kann sich ein Client nicht mehr an der Domäne anmelden, wenn seine Uhrzeit stark von der Server-Uhrzeit abweicht.
Optimal ist daher, den führenden Domänen-Controller mit externer, amtlicher Uhrzeit zu versorgen. Die weiteren Domänen-Controller müssen so eingestellt sein (werden), dass sie die Uhrzeit vom Domänen-Controller beziehen.
Damit das Ganze funktioniert, muss auf der Firewall der Zugriff auf die amtlichen Zeitserver erlaubt werden. Basis bildet hier das sogenannte NTP Protokoll.
Wenn man am ersten Domänen-Controller die folgenden Befehle einstellt - in einer Eingabeaufforderung (Administrator), wird die Serverzeit amtlich:

w32tm /config /update /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8 3.pool.ntp.org,0x8" /syncfromflags:MANUAL
w32tm /config /reliable:yes
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync /rediscover

(Post ID:1379)

Exchange Server angreifbar

Aktuell existieren #Sicherheitslücken in allen #Exchange Versionen, die es Angreifern ermöglicht, sich administrative Berechtigungen zu erschleichen und z. B. Mails umzuleiten. Da die Lücke im Active Directory (EWS) verankert ist und über den Internet-Zugang auf den Exchange (OWA) erreichbar ist, sollten Sie umgehend handeln und die Lücke schließen (lassen).

Bis ein Update von Microsoft verfügbar ist, lässt sich die Lücke durch Löschen eines Registrierungs-Schlüssels auf dem Exchange Server schließen:

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f

Wenn Sie die Lücke nicht selbst schließen möchten oder können, beauftragen Sie uns bitte mit einem (kostenpflichtigen) Vorgang beauftragenund wir sichern Ihren Exchange Server ab.

Quelle: CVE-2018-8581 | Microsoft Exchange Server Elevation of Privilege Vulnerability

(Post ID:1249)