{"id":273510,"date":"2022-10-04T10:21:16","date_gmt":"2022-10-04T08:21:16","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=273510"},"modified":"2022-11-07T08:03:24","modified_gmt":"2022-11-07T07:03:24","slug":"exchange-server-microsofts-0-day-schutz-aushebelbar-neue-einschtzungen-3-oktober-2022","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/10\/04\/exchange-server-microsofts-0-day-schutz-aushebelbar-neue-einschtzungen-3-oktober-2022\/","title":{"rendered":"Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)"},"content":{"rendered":"

\"Exchange[English<\/a>]Seit Ende September 2022 ist eine 0-Day-Schwachstelle (ZDI-CAN-18333) in Microsofts On-Premises Exchange Servern (2013, 2016 und 2019) bekannt. Die Schwachstellen (CVE-2022-41040, CVE-2022-41082) werden bereits in freier Wildbahn ausgenutzt. Microsoft hat zwar reagiert und einen Workaround zum Schutz ver\u00f6ffentlicht sowie per EMS URI Rewrite-Regeln zum Schutz ausgerollt. Aber die URI Rewrite-Ausdr\u00fccke lassen sich umgehen. Zudem werden die ersten (bisher Fake) Exploits im Internet angeboten. Hier ein \u00dcberblick \u00fcber die neuesten Entwicklungen.<\/p>\n

Die 0-day-Schwachstelle ZDI-CAN-18333<\/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-Schwachstelle ZDI-CAN-18333 berichtet. Microsoft Exchange Server 2013, 2016 und 2019 werden durch zwei ungepatchte Zero-Day-Schwachstellen CVE-2022-41040 (Server-Side Request Forgery) und CVE-2022-41082 (Remote Code Execution per PowerShell) gef\u00e4hrdet.<\/p>\n

F\u00fcr die Schwachstelle wird inzwischen der Begriff ProxyNotShell<\/em> benutzt, weil die Sicherheitsl\u00fccken ein \u00e4hnliches Angriffsszenario wie bei ProxyShell erfordern, es sich aber nicht um die ProxyShell-Schwachstelle handelt.<\/p><\/blockquote>\n

Gl\u00fccklicherweise ben\u00f6tigt ein Angreifer einen authentifizierten Zugriff auf den anf\u00e4lligen 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 Privilegienerh\u00f6hung. On-Premises-Installationen, die nicht per Internet erreichbar sind, sollten gegen\u00fcber Remote-Angriffen gesch\u00fctzt sein. Allerdings sind zahlreiche Exchange-Installationen direkt per Internet erreichbar (siehe Microsofts Empfehlungen f\u00fcr die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333<\/a>).<\/p>\n

\"Sophos<\/a><\/p>\n

Vom Bauchgef\u00fchl \u00fcberwiegt bei mir aber die Einstufung, dass die (mutma\u00dflich in China sitzenden) Hinterm\u00e4nner, die den Exploit in freier Wildbahn ausnutzen, gen\u00fcgend Anmeldeinformationen aus Phishing-Angriffen haben, um zahlreiche Exchange-Server anzugreifen. Die Nacht bin auf obigen Tweet von Sophos gesto\u00dfen, die diese Einsch\u00e4tzung st\u00fctzen. Sophos hat das Ganze hier aufgegriffen<\/a> (siehe auch obige Tweets)und schreibt, dass Kunden mit den Sophos-Sicherheitsl\u00f6sungen gesch\u00fctzt seien.<\/p>\n

Inzwischen werden von Betr\u00fcgern wohl erste (bisher aber wohl Fake) Exploits f\u00fcr die obigen Schwachstellen per Internet zum Kauf angeboten. Die Kollegen von Bleeping Computer haben die Nacht in diesem Artikel<\/a> auf den Sachverhalt hingewiesen.<\/p><\/blockquote>\n

Microsofts Workaround kann umgangen werden<\/h2>\n

Die Nacht bin ich auf Twitter auf nachfolgenden Tweet<\/a> von Sicherheitsforscher Kevin Beaumont gesto\u00dfen. Ein Sicherheitsforscher mit dem Alias Jangggg hat sich das URL-Pattern, welches von Microsoft im Blog-Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server<\/a> beschrieben wurde, angesehen. Sein Fazit: Die URI-Blockierungsregel ist nicht ausreichend, und kann leicht umgangen werden. Beaumont hat es verifiziert und best\u00e4tigt dies.<\/p>\n

\"Exchange<\/a><\/p>\n

Microsoft hat den Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server<\/a> zum 2. Oktober 2022 um folgende Hinweise erg\u00e4nzt:<\/p>\n