ProxyNotShell: Scan-Problematik der "false positives" bei Exchange (nmap, Greenbone)

[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ücke zu schließen. Inzwischen gibt es Scanner wie nmap oder Greenbone, um Exchange Server auf diese Schwachstelle zu prüfen. Allerdings liefern diese Scanner ggf. auch Fehlalarme. Ein Leser hat mich Ende Januar 2023  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.

Das ProxyNotShell 0-day-Desaster

Kurzer Abriss, um was es überhaupt geht. Das Sicherheitsteam des vietnamesischen Cybersicherheitsunternehmen GTSC entdeckte Anfang August 2022 im Rahmen von Sicherheitsüberwachungs- und Incident-Response-Tätigkeiten, 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ür On-Premises Exchange Server dann öffentlich bekannt (siehe Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)).

Allerdings kam kein Patch von Microsoft, vielmehr gab es im Oktober 2022 gleich mehrere Versuche, URL-Rewrite-Regeln als vorläufigen Schutz zu etablieren (siehe Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333  und die restlichen Artikel am Beitragsende). Microsoft hat erst im November 2022 ein Sicherheitsupdate zum Schließen der Schwachstellen veröffentlicht (siehe Exchange Server Sicherheitsupdates (8. November 2022)).

Seit mindestens August 2022, spätestens seit Ende September 2022 bestand daher die Gefahr, dass die ProxyNotShell-Schwachstellen CVE-2022-41040 und CVE-2022-41082 als Eintrittsvektor für Microsoft Exchange Server missbraucht wurden.

ProxyNotShell-Scanner und Fehlalarme

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ügung.

• von nmap gibt es den proxynotshell_checker.nse, der auf GitHub abrufbar ist
• Auch Greenbone hat einen Remote-Test für die ProxyNotShell-Schwachstelle entwickelt.Ein Blog-Leser fragte nun Ende Januar 2024 per Mail nach meinen Erfahrungen mit den ProxNotShell-Tests von nmap und Greenbone, welche auf Exchange 2016 CU23 + KB5032147 und Exchange 2019 CU13 + Nov23SU. Die Scanner liefern in den genannten Installationsszenarien false positve-Ergebnisse, obwohl der HealthChecker 24.01.19.1457 von Microsoft keine Vulnerability erkennt. Der Leser hat in seinem Unternehmen diese Erkenntnis an Greenbone gemeldet und folgende Antwort erhalten:
  

  Sehr geehrter Herr ***,

  vielen Dank für Ihre Nachricht.

  In der Tat ist es möglich, dass dieser Netzwerkschwachstellentest (NVT) ein falsch-positives Ergebnis zeigt.

  Ein aktiver Test, wie dieser, versucht durch Anfrage an der betroffenen Anwendung selbst auf das Vorhandensein einer Schwachstelle zu schließen. Das beinhaltet nur in den aller seltensten Fällen jedoch das direkte Ausnutzen der Schwachstelle (QdE = 100%). Dies liegt daran, dass wir sicherstellen möchten, dass der Host des Kunden durch den Test auf keinen Fall geschädigt werden kann.

  Daher beruhen aktive Tests in der Regel auf indirekten Methoden. In dem Fall von "Microsoft Exchange Server OWA Multiple Vulnerabilities (KB5019758, ProxyNotShell…" (OID:1.3.6.1.4.1.25623.1.0.104337) besteht der aktive Test aus der Auswertung einer HTTP GET Antwort.

  Wir geben hier einen QdE von 70% an, weil z.B. eine indirekte Feststellung der Schwachstelle durch authentifizierte Abfrage der Softwareversion viel genauer arbeitet.

  Falsch-positive Ergebnisse von diesem spezifischen NVT sind uns bereits gemeldet worden. Wir sehen leider keine Möglichkeit das Verhalten dieses NVTs zu verbessern. Ich empfehle für diesen Host eine Übersteuerung anzulegen.

  Der Leser merkt an, dass auch auf einer neuen sauberen Windows 2019 CU13 Nov23SU Installation die ProxyNotShell-Schwachstelle fälschlich vom Greenbone erkannt wird und meinte "Evtl. wäre das einen Blog Eintrag Wert damit sich anderen Kollegen nicht den Kopf zerbrechen was sie falsch gemacht haben könnten." Liegen euch entsprechende Erfahrungen oder Erkenntnisse zu diesem Sachverhalt vor?

  Ähnliche Artikel:
  Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
  Exchange Server: Neue 0-day (nicht NotProxyShell, CVE-2022-41040, CVE-2022-41082)
  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)
  Exchange Server Sicherheitsupdates (11. Oktober 2022)
  Exchange Server Sicherheitsupdates (8. November 2022)
  Droht eine Exchange ProxyNotShell-Katastrophe zum Jahreswechsel 2022/2023?
  Britisches Wählerverzeichnis: Hack in 2022 wohl über Exchange 0-day (ProxyNotShell)