Exchange Server: Neue Sicherheitsupdates (Oktober 2022)

von

Microsoft hat heute neue Sicherheitsupdate für alle unterstützen Exchange Server Versionen veröffentlicht. Microsoft weißt ausdrücklich darauf hin, dass die Updates keinen Fix für die Zero-Day Schwachstellen (ProxyNotShell) enthalten. Die folgenden Schwachstellen werden durch das Sicherheitsupdate behoben, drei der Schwachstellen gelten als kritisch:

Die Updates können hier runtergeladen werden:

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

Hier findet sich der Artikel auf dem Exchange Team Blog:

Da wie bereits erwähnt die Zero-Day Lücken noch nicht geschlossen wurden, muss der Workaround via URL Rewrite Regel erhalten bleiben. Der String für das Reg-Ex Pattern wurde in der letzten Zeit öfter durch Microsoft angepasst. Dies ist der aktuelle String für die URL-Rewrite Regel:

(?=.*autodiscover)(?=.*powershell)

Eine entsprechende Anleitung zur Konfiguration der URL Rewrite Regel findet sich hier:

Microsoft empfiehlt, dass die Updates zeitnah installiert werden.

54 Gedanken zu „Exchange Server: Neue Sicherheitsupdates (Oktober 2022)“

  1. Moin,

    ich habe gestern das Update auf einem 2016er Exchange installiert und habe heute Probleme mit Outlook.
    Es lässt sich garnicht mehr öffnen (Probleme mit der Exchange Verbindung). Neues Profil anlegen ruft ein Anmeldefenster hervor.
    OWA funktioniert.
    Hat jemand eine Idee?

    Antworten

  2. Hallo miteinander,

    ich ärgere mich jetzt schon zwei Tage mit dem Update KB5019077 herum. MSX19, CU12, SU2 (08/22), onprem, VM
    Das Einspielen über Windows-Update schlug fehl, Fehler 1603, MSX-Dienste sind alle deaktiviert und lassen sich auch nicht manuell starten, da sie vom MSX-AD-Topologie dienst abhängig sind der eben auch nicht startet. Der ist aber von Net.TCP Port Sharing Service abhängig, der wiederum gestartet ist.
    Auf reddit gibts noch Hinweise auf .NET4.8-Probleme, fehlenden/falschen SharedWebconfig.config-Dateien (ASP.NET 4 event 1310 sollen darauf hinweisen, die bei mir auftauchen), MS schrieb was von Zugriffsrechten, aber leider komme ich nicht weiter:
    .NET-Repairtool machte was, aber das Problem blieb, Neuinstallation/Reparatur von 4.8, weil schon installiert (höhere Nummer) brachen daher ab;
    Dienste starten nicht (auch über Powershell-Script (Reddit)) nicht
    und eigentlich würde ich eine Neuinstallation vermeiden.
    Frage: Wenn es ohne Eure hilfreichen Ideen doch darauf hinausläuft, ein „.\setup /m:upgrade /IAcceptExchangeServerLicenseTerms“ zu machen, was muß ich ggf. beachten, damit ich nicht komplett alles neu konfigurieren muß (konfig, user, db, etc)?

    Vielen Dank und Euch ein entspanntes WE,

    Antworten

  3. Hallo,

    ich validiere aktuell die Extended Protection komplett durch.
    Es gibt eine Konfiguration, wo es einen Bug gibt.
    Wenn man OWA und ECP von Formular auf Windows Auth. und Standard Auth. umstellt, kann man sich auf dem Exchange Server selbst, nicht mehr am ECP und OWA anmelden.

    Von einem anderen Client fkt. es, auch von extern, ebenfalls wenn man dort via Sophos Umkehrauth. konfiguriert hat.

    Hat jemand dieses Problem beobachtet, es muss per Design so sein, weil ein Kunde mit der gleichen Einstellung, hat den gleichen Fehler. Wenn nicht, mache ich einen MS Fall auf.

    Antworten

    • Manchmal muss man die Frage aufschreiben, damit einem die Lösung einfällt.

      1. Entweder per ECP/OWA mit dem Servernamen zugreifen, dann geht es auch lokal auf dem Exchange Server.
      2. Oder einen Registry Key setzen, denn ich aus den SharePoint Umfeld kenne: DisableLoopbackCheck = 1

      Antworten

  4. Gibt es Informationen oder eine Einschätzung wann ein tatsächliches Update zur Behebung der ProxNotShell Sicherheitslücke seitens Microsoft zu erwarten ist? Könnte das Update bald erscheinen oder dauert es bis zum nächsten regulären Patch Day am 08.11.2022?

    Antworten

  5. Ich hatte auch auf einem Exchange 2019 mit Servder 2019 massiv Probleme mit dem Patch. Der erste Versuch üer Windows Update schlug fehl. Danach waren wie beschrieben alle Dienste deaktiviert. Ich habe diese manuell gestartet und den Patch nochmal sauber per Hand installiert. Trotz CMD mit erhöhten Rechten waren wieder alle Dienste auf deaktiviert. Nur manuelles umstellen auf Automatisch brachte dann einen Erfolg. Der andere Exchange Server im DAG hatte keine Probleme.

    Was mich nur irrtiert ist das im ECP immer noch Version 15.2 (1118.7) steht. Bei euch auch so?

    Antworten

    • Ich weiß nicht, wie oft ich schon Kunden oder in Foren erklärt habe, dass die Installation per Windows Update (oder WSUS) immer wieder für Überraschungen gut ist und im Zweifel natürlich zusätzliche Schritte notwendig sind. Trotzdem gibts immer wieder Leute die ihr Glück versuchen wollen. ;)

      Im ECP steht schon immer nur die jeweilige Hauptversion (das CU, bzw. früher das Service Pack). Security Patches wurden an der Stelle noch nie angezeigt.

      Antworten

  6. Komischerweise funktionieren die „nebenpostfächer“ nicht mehr. Fehler „0x8004010F“ beim Senden Outlook 2019.

    Und ja, ich kenne die Workarounds mit ost / neues Profil anlegen. Das ist nicht die Lösung.

    Bei allen Usern mit mehr als 2 Postfächern auf einem Exchangeserver . (Ex 2016 CU23)

    Wirklich komisch….

    Antworten

  7. Ich erhalte beim aktivieren der Extended Protection folgenden Fehler:

    Das Argument für den Parameter „SiteVDirLocations“ kann nicht überprüft werden. Das Argument ist NULL oder leer, oder ein Element der Argument Auflistung enthält einen NULL Wert. Geben Sie eine Auflistung an, die keine NULL-Werte enthält und führen Sie dann den Befehl erneut aus.

    Zeichen 35 in Exchange-Script

    Exchange 2016 auf Server 2012 – 15.01.2507.013 (Oktober 2022 SU Update auf CU 23)

    Antworten

  10. Hallo zusammen,
    wir haben seit dem Update (KB5019076) auf dem Exchange 2016 CU23 folgendes Problem. Unsere Mails bleiben in der Warteschlange mit folgender Fehlermeldung hängen: „LED= 451 4.4.395 Target host responded with error. -> 421 4.4.1 Connection timed out“. Der Mailprovider, an den die Mails per SMTP versendet werden sollen weist alle Schuld von sich. Wir haben auch schon versucht, das Update manuell zu deinstallieren (hat nichts gebracht). Komischerweise werden zwischenzeitlich teilweise Mails versendet, danach geht der Exchange aber wieder auf o.g. Fehlermeldung. Im Ereignislog können wir auch nichts ungewöhnliches feststellen.
    Vielleicht hat ja jemand eine Idee!?
    Vielen Dank , Florian

    Antworten

  12. Exchange 2013 (auf Windows Server 2012 R2) alle Updates ohne Probleme installiert. Extended Protection und die URL Rewrite-Regel hatte ich vorher schon aktiv.

    Antworten

  13. Bei mir lief das Update anscheinend nicht sauber durch. Nun komme kommt “ Fehler beim Datenabruf“ und komme auch nicht mehr drauf.
    Das letzte Windows Update funktionierte ohne Probleme.

    Was nun?

    Viele Grüße

    Antworten

  14. Bei mir lief das Update anscheinend nicht sauber durch. Nun komme kommt “ Fehler beim Datenabruf“ und komme auch nicht mehr drauf.
    Das letzte Windows Update funktionierte ohne Probleme.

    Was nun?

    Antworten

  15. Exchange 2016 mit CU 23 nach SU Oktober Update auf Version 15.01.2507.013 und Dienste laufen alle.

    Installiert unter Server 2012 R2 mit ESET Mailsecurity 9.0.10009.0 über Windows Update.

    Antworten

    • Moin Tob, ja da hab ich das Update installiert – aber noch nicht EP aktiviert, da ich erst alle Server nachziehen möchte bevor ich EP einstelle.
      Die Installation lief aber fehlerfrei.
      Ich deaktiviere bei der Installation von CU & SU immer den lokalen AV

      Grüße

      Antworten

  17. Updates liefen hier bisher problemlos!

    manuell:
    1x Exchange 2016 unter Windows Server 2012R2
    1x Exchange 2019 unter Windows Server 2019

    Dazu gut 10 weitere Systeme, die sich letzte Nacht automatisch gepatcht haben.

    Antworten

  18. Das Update oder was auch immer hat bei uns die „Windows Dienste“ teilweise deaktiviert (anstatt manuell oder automatisch).
    Leider nicht alles im Protokoll erkennbar gewesen.
    Exchange Dienste waren alle deaktiviert und konnten somit auch bei einem Neustart nicht starten oder gestartet werden.

    Nachdem die Dienste wieder entsprechend eingestellt sind läuft alles wieder.

    Antworten

    • Hi, kurze Frage. Wurde das Update per .exe oder .cab Datei installiert? Wurde die Datei als Administrator ausgeführt, z.B. über eine als Administrator gestartete cmd? Ich kenne das verhalten nur wenn man das Update nicht als Administrator startet.

      Antworten

        • gleichzeitig Windows Update und gleichzeitig ESET installieren, bringt immer Probleme. Man will sich zwar einen Reboot sparen, aber danach könnte alles kaputt sein. ESET rät auch dringlich davon ab.

        • nein, kein Virenschutz von Drittherstellern – nur Microsoft-Produkte als VM unter VMware. Windows 2019 mit Exchange 2019

        • OK, das ist ja merkwürdig. Ich habe den einen der beiden Server mit deaktiviertem Virenschutz jetzt erfolgreich aktualisieren können (Server 2016, Exchange 2016).

        • Mittlerweile ist auch der andere Server, bei dem das Update mit automatischer Aktualisierung durchgelaufen ist, trotz deaktiviertem automatischen Update, erneut automatisch gepatcht worden. Dieses mal jedoch ohne Probleme.

  20. Das mit =.*autodiscover)(?=.*powershell funktionierte bei mit nicht.
    Outlook konnt scih nicht mehr mit demExcahnge Server verbinden und bekam
    ein Fehhlermeldung, dass das autodiscover-Zertifikat nicht gültig ist.

    Antworten

      • das ist richtig, das kam nur vom copy/paste hier, in der regel sollte es aber richtig gewesen sein, da ich sie gelöscht
        hatte kann ich es nicht mehr überprüfen.
        habe danach den patch von MS ausgeführt die erstellte regel war die selbe, danach lief es ohne probleme.
        war wahrscheinlich doch wohl eine fehlerhafte eingabe von mir.

        Antworten

  21. Hinweis bei DAGs:
    Ich hatte bei uns gerade das Problem, dass die Mitigations auf allen DAG-Membern erst entfernt und der IIS-Dienst neugestartet werden musste, bevor ein DAG-Member in den Wartungsmodus geschaltet werden kann.
    Ansonsten funktionierte der Redirect der Clientverbindungen nicht.

    Eingespielt war die aktuelle MS-Regel per EMS.

    Antworten

  22. Hallo zusammen,

    wenn ich das richtig sehe, dann sind es alles CVEs aus August mit der Aktivierung von EP?

    Bin gerade etwas irritiert was nun der Unterschied zum August/Oktober ist

    Antworten

Schreibe einen Kommentar