[English]Noch ein Nachtrag in Sachen On-Premises Exchange Server (2016-2019) und der seit Ende September 2022 bekannten zwei 0-Day-Schwachstellen (CVE-2022-41040, CVE-2022-41082). Zum Wochenende (8. Oktober 2022) hatte Microsoft erneut an seinen Artikeln zur Abschwächung dieser Sicherheitslücken herumgeschraubt. Zudem meldete sich ein Blog-Leser, der auf Fehler im korrigierten PowerShell-Script hinwies. Ich komme erst heute dazu, einen Nachtrag zum Sachstand zu schreiben. Mit etwas Glück gibt es in wenigen Stunden einen Patch.
Anzeige
Die ProxyNotShell-Schwachstelle
In den On-Premises Installationen von Microsoft Exchange Server 2013, 2016 und 2019 wurden Ende September 2022 die 0-day-Schwachstellen CVE-2022-41040 (Server-Side Request Forgery) und CVE-2022-41082 (Remote Code Execution per PowerShell) öffentlich bekannt. Mutmaßlich staatliche Angreifer (aus China) nutzten eine Kombination dieser Schwachstellen, um On-Premises Installationen von Microsoft Exchange Server 2013, 2016 und 2019 anzugreifen und dort eine Webshell zu installieren.
Diese Angriffe waren Sicherheitsforschern aufgefallen und diese hatten dann öffentlich gewarnt. Ich hatte das Thema zum 29. September 2022 im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022) aufgegriffen und in weiteren Beiträgen über neue Entwicklungen informiert (siehe Links am Artikelende).
Aktuell sind keine großen Angriffswellen auf Exchange Server über diese Schwachstellen bekannt. Möglicherweise auch, weil die Angreifer zur Ausnutzung beider Schwachstellen eine Authentifizierung auf dem betreffenden Exchange Server benötigen. Zudem muss der Angreifer PowerShell-Scripte (remote) ausführen können, hat dann aber die Möglichkeit einer Privilegien-Erhöhung.
Microsofts Workarounds
Seit der Bekanntgabe der 0-day-Schwachstellen hat Microsoft zudem Anleitungen veröffentlicht, wie man man Angriffe über diese Schwachstellen verhindern kann. Neben einer URI Rewrite-Regel, die Administratoren setzen können, wurde angeregt, Remote PowerShell für Benutzerkonten zu deaktivieren (was aber mit Vorsicht zu behandeln ist, um keinen Administrator ungewollt remote auszusperren).
Exchange Server 2016 und Exchange Server 2019 mit aktiviertem Exchange Emergency Mitigation Service (EEMS) erhalten automatisch die aktualisierte URI-Rewrite-Regel. Hier müssen Administratoren eigentlich nicht mehr aktiv werden. Microsoft stellte zudem das EOMTv2-Skript für die PowerShell bereit, über welches Administratoren die betreffenden Schutzmaßnahmen automatisch ausführen können. Das ist beispielsweise für alle Exchange Server, die kein Exchange Emergency Mitigation Service (EEMS) unterstützen, hilfreich, erspart es doch die manuelle Erstellung der URI Rewrite-Regel.
Neue Nachbesserungen zum 8. Oktober
Einziges Problem bei diesem Ansatz ist, dass Microsoft seit der Freigabe der ersten URI-Rewrite-Regel dieses Muster mehrfach anpassen musste (siehe Links am Artikelende). Zum 8. Oktober 2022 wurde dann die URI-Rewrite-Regel ein weiteres Mal angepasst. Die Information findet sich bei Microsoft im Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server, wo es heißt:
October 8, 2022 updates:
A correction was made to the string in step 6 and step 9 in the URL Rewrite rule mitigation Option 3. Steps 8, 9, and 10 have updated images.
In Schritt 6 lautet die URL Rewrite-Regel nun (?=.*autodiscover)(?=.*powershell), und für Using muss Regular Expressions gewählt sein. Zudem ist How to block auf den Wert Abort Request einzustellen (siehe folgender Screenshot).
Anzeige
Das Feld Condition input ist vom Wert {URL} auf {UrlDecode:{REQUEST_URI}} zu setzen. Blog-Leser Stefan A. hatte das bereits am 8. Oktober 2022 in diesem Kommentar erwähnt und zudem die Information gegeben, dass auch das EOMTv2 Script aktualisiert wurde und die neue URI Rewrite-Regel per EEMS ausgerollt wird – danke dafür. Weiterhin hat mich Blog-Leser Andy M. heute per Mail erneut auf diese Korrekturen hingewiesen (danke).
Zumindest ist bei der Revision zum 8. Oktober 2022 nichts am EOMTv2 Script schief gegangen. Bei den vorhergehenden Änderungen wurde ein fehlerhaftes EOMTv2 Script veröffentlicht – wie Blog-Leser cram in diesem Kommentar ausführt.
Blog-Leser Andy M. hat mich in seiner heutigen Mail auf einen Artikel von heise zum gleichen Thema hingewiesen. Interessant ist in diesem Zusammenhang dieser Kommentar. Ein Nutzer berichtet, dass es nach dem Setzen der obigen URI Rewrite-Regel bei diversen Kunden Probleme beim Einspielen neuer Profile gebe. Irgend jemand aus der Leserschaft, der dies auch festgestellt hat?
Das Ganze hat inzwischen etwas von "und täglich grüßt das Murmeltier" – die Thematik ist wohl – auch durch die regulären Ausdrücke – einfach zu komplex geworden. Ich gehe mal davon aus, dass am heutigen Dienstag, den 11. Oktober 2022 (Patchday) irgendwann nach 19:00 Uhr Sicherheitsupdates mit Microsoft Exchange 2013 – 2019 ausgerollt werden, die dann auch die unter dem Namen ProxyNotShell geführten 0-day-Schwachstellen schließen werden. Dann sollte die "Mitigation-Orgie" über ein URI-Rewrite-Regel ein Ende haben.
Exchange-Administratoren bleibt bis dahin nur, sich über die Korrekturen des Workarounds zu informieren und die Einträge für die URI-Rewrite-Regeln zu kontrollieren. Ob nach dem Patchday und installiertem Sicherheitsupdates ein manueller Eingriff bezüglich der gesetzten URI-Rewrite-Regel vorzunehmen ist, ist mir aktuell unbekannt.
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
2015
