Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)

Exchange Logo[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:

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).

New Exchange NotProxyShell bypassing issue


Anzeige

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software, Windows Server abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

29 Antworten zu Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)

  1. Byom sagt:

    Danke für die Übernahme des Kommentars. Ich lese den Blog hier regelmäßig und dachte, ich muss auch mal etwas Qualifiziertes beitragen.

    • Günter Born sagt:

      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.

    • Whistler82 sagt:

      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.

  2. Stefan A. sagt:

    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

    • Robert sagt:

      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** !!

    • Günter Born sagt:

      Danke – habe es schon nachgetragen – noch bin ich nicht so up to date …

  3. Stefan A. sagt:

    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

  4. Roger H sagt:

    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.

  5. cram sagt:

    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!

  6. sho sagt:

    Fühle mich langsam wie in "Und täglich grüßt das Murmeltier", jeden Tag eine neue Überraschung :-(

  7. Dominik sagt:

    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.

  8. Stefan A. sagt:

    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?

    • cram sagt:

      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!

  9. stefan s. sagt:

    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

  10. Dominik sagt:

    Kann nur bestätigen, dass die URL UrlDecode:{REQUEST_URI} automatisch vom Mitigation Service eingefügt wurde.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.