[English]Microsoft hat zum 9. August Sicherheitsupdates für Exchange Server 2013, Exchange Server 2016 und Exchange Server 2019 veröffentlicht. Diese Updates sind erforderlich, um Schwachstellen, die von externen Sicherheitspartnern gemeldet und durch die internen Prozesse von Microsoft gefunden wurden, zu schließen. Die Updates gelten für die nachfolgend genannten Exchange Server On-Premises-Installationen.
Anzeige
Die Sicherheitsupdates für Exchange Server vom August 2022 beheben Sicherheitslücken, die von Sicherheitspartnern gemeldet und durch die internen Prozesse von Microsoft gefunden wurden. Microsoft hat den Techcommunity-Beitrag Released: August 2022 Exchange Server Security Updates mit einer Beschreibung der Sicherheitsupdates veröffentlicht.
Es stehen Sicherheitsupdates für folgende Exchange-Server CU-Versionen zur Verfügung.
Mit den Updates werden die Microsoft Exchange Server Elevation of Privilege-Schwachstellen CVE-2022-21980, CVE-2022-24477 und CVE-2022-24516 geschlossen. Hier die komplette Liste der Schwachstellen:
Anzeige
- Microsoft Exchange Information Disclosure Vulnerability (CVE-2022-21979)
- Microsoft Exchange Server Elevation of Privilege Vulnerability (CVE-2022-21980)
- Microsoft Exchange Server Elevation of Privilege Vulnerability (CVE-2022-24516)
- Microsoft Exchange Server Elevation of Privilege Vulnerability (CVE-2022-24477)
- Microsoft Exchange Information Disclosure Vulnerability (CVE-2022-30134)
- Microsoft Exchange Information Disclosure Vulnerability (CVE-2022-34692)
Microsoft empfiehlt, diese Updates sofort zu installieren, obwohl noch keine aktiven Exploits in freier Wildbahn bekannt sind. Zu beachten ist, dass die Exchange Server auf das aktuelle CU aktualisiert werden, bevor die August 2022-Updates installiert werden (siehe obige Grafik und den Hinweis von Microsoft). Zur Prüfung kann das HealthChecker-PowerShell-Script von Microsoft verwendet werden.
Diese Sicherheitslücken betreffen Exchange Server. Exchange Online-Kunden sind bereits vor den in diesen SUs behandelten Sicherheitslücken geschützt und müssen außer der Aktualisierung aller Exchange-Server in ihrer Umgebung keine weiteren Maßnahmen ergreifen.
Windows Extended Protection aktivieren
In einer Ergänzung weist Microsoft darauf hin, dass Administratoren zum beheben einiger Schwachstellen, die im August 2022 geschlossen wurden, den erweiterten Windows-Schutz (Windows Extended protection) auf Ihren Exchange-Servern (in IIS)aktivieren müssen. Zur Aktivierung dieser Funktion stellt Microsoft ein Skript bereit (die aktuelle Version findet sich hier). Vor der Aktivierung der Extended Protection (EP) auf Produktivsystemen sollte geprüft werden, ob die Voraussetzungen auch erfüllt sind. Die Aktivierung von Extended Protection (EP) wird nur von bestimmten Exchange-Versionen unterstützt. Problem werden auch die zahlreichen "Known Issues" werden, die in den Voraussetzungen genannt werden.
Ähnliche Artikel:
Sicherheitsupdates für Exchange Server (Januar 2022)
Sicherheitsupdates für Exchange Server (8. März 2022)
Exchange Server April 2022 CU (20.4.2022)
Kumulative Exchange Updates Juni 2021 veröffentlicht
Probleme mit Exchange März 2022-Updates
Microsoft 365-Bug: Mails aus Exchange Online und Outlook landen im Spam-Ordner
Microsoft Exchange Admin-Portal wegen ausgelaufenem Zertifikat blockiert
Exchange Update-Fehler und -Infos (13. April 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Benutzerdefinierte Attribute in ECP nach CU-Installation (Juli 2021) nicht mehr aktualisierbar
Basic Authentication in Exchange Online wird ab Oktober 2022 eingestellt
Exchange: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Anzeige
ein toller patch, den die allgemeinheit nun testen soll… schämen sich die nicht bei microsoft. windows extended protection werden zig admins nicht aktivieren können, weil sie ansonsten in die known issues fallen.
wozu macht man sowas?
Laut https://www.frankysweb.de/neue-sicherheitsupdates-fuer-exchange-server-august-2022/
keine Probleme mit Exchange Update.
Wie kann man den die im Bild gezeigten Versionen von ExChange auslesen?
So gibt es eine andere Nummer (aus Outlook):
Debug.Print Session.ExchangeMailboxServerVersion
Ich mache das für gewöhnlich direkt auf dem Exchange Server in einer Powershell mit folgendem Befehl:
(get-item $env:ExchangeInstallPath\bin\exsetup.exe).VersionInfo
Hmm… und wie siehts jetzt mit Exchange Server 2016 CU21 aus?!
Das "2022 H1 CU" ist wohl auch an mir vorübergegangen…
Gibts da schon Erfahrungen von 2016 CU21 –> 2022 H1 CU ??
Ich bekomm schon wieder Magenkrämpfe nur beim dran denken….
Exchange Server 2016 CU 21 erhält gar kein Sicherheitsupdate mehr.
Es erhalten immer nur die letzten beiden Versionen von Exchange Sicherheitsupdates, also CU 22 und CU 23.
Du musst also vorher von 21 auf 23 gehen.
Oder halt von 21 auf 22, was aber keinen Sinn macht.
2022 H1 ist nichts anderes als das CU12 für 2019er bzw. CU23 für 2016er Exchange Installationen – da hat das Marketing nur am Namen gedreht…
Schlimmer ist, das praktisch keine Informationen vorhanden sind, was wirklich los ist? Was macht die Extended Protection? Ist das noch obendrauf für die Zukunft oder ist das zwingend für jetzt? Und zwar für welche CVE? Für alle sechs davon oder nur für eine? Nix genaues weiß man nicht.
Und dann hat MS auch noch falsche Downloadlinks veröffentlicht und mittlerweile neue Links gepostet, was auch auch nur in den Kommentaren steht und sonst nirgends.
Edit: Fehler der Grafiken selbst erkannt :)
Muss ich wohl nochmals nachgehen – ist immer das Gleiche mit den CU-Links.
@Olli: gebe ich Dir in allem zu 100% recht!
und bei: "2022 H1 ist nichts anderes als das CU12 für 2019er bzw. CU23 für 2016er Exchange Installationen – da hat das Marketing nur am Namen gedreht…" …habe ich auch erst einmal rätseln müssen, was dieser Bullshit 2022H1 bedeuten soll! *argh*
Bin ich der einzige, der nach dem August-SU die Windows Extended Protection per PS-Script nicht aktivieren kann, weil das SU den Exchange Server 2019 Build anstatt auf 15.02.1118.012 nur auf 15.02.1118.010 angehoben hat, das Script das aber als nicht kompatibel ansieht?
Bei uns ist das bisher auf zwei unabhängigen Exchange Servern 2019 so, beide laufen unter Windows Server 2019 und waren zuvor auf CU12 inkl. May-SU.
Lt. MS sind folgende CVE nur mit aktivierter E.P. so gepatcht, dass man ruhig schlafen kann.
CVE-2022-21979
CVE-2022-21980
CVE-2022-24516
CVE-2022-24477
CVE-2022-30134
Diese CVE benötigt keine E.P.
CVE-2022-34692
Da ja fast jeder den ich kenne nen Load-Balancer oder Reverseproxy einsetzt, kann das Aktivieren des E. P. m. M. nach auch Probleme verursachen.
Ich würde mich über jeden kurzen Erfahrungsbericht von "Pionieren" freuen ;-)
Danke -> Grüße
Ich habe gestern Abend die E.P. eingerichtet.
Haben hier Exchange 2016 CU 23 DAG und Kemp Load-Balancer, Mobileiron etc. im Einsatz -> Keinerlei Probleme.
Muss man nicht verstehen, ich habe das SU nochmals heruntergeladen, die EXE von gestern Nacht hatte eine Grösse von 159582KBm die von heute interessanterweise eine von 159590KB, die neue ist also 8KB grösser und siehe da, nach der Installation der neuen Exe hat der Exchange den richtigen Build 15.2.1118.12, und nun lief auch das PS-Script für die Aktivierung de EEP fehlerfrei durch.
Davon hatte ich gestern Nacht noch im Exchange Blog gelesen.
Microsoft hat wohl zuerst eine veraltete Version online gestellt…
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/bc-p/3595327/highlight/true#M33548
Steht bei Microsoft in den Kommentaren. MS hat zuerst einen falschen Link veröffentlicht mit einem falschen Patch und irgendwann heimlich den Download durch einen neuen ersetzt…
Danke, da habe ich die Infos dazu inzwischen auch gefunden, beim ersten Mal hatte ich es überlesen, weil ich mich primär auf Infos zum EEP konzentriert hatte, aber, dass man sowas überhaupt erst in irgendwelchen Kommentaren suchen muss ist irgendwie schon, sagen wir mal, befremdlich…
Das größte Problem bei der Extended Protection scheint "Customers using a Retention Policy containing Retention Tags which perform Move to Archive actions should not configure Extended Protection, as enabling Extended Protection will cause automated archiving to stop working. We are actively working to resolve this issue" zu sein (Quelle:
Das setzen viele Unternehmen ein. Warum das MS Skript das nicht überprüft, statt das in eine Fußnote zu setzen, wird wohl Microsofts Geheimnis bleiben.
Mal so zur Info, wir haben nun drei unserer Exchange Installationen aktualisiert und bei allen die Exchange Extended Protection aktiviert, bisher können wir (noch?) keine negativen Folgen feststellen, aber der Tag ist ja noch jung :-)
Es handelt sich um 3 separate Exchange-Installationen (2x Exchange 2019, 1x Exchange 2016), kein DAG, kein Loadbalancer.
Kann jemand genauer erklären wo ich EEP auf 2013er aktivieren kann?
.\ ExchangeExtendedProtectionManagement.ps1 findet er bei mir nicht
Danke
hat sich erledigt…
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862
"The current version of this script can be found at https://aka.ms/ExchangeEPScript and the documentation is at https://aka.ms/ExchangeEPDoc."
Du hast das Script heruntergeladen in in die richtigen Pfade kopiert, bzw. der PS den korrekten Pfad mitgegeben? Aber zuerst: Das Script muss seperat heruntergeladen werden von der MS GitHub Seite…
Wenn ich auf unserem Exchange Server 2016 nach der Installation der Updates versuche die Extended Protection mittels dem Skript zu aktiveren, bekomme ich bei jedem Befehl, welcher umgesetzt wird in dem Skript diese Meldung:
Set-WebConfigurationProperty : Dateiname: \\?\C:\Windows\system32\inetsrv\config\applicationHost.config
Fehler: Die Konfigurationsänderungen können nicht angewendet werden, da die Datei geändert wurde.
Woran kann dies liegen?
Ich hatte am Freitag zwei Exchange 2013 und einen 2019 über Windows Update gepatcht. Bei den ersten zweien war das Update ohne Probleme durchgelaufen, auf dem dritten, dem 2019, hing er bei einem Installationsstatus von 92% fest und konnte anscheinend mehrere Dienste aufgrund eines Abhängigkeitsproblems nicht starten.
Nach einem notgedrungen ausgeführten Reboot (der Server reagierte irgendwann fast gar nicht mehr) waren alle auf Automatisch stehenden Exchange-Dienste nicht geladen, weil der Dienst Microsoft Exchange Active Directory-Topologie sich nach dem Start sofort wieder beendete und daran wohl ein ganzer Rattenschwanz an Abhängigkeiten angeknotet ist.
Die Deinstallation des als installiert gezeigten Updates schlug fehl, ebenso der Versuch, das CU12 nochmal drüber zu installieren.
Blieb letztlich die Wiederherstellung von System- und Programmvolumen aus dem Backup. Einzelfall? Kann ich eine Wiederholung wagen, diesmal als manuelle Installation?
Ich habe das Problem wenn ich die Extended Protection aktiviere auf einem EX2013 das die Outlook-Clients sich nicht mehr verbinden – Outlook startet bis zu einer Kennwortmaske und das war es dann. Rolle ich zurück ist alles wieder fein. Bin ich damit alleine?
Wäre ja mal schön, wenn sich Microsoft dazu äußert, warum dieses auftreten könnte. Gibt es anscheinend öfters? Bisher nur in Verbindung mit Office 365 bekannt.
Hast du da einen Proxy / UTM oder so dazwischen?
Es gibt auf anderen Seiten einige Berichte, dass das mit der AV-Lösung zusammenhängen könnte, da diese die SSL-Verbindung terminiert um die Pakete zu scannen. Das Hinzufügen des Exchange als Ausnahme soll wohl allen geholfen haben.
z.B. hier in den Kommentaren zu finden:
https://www.frankysweb.de/neue-sicherheitsupdates-fuer-exchange-server-august-2022/#comment-120273
https://www.frankysweb.de/neue-sicherheitsupdates-fuer-exchange-server-august-2022/#comment-120271
Oder auch hier:
https://web.archive.org/web/20220816071935/https://www.reddit.com/r/exchangeserver/comments/wk8p3r/comment/ikhovtz/?utm_source=reddit&utm_medium=web2x&context=3
Danke – In meinem Fall leider nicht.
Virenscanner und Firewall sind aktuell ausgeschlossen, trotzdem kommts zu dem entsprechenden Fehler und Eventlogeintrag über eine gescheiterte Anmeldung bei aktiver EP.
Hier ist noch mal der Kommentator vom 16. August 2022 um 15:20
Ich habe gestern auf Exchange 2013 das Update eingespielt und auch die Extended Protection aktiviert.
Wir haben seitdem das Problem, dass auf einigen wenigen Rechnern Outlook 2016 permanent nach dem PW fragt und sich nicht mit Exchange verbinden kann. Bei den allermeisten Usern (gleiches Windows 10, gleiches Outlook 2016, Mailbox auf dem selben Exchange 2013) tritt das Problem nicht auf.
Es liegt nicht am User oder am Postfach, sondern am Rechner. Es gibt z.B. den Fall, dass ein User auf seinem Desktop das Problem hat, auf seinem Laptop aber nicht. OWA im Browser funktioniert immer.
Wir konnten den Fehler auf den betreffenden Rechner bislang nicht finden. Falls irgendwer einen Tipp hat, gerne her damit.
Bei OWA (auch von extern über ReverseProxy) und Activesync aufm Smartphone bislang keine Probleme.
Haben den Fehler endlich gefunden. Der Einfachheit halber verlinke ich meinen (aktualisierten) Kommentar im Exchangeblog:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/bc-p/3603261/highlight/true#M33721
Weil ein paar es nicht aktivieren können, soll Microsoft die Sicherheitslücken gar nicht erst schließen?
Für die mit Server 2012R2 und Exchange (2016) die die IIS Modul Warnung bekommen haben gibt es jetzt eine neue Version die berücksichtigt, das diese Module von MS bei 2012R2 nicht signiert sind:
https://github.com/microsoft/CSS-Exchange/releases
meinen Sie damit eine neue Version vom HealtChecker.ps?
Jup, deswegen der Link. Hätte ich aber noch mal reinschreiben können, hast recht :)
Hat jemand Erfahrung mit dem bekannten Problem "Das Cmdlet Get-EmailAddressPolicy schlägt fehl und gibt "Microsoft.Exchange.Diagnostics.BlockedDeserializeTypeException" zurück. ?
Wenn es nicht mehr möglich ist, die Adressrichtlinien einzusehen oder gar zu ändern, hat man doch ein großes Problem….
Kann jemand bestätigen, ob der Fehler bei einer EX2019 CU12 auftritt?