Attacks on outdated Exchange servers are currently underway again. Specifically, the ProxyNotShell vulnerability, which became known in October of this year, is being exploited again. The new attack method has been christened OWASSRF. The IIS rewrite rules published by Microsoft are bypassed in this new attack method. The only thing that helps at the moment is to install the available security updates from November:
A detailed description of the new attack method can be found on the CrowdStrike blog:
Anyone currently running Exchange Server without the November SU should install the update as soon as possible. The Christmas period in particular is often used for automated attacks, as many employees in IT departments are on vacation, reducing the likelihood of an attack being noticed quickly.
As already mentioned, only the installation of the update KB5019758 helps against this new attack, the IIS Rewrite Rules, which Microsoft has distributed via Exchange Emergency Mitigation, do not help, as they were only configured for the Autodiscover vDir:
However, the new attack now targets the OWA vDir. Without the KB5019758 update, the only workaround currently available is to disable OWA to protect against OWASSRF. With the following IIS rewrite rule, OWA can be restricted to the local subnet and deactivated for all other IPs:
Request blocking" can be used as a rule template:
The new rule is now configured as shown in the next screenshot. This rule applies to all IPs, except if the request comes from the network 192.168.200.* (the network must be adjusted accordingly):
This is what the finished rule looks like:
It may be easier to block access at a reverse proxy or a web application firewall, if these are used.
Perhaps the ProxyNotShell rule could also be changed from "(?=.*autodiscover)(?=.*powershell)" to "(?=.*owa)(?=.*powershell)", but I have not yet found any information on this. If it were that simple, CrowdStrike would probably have already pointed it out.
Vorab frohe besinnliche Weihnachten!
Aufgrund der aktuellen OWASSRF bzw. ProxyNotShell Vulnerability in MS Exchange folgende Fragestellungen (vielleicht sogar als Anregung, um bei Gelegenheit auf die Thematik EP näher einzugehen):
1) Zum Schliessen der Verwundbarkeiten CVE-2022-41080 und CVE-2022-41082 reicht einfach nur das Einspielen v. Patch aus? Oder wird sogar Extended Protection vorausgesetzt, damit der Patch erst dann aktiviert wird?
Admins sind sich nämlich nicht sicher, ob die Lücken evtl. doch nicht geschlossen sind, wenn nur der Patch installiert wurde aber EP nicht aktiviert ist.
Leider geht dies aus dem Hinweis „Aktivieren des erweiterten Schutzes“ in KB5019758
nicht deutlich hervor.
2) Gilt dies (EP Aktivierung) grundsätzlich von nun an auch bei allen zukünftigen Exchange-Patches / Security Updates oder nur bei ausgewählten?
Im August & Oktober geht MS hier noch ein:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2022-exchange-server-security-updates/ba-p/3646263
Im November (wo auch der Patch für ProxyNotShell veröffentlicht) aber nicht mehr!
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045
Was spricht denn gegen die Aktivierung der extended Protection?
Ganz im Gegenteil, in meinen Augen spricht nämlich sehr vieles dafür; das Problem ist aber dabei die Admins davon zu überzeugen, es zu tun. Ein unschlagbares Argument wäre, wenn die Vulnerability trotz Patch-Installation aber OHNE extended Protection NICHT geschlossen wird und man weiterhin (dann wohl wissend) ungeschützt da steht. Deshalb suche ich hier nach dem entscheidenden Hinweis, da MS im jeweiligen KB nicht näher auf EP und Auswirkungen bei nicht Aktivierung im Kontext des Zero-Days leider eingeht.
Die EP sollte zwingend aktiviert werden, denn nur dann werden die Lücken, die mit den vorherigen Patches August und Oktober adressiert werden, auch tatsächlich geschlossen.
Einfach mal das Health Checker Script von Microsoft herunterladen und ausführen.
Alles, was da Rot im Ergebnis ist, bedarf dringender Handlung!
Und die EP gehört dazu!
Wie erwähnt kannst du den Kunden ja einfach das healthchecker Skript ausführen lassen und der html Report wird schön rot markieren, wenn die Lücke nicht geschlossen ist.
…dem kann ich mich nur anschließen. Ich habe vor Weihnachten noch einen Exchangeserver2019 auf Server2022 für eine Migration vorbereitet und den neuen noch „leeren“ Exchange2019 mit den aktuellen Patches versorgt und das EP Script instl.. In der html Log Datei ist alles grün.
Dazu habe ich noch Franky`s Reverse Proxy unter Apache2 unter Ubuntu Server mit den blockierten Services laufen so dass der neue, wie auch der alte, Exchange nicht direkt im Internet hängt.
Den Exchange2019 hatte ich nun einige Tage parallel in CoExistens zum „alten“ Exchange2016 laufen ohne erkennbare Probleme.
Nach der Migration von EX2016 auf EX2019 und anschließendem „sauberen“ deinstl. und entfernen vom alten EX2016 lief der EX2019 mit dem Reverse Proxy immer noch sauber und das EP Script zeigt in der html auch noch alles grün.
Ich denke mehr kann man nicht machen?!?
Grüß und noch schöne Weihnachten
Direkt mit dem Dezember SU ohne das November update explizit vorher installiert zu haben sollteman auch sicher sein oder?
sind monatliche SU cummulativ, Danke
Es gab kein Dezember SU für Exchange. ;) Also nein, wenn du die für Windows meinst, hilft das nicht.
Wen der Kunde noch CU19 hat, kann man da das November SU für CU 22 oder 23 drüberbügeln, für CU19 gibt es ja kein November SU, Danke.
Nein, dann muss man vorher erst CU23 oder 22 (ich geh mal von Exchange 2016 aus) installieren und dann das November Update. Aber wer jetzt noch mit CU19 rumfummelt hat in meinen Augen die Tragweite meist auch nicht so ganz begriffen.
Kann ich erklären, was keine Ausrede sein soll..Es war eine Krankheitswelle bei uns, die Leute um einen Snapshot zu machen waren schlicht und einfach nicht da..Deswegen hat es sich immer wieder verschoben, sonst sieht unsere Patchrichtlinie innerhalb 3 Tagen vor :)
Na besser spät als nie. ;)
Extra noch heute den Patch eingespielt..
Hatten bislang nur die URL Regeln aktiv. (Selbst erstellte und die von MS)
Warum wartet man mit dem Patch so lange?