Microsoft hat heute neue Sicherheitsupdates für Exchange Server 2016 und Exchange Server 2019 veröffentlicht. Das Update schließt die Remote Execution Schwachstelle CVE-2023-36778 und bietet eine bessere Lösung für die Schwachstelle CVE-2023-21709 aus dem August. Mit dem August Sicherheitsupdate gab es ja Probleme und das Update wurde zeitweise zurückgerufen. Das Update aus dem Oktober für CVE-2023-36434 für Windows Server liefert nun eine bessere Lösung als das IIS Token Cache Module zu deaktivieren. Dies ist mit dem August Update geschehen und kann zu Leistungseinbußen geführt haben. Der IIS Token Cache kann daher nach der Installation der Windows Updates wieder aktiviert werden.
Hier geht es direkt zu den Updates:
Nach der Installation der Oktober Windows Updates kann das IIS Token Cache Modul mit dem folgenden Befehl wieder aktiviert werden:
New-WebGlobalModule -Name "TokenCacheModule" -Image "%windir%\System32\inetsrv\cachtokn.dll"
Hier noch eine Grafik vom Exchange Team Blog, welche den Update Prozess verdeutlicht:
Quelle: Released: October 2023 Exchange Server Security Updates
Interessantes Problem, bei einem unserer Exchange Server2019 lief zwar das Oktober SU letzte Woche fehlerfrei durch und es schien zunächst auch alles wie gewohnt zu funktionieren, heute habe ich dann aber erstaunt feststellen müssen, dass weder ECP noch OWA funktionierten, beim ECP wurde die Seite in einer Art Rohformat angezeigt und mit F12 im Browser sah man, dass dutzende Dateien nicht gefunden werden konnten mit Error 404, beim OWA kam einfach nur eien Fehlerseite mit Error 500. Nach einer kurzen Suche bin ich dann in einem anderen Forum auf einen Hinweis gestossen, dort hatte ein Admin berichtet, dass in seinem Fall die NTFS-Zugriffsrechte auf die Ordner ClientAccess\ECP und ClientAccess\OWA sowie auf dem Order FrontEnd nicht mehr stimmten, bei Ihm fehlte die Gruppe Authenticated Users mit der Berechtigung Read.
Als ich dies in unserem Fall prüfte, stellte ich fest, dass diese Berechtigung bei uns zwar korrekt vorhanden war, aber, die Ordner \ClientAccess\ecp\15.2.1258.27, \ClientAccess\owa\15.2.1258.27 und \ClientAccess\owa\prem\15.2.1258.27 so gut wie leer. Ich habe dann einfach mal die fehlenden Ordner und Dateien von einem andere Exchange 2019, der das Problem nicht hat, rüber kopiert und seither laufen ecp und owa wieder einwandfrei.
Da alles andere soweit funktionierte und es „nur“ um ecp und owa ging, hab ich es einfach mal riskiert.
Hoffentlich fällt mir das dann beim nächsten CU und/oder SU nicht auf die Füsse :-)
Evtl. hilft es ja auch jemand anderem.
2x Exchange 2019 DAG Security Patch ohne Probleme.
Es hat uns „nur“ einen Server nach den Windows Updates zerschossen..Dort ging gar nichts mehr und haben ihn nur über Umwege wieder zum laufen gebracht.
Uns hat der Security Patch auch nen Exch 2019 zerlegt. Über welche Umwege hast du es wieder zum laufen gebracht?
Ich habe die Dienste mit dem PS-Script von https://www.alitajran.com/restart-exchange-services-powershell-script/ wiederherstellen können. Danach lief alles wieder normal. Dann habe ich den Patch nochmal manuell installiert und nun lief es sauber durch und der HealthChecker Report sieht auch gut aus.
Wir hatten andere Probleme, keine mit dem Security Patch.
Nach Windows Updates kam die VM nicht wieder und war platt
I installed the windows update and than the exchange update it tooks 15 minutes and works successfully
Exchange 2016 CU23 auf Windows Server 2016, bisher alles erfolgreich und unauffällig nach dem Update.
Exchange 2019 CU13 auf virtualisierten Server 2022:
Update zwar langsam, aber erfolgreich
Beim angesprochenen Windows-Update (KB5031364/CVE-2023-36434) werden noch zwei Registry-Keys zum Schutz vor CVE-2023-44487 genannt, wo müsste man diese setzen und machen diese auf einem Exchange-Server Sinn?
Wenn du http/2 aktiv hast, dann kannst du es abschalten und wärest nicht mehr potentiell betroffen.
Es ist bedauerlich, wie stark die Website von Frankys mit Werbung überladen ist! Irgendwo muss es doch auch eine Grenze geben, was die Werbung angeht…
Was für Werbung?
Bist du etwa Masochist und benutzt keinen Werbeblocker?
Was zahlst du den für diese überragende Webseite hier, dass du dir das Recht rausnimmst dich zu beschweren? Man hat immer die Wahl woanders hin zu gehen wenn es nicht passt.
Exchange 2016 CU23 auf Server 2016:
Update erfolgreich
auf über 20 (deutschen) Exchange-Servern gestern Abend installiert. Per Powershell ausgeführt. Nach Neustart ist alles ohne zicken einwandfrei durchgelaufen. Token Cache aber nicht angefasst, da kein Bedarf. Kein einzelner hat Probleme gemacht.
Alles gut gelaufen:
On Premise, virtualisiert (ESXi)
Server 2019 Standard (DE)
Exchange 2019 (DE) CU13 (SU von August wurde nur in V2 installiert, war später dran)
HealthChecker soweit ok – er meckert „kaum was“
Antivirus manuell gestoppt
CMD als Admin und UpdateFile KB5030877 gestartet
Installationsdauer: ca. 10 Minuten
Neustart nach Aufforderung des Installers
Ein paar Minuten später meldet mein lokales Outlook wieder Konnektivität.
Test Intern nach Extern und retour erfolgreich (dauert auch noch die ein oder andere Minute)
IIS Token Cache wieder geladen mit dem Befehl vom Artikel oben
HealthChecker geprüft – passt!
Vielen Dank an Franky für diesen Blog, die ständigen Infos und auch hilfreichen Kommentare hier :)
Deutscher EX2016 CU23 auf Server 2016 lief ebenfalls problemlos durch. Nur ein Dienst startet leider nicht mehr bzw. stürzt direkt wieder ab.
Folgendes habe ich bereits rausgefunden:
Get-ServerHealth -Identity ‚EXCHANGE‘ -HealthSet ‚Search‘
Server State Name TargetResource HealthSetName AlertValue ServerComp
onent
—— —– —- ————– ————- ———- ———-
EXCHANGE NotApplicable SearchQueryStxMon… Mailbox Database … Search Unhealthy None
EXCHANGE NotApplicable HostControllerSer… HostControllerSer… Search Unhealthy None
Am Index scheint es nicht zu liegen:
Get-MailboxDatabaseCopyStatus
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
—- —— ——— ———– ——————– ————
Mailbox Database 1650794868\EXCHANGE Mounted 0 0 Healthy
2 Fehler wiederholen sich im System:
Der Dienst „Microsoft Exchange Search Host Controller“ wurde unerwartet beendet. Dies ist bereits 2841 Mal vorgekommen. Folgende Korrekturmaßnahmen werden in 30000 Millisekunden durchgeführt: Neustart des Diensts.
Der zugrunde liegende Transport für [::]:3800 kann nicht gebunden werden. Möglicherweise enthält die Liste nur zum Abhören von IP einen Verweis auf eine Schnittstelle, die gegebenenfalls auf diesem Computer nicht vorhanden ist. Das Datenfeld enthält die Fehlernummer.
Bin noch am Suchen…. hat jemand ein ähnliches Problem?
Also ich denke das Problem hat nichts mit dem Update zu tun. Hier habe ich einen Lösungsansatz gefunden.
https://docs.nospamproxy.com/Server/14/Suite/de-de/Content/known-errors/Dienste-%20starten-nicht-weil-Bindung-auf-http-6060-nospamproxy-nicht-funktioniert.htm
Lösung 1 hat bei mir geholfen. Ich bin aber noch am prüfen, warum es zu diesem Problem kam. Hab eventuell das nicht komplett deaktiviert ipv6 im verdacht.
SU Update auf Exchange 2019 manuell auf Server 2022 hat funktioniert. Healthchecker sagt nun:
TokenCacheModule loaded: False
The module wasn’t found and as a result, CVE-2023-21709 and CVE-2023-36434 are mitigated. Windows has released a Security Update that addresses the vulnerability.
It should be installed on all Exchange servers and then, the TokenCacheModule can be added back to IIS (by running .\CVE-2023-21709.ps1 -Rollback).
More Information: https://aka.ms/CVE-2023-21709ScriptDoc
hat das bei jemanden funktioniert?
Siehe unten. ;)
ja bei dir nicht
ist sowieso nicht notwendig – We disabled IIS Token Cache as a part of August 2023 update. Does Exchange require IIS Token Cache to run? Must we re-enable it?
Re-enabling IIS Token Cache after installing the update for CVE-2023-36434 is optional. Exchange Server does not require IIS Token Cache. We wanted to call the CVE-2023-36434 update because we heard from some customers who had concerns about performance of their clients after IIS Token Cache is disabled. If you already disabled IIS Token Cache and want to keep it disabled, Exchange Server does not require it. But please make sure to install all Windows Updates anyway.
Wir haben den IIS-Token-Cache im Rahmen des Updates vom August 2023 deaktiviert. Benötigt Exchange für die Ausführung den IIS-Token-Cache? Müssen wir es wieder aktivieren?
Das erneute Aktivieren des IIS-Token-Cache nach der Installation des Updates für CVE-2023-36434 ist optional. Exchange Server erfordert keinen IIS-Token-Cache. Wir wollten das Update CVE-2023-36434 aufrufen, weil wir von einigen Kunden gehört haben, die Bedenken hinsichtlich der Leistung ihrer Clients hatten, nachdem der IIS-Token-Cache deaktiviert wurde. Wenn Sie den IIS-Token-Cache bereits deaktiviert haben und ihn deaktiviert lassen möchten, ist er für Exchange Server nicht erforderlich. Bitte stellen Sie jedoch sicher, dass Sie trotzdem alle Windows-Updates installieren.
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2023-exchange-server-security-updates/ba-p/3950647
Na Hauptsache du denkst dann beim der Installation des nächsten Exchangeservers dran, sonst hat man irgendwann mehrere Server mit unterschiedlichen Einstellungen und sucht sich ggf. nen Wolf bei potentiellen Problemen. Das war der Grund, warum ich das Token Cache Modul wieder aktiviert hab.
Hallo Norbert, da hattest du recht und mich überzeugt :-)
Ja, Ex2016 auf Server 2016. Die Meldung ist dann ebenfalls im HealthChecker Log verschwunden.
wenn man das Skript so ausführt –> ? .\CVE-2023-21709.ps1 -Rollback).
Ja. EMS starten und ins Verzeichnis mit dem Script wechseln, dieses ausführen wie du beschrieben hast. z.B.:
cd d:\scripts
.\CVE-2023-21709.ps1 -Rollback
Dann wird im selben Verzeichnis eine Debug Textdatei erstellt und am Ende steht bei mir:
Write-Progress Activity: ‚Adding TokenCachingModule‘ Completed: True
Sieht für mich okay aus. Muss anmerken das wir das Script damals auch aus dem Verzeichnis ausgeführt haben.
Hallo „nk“,
vielen Dank. Hat bei mir genauso funktioniert. Wichtig ist vielleicht, dass man das aktuelle Skript herunterlädt und nicht das alte vom August verwendet. Die Skripte sind auch unterschiedlich groß.
Mit dem aktuellen Skript und mit .\CVE-2023-21709.ps1 -Rollback sagt auch der Healtchecker alles in Ordnung :)
Sehr schön! Jetzt wo du es erwähnst hat sich mein Script vom August selbst aktualisiert nach dem ersten Aufruf (mit -Rollback) und ich durfte den Befehl erneut ausführen, eigentlich exakt wie das Healthchecker Script auch. Komisch, dass es bei dir nicht der Fall war.
Hauptsache es hat geklappt :)
Halllo „nk“.
ich hatte direkt das neue Skript herunterladen. :)
Hier:
Beim Kopieren durch das Update kam bei 10 von 29 dlls der Fehler, das er nicht in das FIP-FS\bin-Verzeichnis schreiben kann.
Ich habe die alten dlls dann manuell in ein neues Verzeichnis verschoben, dann klappte es.
Warum das Update die 10 alten dlls nicht überschreiben konnte, aber weitere 19 dann doch, ist mir rätselhaft. An fehlenden Rechten kanns nicht gelegen haben, denn dann hätte ich die auch nicht verschieben können.
Und dann hatte er den Dienst „Exchange Search Host Controller“ nicht wieder aktiviert, musste manuell gemacht werden.
Nach dem Neustart hat der Health Checker gemeckert, das er virtuelle Verzeichnisse unter „Bin Search Folder“ nicht finden kann.
Dadurch funktionierte ECP nicht mehr.
Dann nach MS-Anweisung die Pfade im IIS hardkodiert eingetragen, iis neu gestartet und es läuft!
So viel musste ich noch nie am Exchange nach einem Update (übrigens manuell gemacht) nacharbeiten.
Das Update hat mal wieder einen Ex 2016 zerschossen…. gleiches Drama wie vor 1-2 Monaten mit dem CU was zurückgenomme wurde.
Habe die Reparatur aufgegeben und restored.
Dienste waren alle nicht mehr startbar (obwohl die abhängigen Dienste liefen)
händiges installieren vom fehlgeschlagenem Update brach auch ab
Das Problemupdate mit dem Workaround, musste Deinstalliert werden, um weitere Upates zu installieren.
Vieleicht war das der Fehler, das Du das Problemupdate nicht erntfernt hast.
Kannst du das bitte ein wenig näher erläutern? ich glaube wir haben dasselbe Problem
Falls August SUv1 mit Workaround installiert wurde dann sollte SUv1 deinstalliert, Reboot, erstellter Account gelöscht und v2 installiert werden.
Gemäß: https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
also SU Update installieren und den Befehl eingeben. Kann mich nicht erinnern im August diesen Befehl vorher aktiviert zu haben ?!
Du musst den Befehl nur ausführen, wenn du in auch manuell im August ausgeführt hattest
„If you did not do anything to address CVE-2023-21709 yet: Install update for CVE-2023-36434 on all your Exchange Servers.“
D
Nein, das sollst du erst und nur machen, wenn du im August das Token Cache Module deaktiviert hast, und nachdem du jetzt die aktuellen Oktoberupdates für Windows Server installiert hast. Das Exchange SU hat damit nix zu tun.
Exchange 2019 auf Windows Server 2019 (deutsch) ohne Probleme.
Exchange 2019 auf Windows Server 2022 nach Installation bisher problemlos und alles unauffällig.
Deutscher EX2016 CU23 auf Server 2016 lief problemlos durch.
Restart verlief unauffällig. Bisher keine Unstimmigkeiten.
Gruß
Installation auf 3 Edges und 2 Mailboxservern (alles Exchange 2019) bisher problemlos durchgelaufen.
\CVE-2023-21709.ps1 -Rollback
hat bei mir übrigens nicht funktioniert, ich mußte die oben von Frank beschriebene Variante für jeden Server nutzen.
also diesen Befehl eingeben, wenn alle Updates installiert sind und man im August es deaktiviert hatte ?!
1
New-WebGlobalModule -Name „TokenCacheModule“ -Image „%windir%\System32\inetsrv\cachtokn.dll“
Na wer traut sich diesmal als erster drüber :-))
Der Exchange Team Blog und deren aktive Nutzer ;)