{"id":292575,"date":"2024-02-23T00:01:00","date_gmt":"2024-02-22T23:01:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=292575"},"modified":"2024-02-23T08:34:59","modified_gmt":"2024-02-23T07:34:59","slug":"proxynotshell-scan-problematik-der-false-positives-bei-exchange-nmap-greenbone","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2024\/02\/23\/proxynotshell-scan-problematik-der-false-positives-bei-exchange-nmap-greenbone\/","title":{"rendered":"ProxyNotShell: Scan-Problematik der "false positives" bei Exchange (nmap, Greenbone)"},"content":{"rendered":"

\"Sicherheit[English]Ende September 2022 scheuchte die als ProxyNotShell bekannt gewordene Schwachstelle in Microsoft Exchange Server Administratoren auf. Die Anfang August 2022 entdeckte Schwachstelle wurde als 0-day mit Exploits angegriffen und Microsoft brauchte mehrere Versuche, die Sicherheitsl\u00fccke zu schlie\u00dfen. Inzwischen gibt es Scanner wie nmap oder Greenbone, um Exchange Server auf diese Schwachstelle zu pr\u00fcfen. Allerdings liefern diese Scanner ggf. auch Fehlalarme. Ein Leser hat mich Ende Januar 2023\u00a0 mit der Frage kontaktiert, ob ich Erfahrungen im Hinblick auf solche \"false positive\"-Meldungen mit ProxyNotShell habe. Habe ich nicht, ich stelle das Thema aber mal im Blog zur Diskussion.<\/p>\n

<\/p>\n

Das ProxyNotShell 0-day-Desaster<\/h2>\n

\"\"Kurzer Abriss, um was es \u00fcberhaupt geht. Das Sicherheitsteam des vietnamesischen Cybersicherheitsunternehmen GTSC entdeckte Anfang August 2022 im Rahmen von Sicherheits\u00fcberwachungs- und Incident-Response-T\u00e4tigkeiten, dass Microsoft Exchange Server einer kritischen Infrastruktur angegriffen wurde. Eine Analyse ergab, dass eine bisher unbekannte Exchange-Schwachstelle ausgenutzt wurde. \"\"Ende September 2022 wurde die neue 0-Day-Exploit-Methode (ProxyNotShell) f\u00fcr On-Premises Exchange Server dann \u00f6ffentlich bekannt (siehe Exchange Server werden \u00fcber 0-day Exploit angegriffen (29. Sept. 2022)<\/a>).<\/p>\n

Allerdings kam kein Patch von Microsoft, vielmehr gab es im Oktober 2022 gleich mehrere Versuche, URL-Rewrite-Regeln als vorl\u00e4ufigen Schutz zu etablieren (siehe Microsofts Empfehlungen f\u00fcr die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333<\/a>\u00a0 und die restlichen Artikel am Beitragsende). Microsoft hat erst im November 2022 ein Sicherheitsupdate zum Schlie\u00dfen der Schwachstellen ver\u00f6ffentlicht (siehe Exchange Server Sicherheitsupdates (8. November 2022)<\/a>).<\/p>\n

Seit mindestens August 2022, sp\u00e4testens seit Ende September 2022 bestand daher die Gefahr, dass die ProxyNotShell-Schwachstellen CVE-2022-41040 und CVE-2022-41082 als Eintrittsvektor f\u00fcr Microsoft Exchange Server missbraucht wurden.<\/p>\n

ProxyNotShell-Scanner und Fehlalarme<\/h2>\n

Administratoren und IT-Dienstleister stehen vor dem Probleme On-Premises-Installationen von Microsoft Exchange Server 2016 oder 2019 auf eine Verletzlichkeit hinsichtlich der ProxyNotShell-Schwachstelle zu testen. Dazu stehen ProxyNotShell-Scanner zur Verf\u00fcgung.<\/p>\n