Exchange Server Sicherheitsupdates (9. August 2022)

Update[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.

Exchange August 2022 Updates

Es stehen Sicherheitsupdates für folgende Exchange-Server CU-Versionen zur Verfügung.

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU22 and CU23
  • Exchange Server 2019 CU11 and CU12

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:

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software, Update, Windows Server abgelegt und mit Echange, Patchday 8.2022, Sicherheit, Update verschlagwortet. Setze ein Lesezeichen auf den Permalink.

36 Antworten zu Exchange Server Sicherheitsupdates (9. August 2022)

  1. MOM20xx sagt:

    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?

  2. A. Nonym sagt:

    Wie kann man den die im Bild gezeigten Versionen von ExChange auslesen?

    So gibt es eine andere Nummer (aus Outlook):

    Debug.Print Session.ExchangeMailboxServerVersion

    • Roger Hungerbühler sagt:

      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

  3. Ludwig L. sagt:

    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….

    • Dominik sagt:

      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.

    • Olli sagt:

      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 :)

      • Günter Born sagt:

        Muss ich wohl nochmals nachgehen – ist immer das Gleiche mit den CU-Links.

      • Robert sagt:

        @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*

  4. Roger Hungerbühler sagt:

    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.

  5. Khappa sagt:

    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

    • DerEine sagt:

      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.

  6. Roger Hungerbühler sagt:

    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.

  7. Joachim sagt:

    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.

  8. Roger Hungerbühler sagt:

    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.

  9. Peter sagt:

    Kann jemand genauer erklären wo ich EEP auf 2013er aktivieren kann?
    .\ ExchangeExtendedProtectionManagement.ps1 findet er bei mir nicht

    Danke

  10. David sagt:

    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?

  11. Olaf E. sagt:

    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?

  12. Matze sagt:

    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?

  13. asdasd sagt:

    Weil ein paar es nicht aktivieren können, soll Microsoft die Sicherheitslücken gar nicht erst schließen?

  14. Thomas sagt:

    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

  15. Ex2019User sagt:

    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?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.