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

\"Exchange[English<\/a>]W\u00e4chst 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 <\/em>gef\u00fchrten Schwachstellen werden bereits in freier Wildbahn ausgenutzt. Seit bekannt werden der Schwachstellen versucht Microsoft Workarounds zum Schutz zu ver\u00f6ffentlichen. In der Nacht (auf den 5. Oktober 2022) wurden die URI Rewrite-Regeln zum Schutz gegen Angriffe aktualisiert, weil sich die urspr\u00fcnglichen Regeln umgehen lie\u00dfen. Ist aber nicht das Ende der Fahnenstange, weil sich das auch umgehen l\u00e4sst – es gibt eine neue URI Rewrite Regel. Hier ein \u00dcberblick \u00fcber die neuesten Entwicklungen, und Administratoren sollten reagieren.<\/p>\n

Die ProxyNotShell 0-day-Schwachstellen<\/h2>\n

\"\"Zum 29. September 2022 hatte ich im Blog-Beitrag Exchange Server werden \u00fcber 0-day Exploit angegriffen (29. Sept. 2022)<\/a> \u00fcber die 0-day-Schwachstellen CVE-2022-41040 (Server-Side Request Forgery) und CVE-2022-41082 (Remote Code Execution per PowerShell) berichtet. Mutma\u00dflich 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.<\/p>\n

Die Angreifer ben\u00f6tigen zwar eine Authentifizierung auf dem betreffenden Exchange Server, um eine der beiden Sicherheitsl\u00fccken erfolgreich auszunutzen. Zudem muss er PowerShell-Scripte (remote) ausf\u00fchren k\u00f6nnen, hat dann aber die M\u00f6glichkeit einer Privilegien-Erh\u00f6hung.<\/p>\n

Microsoft bessert nach<\/h2>\n

Microsoft hatte recht fr\u00fch eine vom Entdecker der Schwachstelle vorgeschlagene URI Rewrite-Regel \".autodiscover.json.*@.*Powershell.\" <\/em>zum Abfangen von Angriffsversuchen als Workaround vorgeschlagen. Zudem wurde diese Regel auch per Emergency Mitigation Service<\/a> (EMS) auf entsprechende Exchange-Server verteilt.<\/p>\n

Im Blog-Beitrag Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einsch\u00e4tzungen (3. Oktober 2022)<\/a> hatte ich aber darauf hingewiesen, dass Sicherheitsforscher gezeigt haben, dass sie diese URI Rewrite-Regel umgehen l\u00e4sst. Sicherheitsforscher wie Will Dormann sowie die vietnamesischen Entdecker haben dann das URI-Muster \".*autodiscover\\.json.*Powershell.*\"<\/em> f\u00fcr die Rewrite-Regel vorgeschlagen. Zum 5. Oktober 2022 hat sich Blog-Leser R.S. in diesem Kommentar gemeldet<\/a> und berichtet, dass Microsoft reagiert habe:<\/p>\n

Microsoft hat die Exchange Mitigation EM1 \u00fcbrigens heute Nacht angepasst, jetzt steht da das Pattern .*autodiscover\\.json.*Powershell.* drin.
\nDamit ist die L\u00fccke im urspr\u00fcnglichen Pattern geschlossen.<\/p><\/blockquote>\n

Die Information findet sich bei Microsoft im Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server<\/a>, wo zum 5. Oktober 2022 ein Update vermerkt ist:<\/p>\n

Added under Mitigations section that Exchange Server customers should complete both recommended mitigations.<\/em><\/p><\/blockquote>\n

Im Abschnitt Mitigations finden sich dann die Hinweise, dass Microsoft folgende Korrekturen vorgenommen hat:<\/p>\n