Derzeit laufen wieder Angriffe auf veraltete Exchange Server. Konkret wird die ProxyNotShell Lücke, welche im Oktober diesen Jahres bekannt wurde, neu ausgenutzt. Der neue Angriffsweg wurde OWASSRF getauft. Die von Microsoft veröffentlichten IIS Rewrite Rules werden bei dieser neuen Angriffsmethode umgangen. Hier hilft es aktuell nur die verfügbaren Sicherheitsupdates vom November zu installieren:
Auf dem CrowdStrike Blog findet sich eine detaillierte Beschreibung zur neuen Angriffsmethode:
Wer also aktuell noch Exchange Server ohne das November SU betreibt, sollte schnellstmöglich das Update installieren. Gerade die Weihnachtszeit wird gerne für automatisierte Angriffe genutzt, da viele Mitarbeiter der IT-Abteilungen im Urlaub sind und so die Wahrscheinlichkeit sinkt, dass ein Angriff schnell bemerkt wird.
Wie bereits erwähnt hilft gegen diesen neuen Angriff bisher nur das Installieren des Updates KB5019758, die IIS Rewrite Rules, welche Microsoft mittels Exchange Emergency Mitigation verteilt hat, helfen nicht, da diese nur auf das Autodiscover vDir konfiguriert wurden:
Der neue Angriff zielt nun aber auf das OWA vDir ab. Ohne das Update KB5019758 bleibt aktuell nur der Workaround OWA zu deaktivieren um sich vor OWASSRF zu schützen. Mit der folgenden IIS Rewrite Regel lässt sich OWA auf das lokale Subnetz einschränken und für alle anderen IPs deaktivieren:
Als Rule Template kann „Request blocking“ verwendet werden:
Die neue Regel wird nun wie im nächsten Screenshot zu sehen ist konfiguriert. Diese Regel schlägt bei allen IPs an, außer wenn der Request aus dem Netz 192.168.200.* kommt (Das Netz muss entsprechend angepasst werden):
So sieht dann die fertige Regel aus:
Es ist ggf. einfacher den Zugriff an einem Reverse Proxy oder einer Web Application Firewall zu blockieren, sofern diese eingesetzt werden.
Vielleicht ließe sich auch die ProxyNotShell Regel von „(?=.*autodiscover)(?=.*powershell)“ nach „(?=.*owa)(?=.*powershell)“ umstellen, dazu habe ich aber bisher keine Informationen gefunden. Wenn es so einfach wäre, hätte CrowdStrike vermutlich auch schon darauf hingewiesen.
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?