[English]Ende September wurde ja die 0-Day-Schwachstelle ZDI-CAN-18333 in Microsofts On-Premises Exchange Servern (2013, 2016 und 2019) bekannt, und die Schwachstellen (CVE-2022-41040, CVE-2022-41082) werden bereits in freier Wildbahn ausgenutzt. Nun hat Microsoft reagiert und rollt per EMS URI Rewrite Regeln zum Schutz aus. Weiterhin wurden Fehler in den zwischenzeitlich veröffentlichten Microsoft-Supportbeiträgen korrigiert, und es gibt Scripte zur Prüfung und Absicherung von Exchange-Installationen. Hier ein Überblick über die neuesten Entwicklungen.
Anzeige
Die 0-day-Schwachstelle ZDI-CAN-18333
Zum 29. September 2022 hatte ich im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022) über die 0-day-Schwachstelle ZDI-CAN-18333 berichtet. Microsoft Exchange Server 2013, 2016 und 2019 werden durch zwei ungepatchte Zero-Day-Schwachstellen CVE-2022-41040 (Server-Side Request Forgery) und CVE-2022-41082 (Remote Code Execution per PowerShell) gefährdet.
Allerdings benötigt ein Angreifer einen authentifizierten Zugriff auf den anfälligen Exchange Server, um eine der beiden Sicherheitslücken erfolgreich auszunutzen. Microsoft hatte dann am 29. September 2022 einen Supportbeitrag mit Hinweisen zur Erkennung eines erfolgreichen Angriffs sowie zum Schutz gegen solche Attacken veröffentlicht. Ich hatte im Blog-Beitrag Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333 berichtet.
Allerdings stellte sich schnell heraus, dass die Microsoft-Angaben zur Abschwächung des Angriffs fehlerhaft waren. Blog-Leser haben diesbezüglich einige Kommentare in den oben verlinkten Blog-Beiträgen hinterlassen. Daher war die Blog-Leserschaft in der Lage, erfolgreich die URI Rewrite-Regel für Exchange Server zu setzen.
Microsofts Korrekturen
Blog-Leser Robert weist in diesem Kommentar darauf hin, dass Microsoft seine (fehlerhaften) Angaben zur Abschwächung der URI Rewrite-Pattern korrigiert habe.
Anzeige
Kurzes Update: es tut sich was bei Microsoft…
Es wurde ein Powershell Script von MS released, welches alles automatisch macht.
Ausserdem hat MS nun die Sache mit den RegEx endlich korrigiert und hat nun auch die Absicherung ERWEITERT: betrifft nicht mehr nur das Virt. Dir. Autodiscover, sondern MS wendet die URL Rewrite nun auf die KOMPLETTE Default WebSite an.
Microsoft hat dazu am 30. September 2022 den Blog-Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server nochmals grundlegend überarbeitet. So wurde ein Link zum Artikel Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082 eingefügt, der am 30. September 2022 im Microsoft Security-Blog veröffentlicht wurde. Dort findet sich eine weitere Analyse der Schwachstellen und der davon ausgehenden Bedrohungen.
Exchange: 0-day Angriff per Schwachstelle ZDI-CAN-18333
Angreifer benötigen eine Authentifizierung, um eine schädliche http-Anfrage auf Port 443 an Exchange zu sehen. Dann können Sie die beiden Schwachstellen ausnutzen, um eine Web-Shell als Backdoor zu installieren und weitere Aktivitäten auszuführen. In obigem Artikel gibt es nun weitere Hinweise zur Abschwächung der beiden Sicherheitslücken sowie den Hinweis, dass der Windows Defender for Endpoint nun die Aktivitäten nach dem initialen Angriff erkenne. Zudem unterstützt das in Exchange eingeführte Antimalware Scan Interface (AMSI) die Erkennung der Schadfunktionen. Allerdings dürfte AMSI auf einigen Exchange-Systemen wegen Problemen (siehe Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration) deaktiviert sein.
EMS setzt Blockierungsregel automatisch
Microsoft hatte im September 2021 den Exchange Server Emergency Mitigation Service (EMS) per CU eingeführt (siehe Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service). Dieser sollte Microsoft ermöglichen, dynamisch auf Bedrohungen durch 0-day Schwachstellen zu reagieren, indem z.B. automatisch URI Rewrite-Regeln zum Blockieren von Angriffen gesetzt werden (siehe auch diesen Microsoft-Beitrag).
Hier im Blog war in Kommentaren mehrfach gefragt worden, warum Microsoft diesen Mechanismus nicht verwende. Ich hatte darauf verwiesen, dass die Entwickler da ggf. ein paar Stunden Zeit benötigen, um die entsprechenden Regeln zu implementieren und zu testen. Das ist nun wohl passiert. Gero schrieb bereits heute morgen (1. Oktober 2022) in diesem Kommentar:
Guten Morgen,
auf unserem 2016er hat der EM-Service heute Nacht die Regel auf der Default Web Site automatisch erstellt.
Na endlich….
Microsoft hat hier bestätigt, dass die betreffende Funktionalität für Kunden, die EMS auf ihrem Exchange verwenden, automatisch zum Schutz ausgerollt wird.
For customers who have the Exchange Server Emergency Mitigation Service (EMS) enabled, Microsoft released the URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019. The mitigation will be enabled automatically. Please see this blog post for more information on this service and how to check active mitigations.
Gilt für für Exchange Server 2016 und Exchange Server 2019 mit aktiviertem EMS. Dort wird die URL Rewrite-Blockierregel automatisch ausgerollt und aktiviert. Sofern die Regel manuell eingerichtet wurde, sollte geprüft werden, ob da was korrigiert wurde.
Schutz per Script installieren
Blog-Leser Robert hatte in seinem oben erwähnten Kommentar darauf hingewiesen, dass Microsoft zudem ein PowerShell-Script bereitstelle, welches die URL Rewrite-Blockierregel automatisch im Exchange einträgt. Microsoft hat das PowerShell-Script, welches die Schritte zur URL Rewrite-Blockierregel – zwecks Abschwächung der Sicherheitslücken – automatisch durchführt hier veröffentlicht. Im Artikel Exchange On-premises Mitigation Tool v2 (EOMTv2) finden sich entsprechende Hinweise, was das Script zum Schutz gegen die Sicherheitslücken alles macht und welche Voraussetzungen erforderlich sind. Das PowerShell-Script besitzt auch eine Rollback-Funktion, um die sogenannte Mitigation (Abschwächung) wieder zurückzunehmen.
Ein 0-day-Checker-Tool
Das Viet Nam Cybersecurity Emergency Response Teams/Coordination Center (VNCERT/CC) hat zudem ein 0-day-Checker-Tool veröffentlicht, mit dem man einen Exchange Server auf die Ausnutzbarkeit der Schwachstellen prüfen kann. Dies geht aus nachfolgendem Tweet hervor:
Das Projekt läuft unter MIT-Lizenz und ist auf GitHub abrufbar. Es muss allerdings jeder selbst entscheiden, ob er die bereitgestellten .exe-Dateien aus dieser Quelle auf seinem Exchange Server ausführt. Virustotal meldet keine Funde und das VNCERT-CC hat den Quellcode des Checker-Tools veröffentlicht.
Ergänzung: Es gibt neue Korrekturen – siehe Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)
Artikelreihe:
Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
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)
Ähnliche Artikel:
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: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Exchange Health Checker – Script-Erweiterungen von Frank Zöchling
Anzeige
Kann auf einem 2019er auch die EMS Regel auf der Default Site bestätigen.
Kam heute im laufe des Tages
Da ich mir das ps1 auf dem Handy gerade nicht ansehen kann, was macht das Rewrite? Der vorige Workaround filterte ja nur Powershell-strings, oder?
Gibt es hier Probleme wenn auf dem Exchange noch andere IIS-Subseiten (GFI) laufen?
Lg stefan
Es gibt seit gestern ein Update von GTSC zum eingetragenen Muster. Anscheinend lässt sich das bisher bekannte Muster aushebeln, weswegen man den Wert auf ".*autodiscover.json.*Powershell.*" (ohne "") benutzen soll.
Quelle: https://web.archive.org/web/20221026020832/https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
Von MSRC gibt es dazu kein Update.
Ja, stimmt – wollte ich auch gerade schreiben, aber nk war schneller ;)
Es ist sinnvoll manuell eine 2. Regel mit dem neuen RegEx-Pattern ".*autodiscover\.json.*Powershell.*" zusätzlich zur automatisch verteilten MS-Regel hinzuzufügen.
Bin mal gespannt, ob und besonders WANN dies bei MS auffällt.
Das blockiert nun aber den Powershell-Zugriff komplett, weder unser PRTG, noch unser Cloud Panel kann jetzt noch auf die Exchange Server zugreifen.
Hört sich für mich gut an (bzgl. Sicherheit), für Dich ist das natürlich nicht so gut.
MS hat nämlich NEU eine weitere Mitigation herausgegeben, in der sie jetzt empfehlen, den RemotePowerShell bei ALLEN NICHT-Admin-Usern zu deaktivieren: Added to the Mitigations section: "we strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization. Guidance on how to do this for single user or multiple users is here."
https://learn.microsoft.com/en-us/powershell/exchange/control-remote-powershell-access-to-exchange-servers?view=exchange-ps&viewFallbackFrom=exchange-ps%22%20%5Cl%20%22use-the-exchange-management-shell-to-enable-or-disable-remote-powershell-access-for-a-user
Auf die 'netten' Side-Effects von manchen Konten (u.a. auch von Devs & Co.) bin ich schon mal gespannt, was damit alles lahmgelegt wird.
Ich muss mich korrigieren, das Problem trat gestern nur auf einem unserer Exchange Server auf (Exchange 2016, aktuelles CU, voll gepatcht), der andere (Exchange 2019, aktuelles CU, voll gepatcht) zeigt bisher keine Probleme.
Beim Exchange der Probleme macht, konnten auch die Clients (Outlook 2013) nicht mehr verbinden (übers Internet), evtl. hatte ich auch einen Schreibfehler in der URL oder in der Rule-Konfig, da ich diese sofort wieder gelöscht habe, kann ich das jetzt nicht mehr nachvollziehen, werde es aber heute Nacht nochmals testen.
Ich habe die neue rewrite Regel (ohne das \@.) gestern Nacht nochmals erstellt und jetzt gibt es keine Probleme mehr mit dem Zugriff mit PRTG oder dem Cloud Panel, auch die Client Probleme (Outlooks, interne wie externe, konnten ebenfalls nicht mehr verbinden) treten nicht mehr auf. Also hatte ich beim ersten Versuch wohl irgendwo einen "Tippfehler", oder eine Fehlkonfiguration drin.
Ist doch auch eigenartig das per default jeder User von Exchange Powershell Zugriff hat.. Wieso?
Hat jemand ein Script in dem alle User deaktiviert werden außer die User der Admin Gruppe?
Nach Einspielung der URL Rewrite Regel funktioniert das Management Shell vom Exchange 2013 nicht mehr. Exchange 2016 hat damit keine Probleme. Hat das auch jemand beobachtet? (Remote Powershell ist NICHT deaktiviert worden)
Fehler:
Der WinRM-Client hat einen Status in Bezug auf einen HTTP-Serverfehler (500) empfangen, aber der
Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt. Weitere Informationen finden Sie im
Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : WinRMHttpError,PSSessionOpenFailed
Fehler beim Herstellen der Verbindung zu einem Exchange-Server am aktuellen Standort.
Geben Sie den vollqualifizierten Domänennamen des Servers ein, zu dem eine Verbindung hergestellt werden soll.: