Microsoft hat neue Sicherheitsupdates für Exchange Server 2013, 2016 und 2019 veröffentlicht. Für Exchange 2013 dürfte es das letzte Sicherheitsupdate sein, da der Support für Exchange 2013 am 11.04.2023 endet. Im März Update für Exchange wurde auch das Problem mit dem abstürzenden EWS Web Application Pool im IIS behoben. Anwendungen welche EWS benutzen, sollten also wieder fehlerfrei funktionieren. Der empfohlene Workaround muss manuell wieder rückgängig gemacht werden. Außerdem funktioniert nun auch wieder die Exchange Tool Box und die Warteschlangenanzeige. Endlich funktionieren auch Retention Policies in Verbindung mit Windows Extended Protection, sodass es nun eigentlich keinen Grund mehr gibt, Extended nicht zu aktivieren.
Hier geht es direkt zu den Downloads:
Die Updates beheben 3 als „Wichtig“ eingestufte Schwachstellen welche in die Kategorie „Remote Code Execution“ fallen. Da in diesem Update neben den Schwachstellen auch Probleme mit dem vorherigen Sicherheitsupdate behoben werden, sollte dieses Update zeitnah installiert werden. Hier gibt es weitere Details zu den Schwachstellen:
- Microsoft Exchange Server Remote Code Execution Vulnerability (CVE-2023-21706)
- Microsoft Exchange Server Remote Code Execution Vulnerability (CVE-2023-21710)
- Microsoft Exchange Server Remote Code Execution Vulnerability (CVE-2023-21529)
Neben den Updates für Exchange Server, gibt es auch für Outlook ein Sicherheitsupdate. Es handelt sich dabei um die Schwachstelle „Microsoft Outlook Elevation of Privilege Vulnerability (CVE-2023-2337)„. Da die Schwachstelle scheinbar auch bereits ausgenutzt wurde, hat Microsoft zusätzlich ein Script veröffentlicht, welches prüft, ob sich schädliche Elemente in den Postfächern befinden. Das Script benötigt die EWS Schnittstelle und kann hier runter geladen werden:
Wichtig: Das Script benötigt Impersonations-Rechte und eine entsprechende Throttling Policy. Im oben angegebenen Link steht, wie diese Rechte konfiguriert werden. Das Script sollte auch in Umgebungen ausgeführt werden, welche Exchange Online verwenden, auch dort können schädliche Elemente in den Postfächern liegen.
Hier noch der Artikel vom Exchange Team Blog:
Die Links auf der Exchange Versions Seite sind bereits aktualisiert.
2x Exchange 2019 DAG installiert, Workaround aus Februar wieder rückgängig gemacht.
Stand heute Abend geht unser Melde Button im Outlook von Sosafe wieder nicht…dieser braucht ews, letztes Mal war es ein zeitthema nachdem Workaround und ich schätze das hier mal genauso
Hier noch ein Powershell-Skript um die Throttling Policy auf Default zurückzusetzen und die CVE Policy zu löschen:
$policy = Get-ThrottlingPolicy CVE-2023-23397-Script
$mailboxes = Get-Mailbox | where-object {$_.ThrottlingPolicy -eq $policy.Identity}
$defaultPolicy = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}
foreach ($mailbox in $mailboxes) {Set-Mailbox -Identity $mailbox.Identity -ThrottlingPolicy $defaultPolicy}
Remove-ThrottlingPolicy CVE-2023-23397-Script
Super! Vielen Dank dafür! :-)
Super! Vielen Dank dafür! :-)
Zum Thema 401 im Script:
ExtendedProtection setzt im IIS im EWS in der Windows-Authentifizierung (Erweiterte Einstellungen) den Erweiterten Schutz auf aktiviert.
Ich hatte zum ausführen des Scriptes den Eintrag auf Deaktiviert gesetzt, dann tut das Script auch was es soll.
Das ist der essentielle Punkt, den ich ausser von Dir bisher nicht gesehen habe.
Dass das CVE Skript scheinbar nicht mit der ExtendedProtection umgehen kann.
Hatte schon die Befürchtung, daß es an mir liegt (was ich kategorisch ausschliesse ;-) )
3 x Exchange 2013 auf 2012 R2 ohne Probleme.
Das Script will bei mir einfach nicht. Direkt lokal vom EX aus getestet.
Imperso Rolegroupe gem. Anleitung erstellt und 1-2 Testuser da rein gepackt. Kriege immer wieder die Meldung
The request failed. Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
Aufruf via:
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL https://DOMAIN.COM/EWS/Exchange.asmx -IgnoreCertificateMismatch
Benutzer: impersouser@mail.com (auch impersouser@mail.local getestet), keine Chance..
Ideen?
Bei mir klappt es wie folgt:
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -StartTimeFilter „01.01.2023 00:00:00“ -EndTimeFilter „01.01.2024 00:00:00“ -DLLPath .\lib\40\Microsoft.Exchange.WebServices.dll -EWSServerURL https://*domain*/EWS/Exchange.asmx -IgnoreCertificateMismatch -Credential „user@upn“
Die Microsoft.Exchange.WebServices.dll kannst du dir wie folgt besorgen:
Steps to Download Microsoft.Exchange.WebServices.dll:
Download the nuget package from NuGet Gallery | Microsoft.Exchange.WebServices.2.2.0
(https://api.nuget.org/v3-flatcontainer/microsoft.exchange.webservices/2.2.0/microsoft.exchange.webservices.2.2.0.nupkg)
Change the extension of the file from .nupkg to .zip
Unzip the package.
Use the dll present at “\lib\40” location in the package
Provide the path to the DLL for the DLLPath parameter when running the script.
Wichtig: Der von MS zur Verfügung gestellte Link zur „WebServices.dll“ war anfangs falsch und wurde mittlerweile korrigiert. Zur Not die Datei also nochmal neu herunterladen.
Bei mir hat es seltsamerweise beim Credential-Parameter ohne UPN, spricht rein mit dem samaccountnamen ohne den Domainhelper geklappt.
Ich suche aber eine Möglichkeit das Script für mehrere, nicht via Suchfilder zusammengewürfelte Mailboxen laufen zu lassen. Via
foreach ($mbx in (Get-Content „\liste_mailboxen.txt“)){get-mailbox $mbx | Get-Mailbox -identity $mbx | .\CVE-2023-23397.ps1 -Environment Onprem -StartTimeFilter „01/01/2023 00:00:00“ -EndTimeFilter „01/01/2024 00:00:00“ -EWSSERVERURL „https:///EWS/Exchange.asmx“ -DLLPath „\microsoft.exchange.webservices.2.2.0\lib\40\Microsoft.Exchange.WebServices.dll“}
kommt halt zig mal ne Credentialbox…
Hi,
bei mir hat es was gebracht die IP des Exchange in der EWS URL zu benutzen.
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -StartTimeFilter „01.01.2023 00:00:00“ -EndTimeFilter „01.01.2024 00:00:00“ -EWSServerURL https://„IP_EXCHANGE“/EWS/Exchange.asmx -IgnoreCertificateMismatch -Credential „user@domain.tld“
Update 2016er auf 2012R2 ohne Probleme.
Script hat auch nichts verdächtiges gefunden.
Hallo,
ich sehe nach der Installation des Updates aus März auf unterschiedlichen Sites auf unterschiedlichen Server (Exchange 2016/2019) div. verdächtige Aktivitäten, hat jemand dies auch schon beobachtet?
C:\Windows\Temp\ndif2tbc\ndif2tbc.dll
C:\Windows\Temp\nhtfkv53\nhtfkv53.dll
C:\Windows\Temp\tkgzersz\tkgzersz.dll
Aller werden erstellt durch: SYSTEM@NT-AUTORITÄT@
Sehe hier(EX2016) nichts dergleichen.
Gruß
Ich prüfe grade, vielleicht wirklich nur Zufall und unsere Sicherheitssoftware erkennt das Monitoring hier als false positive.
Hallo,
ich stelle mich wahrscheinlich zu dumm an, aber wo kann ich einen User zu der Gruppe „ApplicationImpersonation Gruppe“ hinzufügen? Mit der Anleitung von MS komme ich nicht klar.
Danke für die Unterstützung schon mal im Vorfeld.
Das Skript aus den requirements ausführen. Danach zB. ins ECP und dort einen User in die neu angelegte Gruppe hinzufügen, welche die benötigen Berechtigungen hat. Die Gruppe hat den Namen der CVE, wie auf der Hilfe Seite beschrieben.
Gruß
https://www.codetwo.com/kb/how-to-set-impersonation-rights-manually/
PowerShell Serialization Payload Signing könnte man nun bedenkenlos aktivieren? Sind die bekannten Probleme behoben?
ansonsten CU Update installiert über Windows Update, funktioniert alles!
So stehts zumindest im Abschnitt „Issues resolved in this release“.
Aber du stehst ja eh auf Risiko, sonst würdest du ja nicht das Windows Update für Exchange verwenden. ;)
hehe jaa stimmt, aber bisher noch nie Probleme gehabt :-). aber danke, dann lasse ich es mal aktivieren
Same :)
Noch nie Probleme damit gehabt in meiner EXCH ONPREM Cluster Umgebung !
GSD!
Hi,
wie kann man den Workarround rückgängig machen?
Danke schon mal
Hab es gefunden, wer es braucht
https://support.microsoft.com/en-us/topic/ews-web-application-pool-stops-after-the-february-2023-security-update-is-installed-f7ead47c-2303-4132-963e-b66548017340
Wenn ich das hier so lese, bin ich irgendwie schon froh zu Microsoft 365 migriert zu haben. Ich genieße die Freizeit…
Noch 2 Wochen und ich mache auch 3 Kreuze :D
Für alle die das Skript auf dem Exchange selber ausführen wollen und sich Zeit sparen wollen:
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL „https://127.0.0.1/EWS/Exchange.asmx“ -IgnoreCertificateMismatch
Dann die Login Daten des Nutzers im UPN Format eingeben, welchen ihr in die ApplicationImpersonation Gruppe gezogen habt: username@domain.local , Passwort
Anschließend sollte das Skript durchlaufen. Bei unserer kleinen Umgebung war das in 2 Minuten durch.
Gruß
Danke! ;)
Laut Script gibt es eine Liste mit aufälligen Elementen.
Diese kann dann zur „Behandlung“ editiert und als Parameter mit dem Script aufgerufen werden.
Was macht das Script aber genau mit den Outlook Elementen?
Werden diese gelöscht?
Das hängt von der CleanupAction ab. Entweder bereinigt oder gelöscht.
Läuft das Test-Script bei euch?
Es heißt ja:
Prerequisites to run the script for Exchange Online
To run this script in an Exchange Online environment, you need to be a member of Organization Management. The script will create an application with full access permission on all the mailboxes. To scan cloud mailboxes, you also need to add the Azure-AD module to PowerShell. See Install AzureAD PowerShell for Graph for more information.
Note: The script uses Microsoft.Exchange.WebServices.dll to make EWS calls. The script will try to download the DLL and use it. However, if it is unable to, you will need to download the DLL and specify the path.
Steps to Download Microsoft.Exchange.WebServices.dll:
Download the nuget package from NuGet Gallery | Exchange.WebServices.Managed.Api 2.2.1.2
Change the extension of the file from .nupkg to .zip
Unzip the package.
Use the dll present at “\lib\net35” location in the package
Provide the path to the DLL for the DLLPath parameter when running the script.
Fehler:
The specified module ‚C:\EWS\lib\net35‘ was not loaded because no valid module file was found in any module directory.
Egal, ob er die Module selber runterlädt oder ich es wie beschrieben mit dem Download und \lib\net35 mache…
Es geht einfach nicht.
Local auf dem eigenen Exchange:
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL https://yourURL.com/EWS/Exchange.asmx -IgnoreCertificateMismatch
Und besser nicht direkt auf dem Exchange ausführen. Da hakte er bei uns immer wieder.
Updates liefen ohne Probleme.
Er sucht das dll wie folgt:
c:\Scripts\CVE-2023-23397.ps1
c:\Scripts\EWS\Microsoft.Exchange.WebServices.dll
ich habs fälschlicherweise zuerst am gleichen Ort wie das Script platziert.
Exchange Server 2019 unter Windows Server 2019 als VM unter Proxmox VE: Keine Probleme
Drei Exchange 2019, bei zwei ohne Probleme, einer hängt seit einer Stunde beim Update installieren fest.
Hat jemand schon das Script zum Scannen der Mailboxen ausgeführt – könnte bestimmt sehr lange dauern, bis dieses fertig wird….
Würde mich auch interessieren. Vor allem welche zusätzlichen Maßnahmen von Euch ergriffen wurden (Stichwort -> Check Port 445/FW)
Na Port 445 wird ja wohl vermutlich bei den meisten _nicht_ ins Internet geöffnet sein. Und der Rest wird vermutlich nicht mal eben NTLM Auth abschalten können/wollen/dürfen. ;)
wie verhält es sich denn mit den Notebooks Clients, die nicht per VPN sondern normal über Internet, per Outlook auf einen OnPrem Exchange zugreifen? Die sind ja ggf. nicht über einen Firmenfirewall geschützt und somit wird der Port 445 dort nicht geblockt.
Das Script lief bei uns recht schnell durch (270 Mailboxen). Habe es aber auf dieses Jahr begrenzt. So wie ich das sehe werden aber die Public Folder Mailboxen nicht gescannt.
*vermutlich* find ich gut :-)
Hab das Skript heut probiert. Als Richtwert bei uns waren es beim Test ca 1 Sekunde pro GB Daten in der Mailbox.
(Ohne die empfohlene Throttling Policy und ohne Einschränkung des Zeitraums)
1. DAG-Node Exchange 2016 CU23 Server 2016 ohne Probleme
– Neue ProductVersion = 15.01.2507.023
– Dauer des Reboots normal.
– Die gefühlte Performance des Systems ist nach dem Update besser (das hatte ich auch noch nie)
Die bessere Performance kann ich in der Tat bestätigen! Dachte zuerst auch das hätte nur gefühlte Gründe oder liegt vielleicht am Neustart, aber da du es ebenfalls erwähnst, ist da vielleicht was dran!
2. DAG-Node Exchange 2016 CU23 Server 2016 ohne Probleme
Beim mir kommt beim Script:
Unable to process mailbox xyz@xyz.xyz, Either you don’t have proper impersonation rights or the mailbox is inaccessible. Inner Exception:
Cannot convert argument „0“, with value: „SmtpAddress“, for „ImpersonatedUserId“ to type „Microsoft.Exchange.WebServices.Data.ConnectingIdType“: „Cannot convert value „SmtpAddress“ to type „Microsoft.Exchange.WebServices.Data.ConnectingIdType“. Error: „Invalid cast from ‚Microsoft.Exchange.WebServices.Data.ConnectingIdType‘ to ‚Microsoft.Exchange.WebServices.Data.ConnectingIdType‘.““
obwohl ich eigentlich die Rechte habe und das sogar mit mehreren Benutzern getestet habe welche aktiv Impersonation Rights benutzen.. :S
Bezüglich dem Outlook Patch: Wenn Outlook aus M365 benutzt wird, muss man dann händisch den Patch installieren? Weil normalerweise updaten sich die M365 Office Programme ja komplett automatisch.
Naja automatisch „irgendwann“. Du könntest natürlich mal auf Updates installieren klicken lassen. Ist ja leider seit c2r alles irgendwie nicht mehr so „praktisch“.
Ging sich mir hier eher darum, ob ein manueller Download und Installation von der MS-Seite notwendig ist oder ob das über den regulären Updateweg für M365 (also entweder automatisch oder über die Funktion im Office selbst) rein kommt. Habe mich da etwas missverständlich ausgedrückt.
https://learn.microsoft.com/en-us/officeupdates/current-channel?redirectSourcePath=%252farticle%252f95c8d81d-08ba-42c1-914f-bca4603e1426
Kommt also „automatisch“ irgendwann. Hab grad mal auf „Jetzt aktualisieren“ geklickt und hab jetzt Version 2302 (Build 16130.20306)
Manuell runterladen ist ja bei C2R eh nicht „wirklich“ vorgesehen. ;)
Hi Franky,
kannst Du bitte den Teil korrigieren: „ am 11.04.20233 endet“ ?
Gruß Christoph
Da ist nur ein Zahlendreher. Der Support für Exchange 2013 endet am 11.04.2023. Ab dann keine Updates mehr.
Vielleicht eine erste Rückmeldung:
Exchange Server 2016 CU23 auf 2016 ohne Probleme nur der Neustart dauert ewig….. :-(
Schöne Woche !
Hier mit 5 exchange 2019 bisher ebenfalls keine Probleme.