{"id":273732,"date":"2022-10-11T12:25:11","date_gmt":"2022-10-11T10:25:11","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=273732"},"modified":"2022-10-11T16:56:28","modified_gmt":"2022-10-11T14:56:28","slug":"exchange-server-microsofts-bessert-lsungen-fr-0-day-schutz-nach-8-oktober-2022","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/10\/11\/exchange-server-microsofts-bessert-lsungen-fr-0-day-schutz-nach-8-oktober-2022\/","title":{"rendered":"Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (8. Oktober 2022)"},"content":{"rendered":"

\"Exchange[English<\/a>]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\u00e4chung dieser Sicherheitsl\u00fccken 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\u00fcck gibt es in wenigen Stunden einen Patch.<\/p>\n

<\/p>\n

Die ProxyNotShell-Schwachstelle<\/h2>\n

\"\"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) \u00f6ffentlich bekannt. Mutma\u00dflich 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.<\/p>\n

Diese Angriffe waren Sicherheitsforschern aufgefallen und diese hatten dann \u00f6ffentlich gewarnt. Ich hatte das Thema zum 29. September 2022 im Blog-Beitrag Exchange Server werden \u00fcber 0-day Exploit angegriffen (29. Sept. 2022)<\/a> aufgegriffen und in weiteren Beitr\u00e4gen \u00fcber neue Entwicklungen informiert (siehe Links am Artikelende).<\/p>\n

Aktuell sind keine gro\u00dfen Angriffswellen auf Exchange Server \u00fcber diese Schwachstellen bekannt. M\u00f6glicherweise auch, weil die Angreifer zur Ausnutzung beider Schwachstellen eine Authentifizierung auf dem betreffenden Exchange Server ben\u00f6tigen. Zudem muss der Angreifer PowerShell-Scripte (remote) ausf\u00fchren k\u00f6nnen, hat dann aber die M\u00f6glichkeit einer Privilegien-Erh\u00f6hung.<\/p>\n

Microsofts Workarounds<\/h2>\n

Seit der Bekanntgabe der 0-day-Schwachstellen hat Microsoft zudem Anleitungen ver\u00f6ffentlicht, wie man man Angriffe \u00fcber diese Schwachstellen verhindern kann. Neben einer URI Rewrite-Regel, die Administratoren setzen k\u00f6nnen, wurde angeregt, Remote PowerShell f\u00fcr Benutzerkonten zu deaktivieren (was aber mit Vorsicht zu behandeln ist, um keinen Administrator ungewollt remote auszusperren).<\/p>\n

Exchange Server 2016 und Exchange Server 2019 mit aktiviertem Exchange Emergency Mitigation Service (EEMS) erhalten automatisch die aktualisierte URI-Rewrite-Regel. Hier m\u00fcssen Administratoren eigentlich nicht mehr aktiv werden. Microsoft stellte zudem das EOMTv2-Skript<\/a> f\u00fcr die PowerShell bereit, \u00fcber welches Administratoren die betreffenden Schutzma\u00dfnahmen automatisch ausf\u00fchren k\u00f6nnen. Das ist beispielsweise f\u00fcr alle Exchange Server, die kein Exchange Emergency Mitigation Service (EEMS) unterst\u00fctzen, hilfreich, erspart es doch die manuelle Erstellung der URI Rewrite-Regel.<\/p>\n

Neue Nachbesserungen zum 8. Oktober<\/h2>\n

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<\/a>, wo es hei\u00dft:<\/p>\n

October 8, 2022 updates:<\/strong><\/em>
\nA 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.<\/em><\/p><\/blockquote>\n

In Schritt 6 lautet die URL Rewrite-Regel nun (?=.*autodiscover)(?=.*powershell)<\/em>, und f\u00fcr Using <\/em>muss Regular Expressions <\/em>gew\u00e4hlt sein. Zudem ist How to block <\/em>auf den Wert Abort Request <\/em>einzustellen (siehe folgender Screenshot).<\/p>\n

\"Exchange<\/p>\n

Das Feld Condition input <\/em>ist vom Wert {URL} <\/em>auf {UrlDecode:{REQUEST_URI}} <\/em>zu setzen. Blog-Leser Stefan A. hatte das bereits am 8. Oktober 2022 in diesem Kommentar<\/a> erw\u00e4hnt und zudem die Information gegeben, dass auch das EOMTv2 Script aktualisiert wurde und die neue URI Rewrite-Regel per EEMS ausgerollt wird – danke daf\u00fcr. Weiterhin hat mich Blog-Leser Andy M. heute per Mail erneut auf diese Korrekturen hingewiesen (danke).<\/p>\n

Zumindest ist bei der Revision zum 8. Oktober 2022 nichts am EOMTv2 Script schief gegangen. Bei den vorhergehenden \u00c4nderungen wurde ein fehlerhaftes EOMTv2 Script ver\u00f6ffentlicht – wie Blog-Leser cram in diesem Kommentar<\/a> ausf\u00fchrt.<\/p>\n

Blog-Leser Andy M. hat mich in seiner heutigen Mail auf einen Artikel<\/a> von heise zum gleichen Thema hingewiesen. Interessant ist in diesem Zusammenhang dieser Kommentar<\/a>. 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?<\/p><\/blockquote>\n

Das Ganze hat inzwischen etwas von \"und t\u00e4glich gr\u00fc\u00dft das Murmeltier\" – die Thematik ist wohl – auch durch die regul\u00e4ren Ausdr\u00fccke – 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 <\/em>gef\u00fchrten 0-day-Schwachstellen schlie\u00dfen werden. Dann sollte die \"Mitigation-Orgie\" \u00fcber ein URI-Rewrite-Regel ein Ende haben.<\/p>\n

Exchange-Administratoren bleibt bis dahin nur, sich \u00fcber die Korrekturen des Workarounds zu informieren und die Eintr\u00e4ge f\u00fcr die URI-Rewrite-Regeln zu kontrollieren. Ob nach dem Patchday und installiertem Sicherheitsupdates ein manueller Eingriff bez\u00fcglich der gesetzten URI-Rewrite-Regel vorzunehmen ist, ist mir aktuell unbekannt.<\/p>\n

Artikelreihe:<\/strong>
\nExchange Server werden \u00fcber 0-day Exploit angegriffen (29. Sept. 2022)<\/a>
\nMicrosofts Empfehlungen f\u00fcr die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333<\/a>
\nNeues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EMS-L\u00f6sung<\/a>
\nExchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einsch\u00e4tzungen (3. Oktober 2022)<\/a>
\nExchange Server: Microsofts bessert L\u00f6sungen f\u00fcr 0-day-Schutz nach (5. Oktober 2022)<\/a>
\nExchange Server: Microsofts bessert L\u00f6sungen f\u00fcr 0-day-Schutz nach (8. Oktober 2022)<\/a><\/p>\n

\u00c4hnliche Artikel:<\/strong>
\nExchange 2016\/2019: Outlook-Probleme durch AMSI-Integration<\/a>
\nExchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service<\/a>
\nExchange: Extended Protection, Checkliste und Probleme<\/a>
\nUpdate f\u00fcr Exchange Extended Protection-Script, aber weiterhin Fehler<\/a>
\nExchange Health Checker \u2013 Script-Erweiterungen von Frank Z\u00f6chling<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

[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\u00e4chung dieser Sicherheitsl\u00fccken herumgeschraubt. Zudem meldete sich ein … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[426,7459,2557],"tags":[5359,24],"class_list":["post-273732","post","type-post","status-publish","format-standard","hentry","category-sicherheit","category-software","category-windows-server","tag-exchange","tag-problem"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/273732","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=273732"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/273732\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=273732"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=273732"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=273732"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}