[English]Wächst sich etwas zur unendlichen Geschichte aus. Seit Ende September 2022 sind zwei 0-Day-Schwachstellen (CVE-2022-41040, CVE-2022-41082) in Microsofts On-Premises Exchange Servern (2013, 2016 und 2019) bekannt. Die unter dem Namen ProxyNotShell geführten Schwachstellen werden bereits in freier Wildbahn ausgenutzt. Seit bekannt werden der Schwachstellen versucht Microsoft Workarounds zum Schutz zu veröffentlichen. In der Nacht (auf den 5. Oktober 2022) wurden die URI Rewrite-Regeln zum Schutz gegen Angriffe aktualisiert, weil sich die ursprünglichen Regeln umgehen ließen. Ist aber nicht das Ende der Fahnenstange, weil sich das auch umgehen lässt – es gibt eine neue URI Rewrite Regel. Hier ein Überblick über die neuesten Entwicklungen, und Administratoren sollten reagieren.
Anzeige
Die ProxyNotShell 0-day-Schwachstellen
Zum 29. September 2022 hatte ich im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022) über die 0-day-Schwachstellen CVE-2022-41040 (Server-Side Request Forgery) und CVE-2022-41082 (Remote Code Execution per PowerShell) berichtet. Mutmaßlich staatliche Angreifer (aus China) nutzen eine Kombination dieser Schwachstellen, um On-Premises Installationen von Microsoft Exchange Server 2013, 2016 und 2019 anzugreifen und dort eine Webshell zu installieren.
Die Angreifer benötigen zwar eine Authentifizierung auf dem betreffenden Exchange Server, um eine der beiden Sicherheitslücken erfolgreich auszunutzen. Zudem muss er PowerShell-Scripte (remote) ausführen können, hat dann aber die Möglichkeit einer Privilegien-Erhöhung.
Microsoft bessert nach
Microsoft hatte recht früh eine vom Entdecker der Schwachstelle vorgeschlagene URI Rewrite-Regel ".autodiscover.json.*@.*Powershell." zum Abfangen von Angriffsversuchen als Workaround vorgeschlagen. Zudem wurde diese Regel auch per Emergency Mitigation Service (EMS) auf entsprechende Exchange-Server verteilt.
Im Blog-Beitrag Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022) hatte ich aber darauf hingewiesen, dass Sicherheitsforscher gezeigt haben, dass sie diese URI Rewrite-Regel umgehen lässt. Sicherheitsforscher wie Will Dormann sowie die vietnamesischen Entdecker haben dann das URI-Muster ".*autodiscover\.json.*Powershell.*" für die Rewrite-Regel vorgeschlagen. Zum 5. Oktober 2022 hat sich Blog-Leser R.S. in diesem Kommentar gemeldet und berichtet, dass Microsoft reagiert habe:
Microsoft hat die Exchange Mitigation EM1 übrigens heute Nacht angepasst, jetzt steht da das Pattern .*autodiscover\.json.*Powershell.* drin.
Damit ist die Lücke im ursprünglichen Pattern geschlossen.
Die Information findet sich bei Microsoft im Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server, wo zum 5. Oktober 2022 ein Update vermerkt ist:
Anzeige
Added under Mitigations section that Exchange Server customers should complete both recommended mitigations.
Im Abschnitt Mitigations finden sich dann die Hinweise, dass Microsoft folgende Korrekturen vorgenommen hat:
- Exchange Server 2016 und Exchange Server 2019 mit aktiviertem Exchange Emergency Mitigation Service (EEMS) erhalten automatisch die aktualisierte URI-Rewrite-Regel.
- Microsoft hat zudem das EOMTv2-Skript, welches die Schritte zur Abschwächung per URI Rewrite-Regel erstellt aktualisiert, um die Verbesserung der URL Rewrite-Regel einzubeziehen. Das EOMTv2-Skript wird auf Computern mit Internetverbindung automatisch aktualisier. Das Skript sollte auf jedem Exchange Server ohne aktiviertes EEMS erneut ausgeführt werden.
Zudem hat Microsoft inzwischen die bebilderte Anleitung, um die URI Rewrite-Regel manuell einzutragen, entsprechend angepasst. Administratoren sollten also kontrollieren, ob die URI Rewrite-Regel entsprechend angepasst wurde. Hier im Blog wurden von diversen Lesern Probleme mit den Microsoft Workarounds berichtet. Hier empfiehlt es sich, die Kommentare unter den am Beitragsende in der Artikelreihe verlinkten Artikeln durchzugehen. Meist wird die Ursache erläutert, warum es Probleme gab.
Rewrite-Regel nicht ausreichend!
Leider springt die oben von Microsoft anchgelieferte URI Rewrite-Regel auch zu kurz. Angreifer könnten die Zeichenketten im Ausdruck ja encodieren – worauf Will Dormann in nachfolgendem Tweet hinweist (danke an Stefan für den Hinweis).
Man muss die Zeichen im String also mit {UrlDecode:{REQUEST_URI}} decodieren lassen.
Was wohl vor ProxyNotShell schützt
On-Premises-Installationen, die nicht per Internet erreichbar sind, sollten gegenüber Remote-Angriffen geschützt sein. Allerdings sind zahlreiche Exchange-Installationen direkt per Internet erreichbar (siehe Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333). An dieser Stelle möchte ich auf den Kommentar von Byom verweisen, der schreibt:
Ein Reverseproxy ist das einzige Mittel der Wahl, um potentiell gefährdete Dienste im Web halbwegs sicher zu anzubieten.
Aus der Praxis haben sich die folgenden Dinge bewährt:1. Nginx Reverse Proxy für Exchange einsetzen (siehe).
2. Reverse-Proxy nur OWA und/oder Microsoft-Server-ActiveSync zum Exchange durchleiten
3. Linux-Firewall aktivieren und IP-Block-Listen absichern, z.B. ipset-blacklist
4. fail2ban fehlerhafte Zugriffe überwacht und IP automatisch blocken
Zudem empfiehlt Microsoft den Zugriff auf Remote PowerShell für den Exchange Server zu deaktivieren. Dann ist eine der beiden Schwachstellen nicht mehr ausnutzbar.
Aktuell sind zwar nur vereinzelte Angriffe auf Exchange Server-Installationen bekannt. Alles in allem ist das Ganze eine ungute Situation und Microsoft bekleckert sich erneut nicht wirklich mit Ruhm. Einen Patch erwartet ich kommenden Dienstag, den 11. 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
Danke für die Übernahme des Kommentars. Ich lese den Blog hier regelmäßig und dachte, ich muss auch mal etwas Qualifiziertes beitragen.
Hinweise sind immer erwünscht – erstens kann ich nicht alles sehen – und zweitens schwächele ich die letzten Tage ein wenig beim Bloggen ;-). Ziel ist ja, dass die betroffenen Admins was rausziehen können – ich selbst hab keinen Exchange am Start.
Auch aus meiner Sicht ein extrem sinnvoller Hinweis. Es war schon immer bedenklich einen Exchange offen im Netz stehen zu lassen. Wer nicht spätestens durch Hafnium wachgerüttelt wurde und seinen Exchange hinter einen Reverse-Proxy gestellt hat, dem ist aus meiner Sicht nicht nur nicht zu helfen, sondern der muss sich auch die Frage gefallen lassen ob er seinen Job überhaupt versteht. Scheint es aber doch noch sehr oft zu geben, ansonsten wären die Kommentare zu den Artikeln über diese Schwachstelle nicht voll mit Kommentaren von Admins die nervös Workarounds ausführen die erst mit Schreibfehlern von Microsoft publiziert werden und später (im Ernstfall zu spät) in unzureichend per EMS ausgerollt werden. Die nächste Stufe ist ein via EMS ausgerolltes Skript, was in einer spezifischen Umgebung benötigte Funktionen lahm legt.
Wenn ich dann noch an das letzte Update denke, dessen Effektivität erst gegeben ist wenn man manuell halbgare Funktionen aktiviert, dann ist doch offensichtlich, dass Microsoft das Produkt nicht mehr im Griff hat und man es vor sich selbst schützen muss.
Und dann immer die weisen Schlaumeier von wegen „aha du hast das Update von gestern (hallo Update-Qualität) noch nicht installiert?" oder „du hast EMS nicht aktiviert?". Ich halte unsere Systeme aktuell aber wer darauf angewiesen ist mit heißer Nadel gestrickte Skripte und Updates Day 1 in der Produktivumgebung einzusetzen, der hat grundsätzliche Probleme in seiner Infrastruktur die er/sie mit derlei Tipps nur kaschiert.
Die Nächstbesten sind dann diejenigen, die dann mit einer Testumgebung kommen. Schön wenn sie die Ressourcen in Hard-/Software und Arbeitszeit haben aber vor allem in der Testumgebung auch noch alle Wechselwirkungen der Produktivumgebung abbilden können und das von jemanden ausprobieren lassen können.
Um beim Exchange zu bleiben, all diesen Unsinn (und Zeit und Nerven) spart man sich mit dem Einsatz eines Reverse-Proxy's. Muss aber öfter gesagt werden, denn die Kommentare deuten darauf hin, dass das in breiter Front noch nicht angekommen zu sein scheint.
Das Ganze entwickelt sich schon wieder weiter… Mal sehen, bis es hierzu offizielle Aussagen von Microsoft gibt…
Hab das hier gerade geschrieben:
https://www.borncity.com/blog/2022/10/04/exchange-server-microsofts-0-day-schutz-aushebelbar-neue-einschtzungen-3-oktober-2022/#comment-133426
Yepp – stimmt!
MS ist schon wieder zu spät, oder denkt nicht 'so weit' wie die anderen…
RegEx: .*autodiscover\.json.*Powershell.*
Condition: {UrlDecode:{REQUEST_URI}}
Wird wohl wieder mehr als 24h dauern, bis MS sich da wieder mit dem autom. Rollout der neuen Rule bequemt… **TRAURIG** !!
Nun, bei mir ist das bereits seit längerem unter EEMS M1.1 gesetzt. Scheinbar wurde das doch recht zügig übernommen.
Danke – habe es schon nachgetragen – noch bin ich nicht so up to date …
Microsoft hat jetzt mit der Regel ebenfalls nachgezogen:
„10/5 – Further improvement to the URL Rewrite rules on October 5. The EEMS service is receiving new rule automatically. EOMTv2 script has been updated (script auto-updates on Internet connected machines and the updated version is 22.10.05.2304). Updated manual URL Rewrite steps on the MSRC blog."
„Option 3: The instructions and image in step 10 are updated for a Condition input change."
„10. Change the Condition input from {URL} to {UrlDecode:{REQUEST_URI}} and then click OK."
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/ba-p/3641494
Kann ich bestätigen, auch bei unserem test Exchange Server ist die Regel über Nacht auf den neuen Wert angepasst worden. Da EEMS bei unseren produktiven Exchange Servern nicht funktioniert, hatte ich dort schon gestern Abend die Regeln neu erstellt, bisher sehe ich auch dort keine Probleme oder Einschränkungen.
Der neue Workaround mit der URLDECODE-Funktion wurde bei uns ebenfalls ausgerollt.
Wenn man das Health Checker Skript in der neusten Version laufen lässt wird aber eine Sicherheitsanfälligkeit: "Security Vulnerability: CVE-2022-41040, Please run the EOMTv2 script from: https://aka.ms/EOMTv2" gemeldet.
Microsoft prüft im Health Checker Skript auf den String:
"{UrlDecode: {REQUEST_URI}}".
EEMS hat aber den String:
"{UrlDecode:{REQUEST_URI}}"
eingetragen.
Nach UrlDecode: fehlt bzw. ist ein Leerzeichen zu viel!
Lässt sich einfach testen in dem die Rewriteregel geändert wird (ein Leerzeichen dazu). Schon ist das Health Checker Skript wieder glücklich!
Exchange Health Checker version 22.10.05.2305
Nach Kontakt mit Microsoft, konnte mir dies bestätigt werden.
Sie haben auch direkt ein Update für den Health Checker veröffentlicht. Version 22.10.06.0840 behebt die Differenz.
Fühle mich langsam wie in "Und täglich grüßt das Murmeltier", jeden Tag eine neue Überraschung :-(
Hallo zusammen, ich habe nochmal eine dumme Frage. Wenn ich nun von Exchange 2016 CU 22 auf CU 23 update, muss ich dann das SU nochmal neu installieren?
Also angenommen MS bringt am Dienstag einen Patch raus, ich installiere ihn mit Stand CU 22 und mache am nächsten Wochenende ein Update von CU 22 auf CU 23. Muss ich dann das SU nochmal neu installieren? Manchmal findet Windows Update das SU dann nicht mehr, weil es der Meinung ist, es wäre schon installiert ?!Habe leider schon vergeblich gegooglet.
Ja, nach einem CU müssen immer alle SUs erneut installiert werden, selbst wenn sie zuvor beim alten CU bereits installiert waren.
Der Ablauf ist immer CU -> SU falls vorhanden.
Gruß
okay also dann erneut Mai und August SU Updates installieren.
dann installiere ich CU 23 dieses Wochenende.
aber hier steht:
Ersetzte Sicherheitsupdates
Dieses Sicherheitsupdate ersetzt die folgenden zuvor veröffentlichten Updates:
Hinweise zum Sicherheitsupdate für Microsoft Exchange Server 2016 und 2019: 10. Mai 2022 (KB5014261)
https://support.microsoft.com/de-de/topic/hinweise-zum-sicherheitsupdate-f%C3%BCr-microsoft-exchange-server-2019-und-2016-9-august-2022-kb5015322-86c06afb-97df-4d8f-af88-818419db8481
das heißt doch, dass das aktuelle SU auch die alten SU's mit ersetzt oder nicht?
Sorry, mein Fehler. Ich vergesse immer, dass die SUs kumulativ sind. Verdammte exchange 2010 Zeiten :)
Es reicht natürlich das aktuelle SU nach dem CU zu installieren.
Gruß
Vorgehen ist immer:
– Letztes CU installieren
– Letztes SU installieren
Alle Updates sind kumulativ.
Am Ende noch das Health Checker Skript laufen lassen.
okay perfekt! Das spart Arbeit :-)
Dann installiere ich Exchange 2016 CU 23 und danach August SU Update und hoffe, dass MS am Dienstag ein SU für das derzeitige 0-Day veröffentlicht :-)
Nein, immer nur das letzte SU.
Das reicht
Müsste es nicht letztmalig auch nochmal Sicherheitsupdates für das CU22 geben?
Zumindest wäre es hier noch einmal aufgeführt, was es vermuten lässt:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41082
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41040
Hat hier jemand eine zuverlässige Information?
Exchange 2016 CU22 und CU23 bekommen zukünftig Sicherheitsupdates. Es bekommen immer die letzten beiden CUs Sicherheitsupdates. Für Exchange 2016 soll es kein weiteres CU mehr geben. Von daher bleibt CU22 unterstützt bis zum Ende des Extended Supports am 14. Oktober 2025.
Stand: JETZT!
zur info: heute vormittags sind wieder die meldugen der exchange server gekommen, das wieder was am Mitigation Service gedreht wurde.. und siehe da, nun steht {UrlDecode:{REQUEST_URI}} drinnen :) lieber spät als nie
Kann nur bestätigen, dass die URL UrlDecode:{REQUEST_URI} automatisch vom Mitigation Service eingefügt wurde.
Inzwischen wurde die Regel nochmal angepasst.
Further improvement has been made to the URL Rewrite rule mitigation:
"(?=.*autodiscover\.json)(?=.*powershell)"
Microsoft bringt einen echt noch zur Verzweiflung!
AKTUELL (mal sehen wie lange noch) steht in der manuellen Variante (Option 3 step 6 and step 9):
"(?=.*autodiscover\.json)(?=.*powershell)"
Aber im AKTUELLEN EOMTv2 Script oder auch per EEMS kommt AKTUELL folgendes:
"(?=.*autodiscover)(?=.*powershell)"
Daher gehe ich davon aus, dass der String ohne "json" der richtige ist.
Ich kann aber beim besten Willen nicht mehr verstehen, wie sowas passieren kann!
Das Ganze ist eine angespannte Situation und unzählige Admins verfolgen das.
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
https://aka.ms/EOMTv2
https://officeclient.microsoft.com/getexchangemitigations
https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/bc-p/3647735/highlight/true#M34497
Admins die das jetzt manuell anlegen, legen das womöglich falsch an bzw. woher soll man aktuell überhaupt wissen, was der richtige String ist?!
auch in der manuellen Variante nun (?=.*autodiscover)(?=.*powershell)
Ich nehme noch Wetten an, wie lange es dauert, bis wir bei .* angekommen sind…
Guten Morgen,
CU 23 Installation hat funktioniert. Und ich kann bestätigen, dass Microsoft die Regel auf (?=.*autodiscover\.json)(?=.*powershell) automatisch angepasst hat. Einfach warten. Das positive ist doch, dass die automatische Anpassung seitens MS funktioniert? Morgen ist Patch-Day.
Bis dahin:
Exchange nicht ins Internet offen stellen
und warten
PS: wenn ein lokaler Angreifer Zugriff hat, hat man sowieso ein anderes Problem.