Letztes Jahr schon führten diverse Microsoft Exchange 0-day Schwachstellen - ProxyLogon, ProxyOracle und ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) - zu einigermaßen chaotischen Zuständen. Dies kann zum Teil auf die späte Reaktion des Herstellers beziehungsweise die verwirrenden, zum Teil falschen Anleitungen für eine erfolgreiche Mitigation der Schwachstelle zurückgeführt werden. Zum Zeitpunkt der Veröffentlichung des Patches waren 2021 bereits eine große Anzahl an Exchange-Server weltweit kompromittiert.
Ende letzter Woche wurde nun eine neue 0-day Schwachstelle - ProxyNotShell (CVE-2022-40140, CVE-2022-41082) getauft - in Exchange bekannt, die zwar im Gegensatz zu ProxyShell - laut offiziellen Informationen - nur authentifiziert eine Remote-Code-Execution (RCE) zulässt, aber dennoch nicht zu unterschätzen ist, da bereits ein Standardbenutzer reicht, um das komplette System zu übernehmen. Diese Schwachstelle wird auch bereits - wenn auch, laut Microsoft nur begrenzt - aktiv ausgenutzt.
Nach Veröffentlichung des initialen Blog-Beitrags zur Schwachstelle und der Meldung an die Zero Day Initiative, hat der Hersteller dieses Mal zwar flott mit Anleitungen für eine Mitigation reagiert, jedoch hat sich gezeigt, dass diese wieder zum Teil falsch beziehungsweise unzureichend sind.

Ohne hier jetzt genau ins Detail zu gehen und die Anzahl der vielleicht in naher Zukunft kompromittierten Systeme zu kennen, soll hier und jetzt die Zeit sein, erneut auf folgendes hinzuweisen ...

Ein On-Prem Exchange-Server ist nur dann ein sicherer oder zumindest halbwegs sicherer Exchange-Server, wenn seine Webinterfaces (Outlook Web Access, Exchange Web Services, etc) ausschließlich über private, gesicherte Verbindungen (zum Beispiel VPN) erreichbar sind.