[English]Microsoft hat zum 10. Januar 2023 Sicherheitsupdates für Exchange Server 2013, Exchange Server 2016 und Exchange Server 2019 veröffentlicht. Diese Sicherheitsupdates schließen zwei Schwachstellen (Elevation of Privilege und Spoofing) in dieser Software. Diese Updates sollen zeitnah auf den Systemen installiert werden, um die betreffenden Schwachstellen zu schließen.
Anzeige
Microsoft hat den Techcommunity-Beitrag Released: January 2023 Exchange Server Security Updates mit einer Beschreibung der Sicherheitsupdates veröffentlicht.
Es stehen Sicherheitsupdates für folgende Exchange-Server CU-Versionen zur Verfügung (Links von Microsoft, die teilweise Downloads von August 2022 aufweisen – aber die KB-Artikel sind in den Details richtig verlinkt).
- Exchange Server 2013 CU23, KB5022188 (Support endet im April 2023)
- Exchange Server 2016 CU23, KB5022143
- Exchange Server 2019 CU11, CU12, KB5022193
Microsoft schreibt im Techcommunity-Beitrag, dass die Sicherheitsupdates vom Januar 2023 Sicherheitslücken beheben, die Microsoft von Sicherheitspartnern gemeldet und durch die internen Prozesse von Microsoft gefunden wurden. Details werden keine offen gelegt, ich hatte im Beitrag Microsoft Security Update Summary (10. Januar 2023) folgende Details zu den Schwachstellen veröffentlicht.
Anzeige
- CVE-2023-21763 und CVE-2023-2176: Microsoft Exchange Server Elevation of Privilege Vulnerabilities; Important, CVSSv3 Score 7.8; Könnte einem authentifizierten Angreifer SYSTEM-Rechte gewähren. Microsoft hat diese Schwachstellen als "Ausnutzung weniger wahrscheinlich" eingestuft, aber keine Erklärung dafür gegeben.
- CVE-2023-21745 und CVE-2023-21762: Microsoft Exchange Server Spoofing Vulnerabilities, Important, CVSSv3 Score 8.0; CVE-2023-21745 kann entweder über das lokale Netzwerk oder über das Internet ausgenutzt werden – und wurde als "Exploitation More Likely" eingestuft. CVE-2023-21762 hingegen ist auf ein gemeinsam genutztes physisches oder lokales Netzwerk oder eine "anderweitig begrenzte administrative Domäne" beschränkt. Eine erfolgreiche Ausnutzung könnte zur Offenlegung von New Technology LAN Manager (NTLM) Hashes und NTLM-Relay-Angriffen führen.
Microsoft schreibt, dass zwar keine aktiven Exploits in freier Wildbahn bekannt sind, man empfihelt aber, diese Updates sofort zu installieren, um die Exchange-Installationen zu schützen.
Beachtet Microsofts Hinweise zur Update-Installation (so sind ältere CUs entfallen). Es wird die Aktivierung des Certificate Signing für die PowerShell Serialisierung nach Installation des Januar 2023-Sicherheitsupdates empfohlen. Zudem soll der Health Checker ausgeführt werden, um zu sehen, ob weitere Aktionen erforderlich sind.
Die Patches verursachen einen Fehler: Sobald das Update auf einem Exchange Server 2016 oder 2019 installiert ist, werden Webseitenvorschauen für in OWA freigegebene URLs nicht mehr korrekt gerendert. Microsoft will diesen Bug in einem zukünftigen Update beheben.
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.
Ergänzung: Ich habe einige Hinweise auf Probleme im Beitrag Microsoft Exchange Januar 2023 Patchday-Nachlese: Dienste starten nicht etc. gesammelt.
Ähnliche Artikel:
Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
Exchange Server: Neue 0-day (nicht NotProxyShell, CVE-2022-41040, CVE-2022-41082)
Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333
Neues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EMS-Lösung
Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (8. Oktober 2022)
Exchange Server Sicherheitsupdates (11. Oktober 2022)
Exchange Server Sicherheitsupdates (8. November 2022)
Ransomware-Angriff für Ausfall der Rackspace-Exchange-Instanzen im Dez. 2022 verantwortlich
Ärger: Schweizer NCSC informiert Kunden über unsicherere Exchange Server (Dez. 2022)
Microsoft Exchange: Neue OWASSRF-Exploit-Methode (ProxyNotShell) durch Play-Ransomware
Droht eine Exchange ProxyNotShell-Katastrophe zum Jahreswechsel 2022/2023?
Anzeige
Lief problemlos auf Exchange 2016 CU23 durch. HealthChecker zeigt in der aktuellen Version alles grün.
Certificate Signing nicht aktiviert. Ich warte da noch ab.
Gruß
Also, ich habe das mal umgesetzt…
New-SettingOverride -Name „EnableSigningVerification" -Component Data -Section EnableSerializationDataSigning -Parameters @(„Enabled=true") -Reason „Enabling Signing Verification"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force
in einer Elevated Exchange PowerShell.
Interessanterweise kann ich nun (nach der Umsetzung) Get-ExchangeCertificate normal (non-elevated shell) nicht mehr ausführen, da kommt ein Empty-Result zurück:
Thumbprint Services Subject
———- ——– ——-
ABER: Get-ExchangeCertificate läuft anscheinend dann nur noch in einer elevated Exchange PowerShell, da kommen dann die normalen Ergebnisse.
Habe mal mit einer anderen Exchange Domain getestet (noch nicht mit dem neuesten SU versehen), mit 'normaler' Exchange PowerShell (nicht elevated), da funktioniert der Get-ExchangeCertificate Befehl weiterhin mit Ergebnissen.
Ist das so beabsichtigt, oder habe ich was falsch gemacht ??
Hallo Zusammen
Kann mir jemand bei der nachfolgenden Entscheidung helfen?
Bei uns eben wieder Thema wegen der aktuellen Updates:
– Wie hoch ist das Risiko, Extended Protection über das MS-Skript einzuschalten?
– Funktionier das Rückgängigmachen erfolgreich wenn etwas schief geht?
Ich habe den Artikel zum Thema bereits mehrmals gelesen, scheitere aber immer bei den Aussagen rund um TLS und NTLM. Die allgemeinen Prerequisites habe ich überprüft.
Aber die einen sagen, man müsse die TLS Versionen fixieren und ander sagen wieder was anderes. Ich für meinen Teil bin verunsichert. Auch wegen NTLM und Office 2010.
Wir haben keine Archive, keine Public Folder etc.
ABER:
Wir haben noch vereinzelte (4-5) Outlook 2010 Clients (intern), welche mit dem Exchange 2016 CU23 kommunizieren. Diese laufen teilweise noch auf "unersetzbaren" Windows 7 Clinets. Wird das ein Problem? Sonst nutzen wir überall Outlook 2019.
Vielen Dank für jegliche Hilfe / Stellungnahme :-)
Grüsse
Damals hat das Script wunderbar funktioniert. Auch der Rollback klappte in der Testumgebung – im Echtsystem war er zum Glück nicht notwendig.
Ich habe damals die Reg-Einträge entsprechend der Doku gesetzt.
Ich persönlich würde, wie in der Doku empfohlen, die TLS Regkeys setzen und das Script im Prüfmodus durchlaufen lassen. Wenn er nichts bemängelt, dann sollte es klappen.
NTLMv2 sollte für Win7 kein Problem sein, aber ich meine das Outlook 2010 kein TLS 1.2 unterstützt. 1. müsste ich das nachlesen und 2. ob die Abschaltung von TLS 1.0/1.1 tatsächlich notwendig für EP ist. (TLS 1.0/1.1 sollten auf kurz oder lang dennoch deaktiviert werden).
Wenn vorab keine Testmöglichkeit besteht – Regkeys setzen, testen, alles ok -> EP aktivieren, testen, alles ok (juhu) – falls nicht, EP Rollback :)
Healthchecker Script hilft ebenfalls weiter, und bei Franky findest du ein gutes Script um die Empfehlungen direkt umzusetzen.
Viel Erfolg!
Hallo nk,
Vielen Dank für deine Antwort. Das macht Mut. Werde ich so umsetzten. Wie kann das Skript denn im "Prüfmodus" gestartet werden? Macht das Skript das nicht automatisch vor der "echten" Ausführung?
PS: Bezüglich TLS 1.2 und Outlook 2010
Zitat von https://jaapwesselius.com/2018/09/23/outlook-2010-disconnected-with-tls-1-2/
"Outlook 2010 does not support TLS 1.2 out of the box. This can be an issue if you or your network department starts implementing a TLS 1.2 environment only. You have to enable TLS 1.2 on the workstation by setting a registry key. After this it works fine."
Schönes Wochenende.
Ich wusste irgendwann erwischt es mich. :-(
Bin noch auf CU22 Nov Update
Jetzt erst mal die CU23 installieren und dann das Januar Update.
Da geht wieder Zeit drauf.
Vorbereitung CU23 = 1h
Installation CU23 (vorher CU22) = 2,5h
Installation SU = 1h
Nacharbeiten (HealthChecker, erneute Aktivierung Extended Protecion…) = 1h
Zusammen: 5,5h
Alles ohne Probleme durchgelaufen!
Bekomme HTTP 500 Fehler, wenn ich mich in die ECP einloggen will ?!
alle Dienste down – trotz Reboot… es macht einfach keinen Spaß mehr. Nachdem man alle Dienst manuell gestartet hat, geht's wieder !
"Die Patches verursachen einen Fehler: Sobald das Update auf einem Exchange Server 2016 oder 2019 installiert ist, werden Webseitenvorschauen für in OWA freigegebene URLs nicht mehr korrekt gerendert. Microsoft will diesen Bug in einem zukünftigen Update beheben."
Exchange Online ist davon nicht betroffen.
Das freut den Admin, dass er mit dem SU gleich einen neuen Fehler einbauen darf und er blöderweise seine Exchange Umgebung noch nicht zu MS in die Cloud migriert hat.
Das Produkt ist wirklich mühsam geworden, ich arbeite mit Exchange seit Version 4.0.
Exchange 2016 CU23 unter Windows 2012R2:
Nach Update auf den Januar Windows Patch startet der Dienst "MSExchangeADTopology" (Microsoft Exchange Active Directory-Topologie) nicht sofort. Dadurch starten fast alle Exchange Dienste nicht. Ein manueller Start der Dienste fährt diese wieder hoch.
Laut ExchangeTeamblog (https://techcommunity.microsoft.com/t5/exchange-team-blog/released-january-2023-exchange-server-security-updates/ba-p/3711808)
"1/11/2023: Added an issue (still being investigated) where Exchange services might not start automatically if update is installed on an Exchange Server 2016 running on Windows Server 2012 R2."
Wird die Sache gerade untersucht.
Betrifft hier 2 Kunden die dieses Jahr umgestellt werden auf neues OS und Exchange 2019.