[English]Sicherheitsforscher von CrowdStrike sind bei der Analyse von mehreren Play-Ransomware-Fällen auf eine neue Expolit-Methode für die NotProxyShell-Schwachstellen CVE-2022-41080 und CVE-2022-41082 gestoßen. Die Ransomware verwendet eine neue Exploit-Methode, um die URL-Rewrite-Regeln von Microsoft (als Reaktion auf ProxyNotShel) für Autodiscover umgeht. Der Exploit ermöglicht eine Remotecodeausführung (RCE) über Outlook Web Access (OWA) und dient dann für die Infektion anfälliger Exchange-Server. Die neue Exploit-Methode wird als OWASSRF bezeichnet. Ergänzung: In zwischen hat auch das CERT-EU reagiert.
Anzeige
Passt mal wieder, kurz vor den Feiertagen muss eine Warnung an Exchange-Administratoren raus, die ihre On-Premises-Systeme nicht auf dem neuen Patchstand haben und deren Systeme per Internet erreichbar sind. Ende September 2022 wurde eine neue 0-Day-Exploit-Methode (ProxyNotShell) für On-Premises Exchange Server gefunden, für die Microsoft im Oktober 2022 gleich mehrere URL-Rewrite-Regeln als vorläufigen Schutz veröffentlichte (siehe Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333 und die restlichen Artikel am Beitragsende). Microsoft hat dann im November 2022 ein Sicherheitsupdate veröffentlicht (siehe Exchange Server Sicherheitsupdates (8. November 2022)).
Neue Exploit-Methode gefunden
Bei der Untersuchung mehrerer Play-Ransomware-Fälle ist Sicherheitsforschern von CrowdStrike aufgefallen, dass die Eindringlinge vermutlich die Microsoft Exchange ProxyNotShell-Schwachstellen CVE-2022-41040 und CVE-2022-41082 als gemeinsamen Eintrittsvektor nutzen. In jedem dieser Fälle wurden die entsprechenden Protokolle überprüft, aber es ließen sich keine Beweise für die Ausnutzung von CVE-2022-41040 für den ersten Zugriff finden. Stattdessen wurde festgestellt, dass die entsprechenden Anfragen direkt über den Endpunkt der Outlook-Webanwendung (OWA) gestellt wurden. Das deutete auf eine bisher unbekannte Methode zur Ausnutzung von Exchange hin.
Die Sicherheitsforscher gehen daher davon aus, eine neue Exploit-Methode (genannt OWASSRF) entdeckt zu haben. Diese kombiniert die Schwachstellen CVE-2022-41080 und CVE-2022-41082, um Remotecodeausführung (RCE) über Outlook Web Access (OWA) zu erreichen. Die neue Exploit-Methode umgeht URL-Rewrite-Abwehrmaßnahmen für den Autodiscover-Endpunkt, die von Microsoft als Reaktion auf ProxyNotShell bereitgestellt wurden. Details haben die Crowdtrike-Sicherheitsforscher hier veröffentlicht.
Während die Sicherheitsforscher von CrowdStrike an der Entwicklung ihres eigenen Proof-of-Concept-Codes (PoC) arbeiteten, um die bei der Untersuchung der jüngsten Play-Ransomware-Angriffe gefundenen Protokolldaten abzugleichen, entdeckte Dray Agha, Bedrohungsforscher bei Huntress Labs, am 14. Dezember 2022 das Tooling eines Bedrohungsakteurs und veröffentlichte es online. Das berichten die Kollegen von Bleeping Computer hier. Das geleakte Tooling enthielt einen PoC für den Exchange-Exploit von Play, der es CrowdStrike ermöglichte, die bei den Angriffen der Play-Ransomware protokollierten bösartigen Aktivitäten zu replizieren.
Die Sicherheitsforscher von CrowdStrike gehen davon aus, dass der Proof-of-Concept-Exploit genutzt wurde, um Remote-Access-Tools wie Plink und AnyDesk auf kompromittierten Servern abzulegen. Seit Sommer gibt es verschiedene Play-Ransomware-Vorfälle (z.B. Stadt Antwerpen, siehe Cyberangriff auf Antwerpen (Belgien), H-Hotels in Deutschland , siehe Cyberangriff auf H-Hotels.com (11. Dez. 2022) etc.). Aktuell gehe ich davon aus, dass ein vollständig gepatchter Exchange Server nicht für diese Angriffsmethode bzw. den Exploit anfällig ist. OWA sollte aber auf jeden Fall nicht per Internet erreichbar sein.
Ergänzung: In zwischen hat auch das CERT-EU reagiert und den neuen 0-Day in seine Liste aufgenommen.
Ä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)
Anzeige
Ransomware-Angriff für Ausfall der Rackspace-Exchange-Instanzen im Dez. 2022 verantwortlich
Ärger: Schweizer NCSC informiert Kunden über unsicherere Exchange Server (Dez. 2022)
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Exchange Health Checker – Script-Erweiterungen von Frank Zöchling
2015
> OWA sollte aber auf jeden Fall nicht per Internet erreichbar sein.
Das wird ggf. für einige ein Problem, die ihr "Homeoffice Konzept" damit gebastelt haben.
Nur für inkompetente Admins, die noch nie von Reverse Proxy und VPN gehört haben.
Ein Reverse Proxy wie ihn viele kennen und nutzen, hilft kein Stück weiter. Denn es werden alle Verbindungen 1:1 weitergeleitet – kein PreAuth, kein Filtern des Datenvekehrs, kein Filter von Parameter, etc.
Ohne eine WAF würde ich heute keinen einzigen Service mehr im Internet bereitstellen. Da ist allerdings wieder an das Zeit- und Kostenproblem geknüpft. :-(
Würde ich nur bedingt unterstreichen. zBsp. ist es zwingend, bei classic full hybrid die EWS Schnittstelle ungeschützt (IP restrictions) zu MS zu publizieren. Reverseproxy und Co. darf man dann nicht, sonst ist es nicht supportet, obwohl diese viele so machen…
Es würde wohl aber schon viel bewirken, wenn man nicht mehr einfach so einen Exchange installieren könnte. Sprich nur noch bei gültigen Lizenzen. Viele "Test" Systeme stehen einfach so rum über MSDN installiert oder man hat irgendwann einen installiert ohne die CAL's etc. Hier würden wohl schon ein erheblicher Teil wegfallen, weil man dann plötzlich merkt, dass die O365 doch günstiger ist als on-Prem korrekt durchzulizensieren.
Auch bei reverse Proxy und Co. kann man nicht einfach die Home Version nehmen im Unternehmensumfeld. Und open source ohne Supportvertrag ist wieder was anderes.
Aus meiner Sicht ist wirklich die Krux, dass Exchange und Co. auch "ohne" korrekte Lizensierung läuft.
@Tom801
Bisher hat sich noch kein Engineer von Microsoft (ich meine damit nicht den Supporter in Indien) darüber negtiv ausgelassen. Es ist sicherlich eine Kunst die notwendige Konfigurationen für dieses Szenario zu haben, aber dafür werden bei uns ein paar ITler bezahlt.
So schlimm das jetzt auch wieder ist, mich wundert in letzter Zeit eigentlich nur eines immer wieder: Exchange Online ist komischerweise nie betroffen?! Nutzen die dort andere Exchange Server oder haben die ein anderes Sicherheitskonzept? Wenn letzteres = ja ist, warum zeigen die dann nicht ein optimales Konzept auf?
Mittlerweile tippe ich da eher drauf, dass die auf Sicherheitslücken sitzen die ab und an ein wenig leaken, da es ja "nur" die onPrem Welt betrifft um so mehr Kunden in deren Cloud zu locken – weil bei denen ist OWA und alles andere aktiv – ohne Probleme.
Klingt jetzt schwer nach Verschwörungstheorie ich weis, aber es ist halt auffällig.
> Wenn letzteres = ja ist, warum zeigen die dann nicht ein optimales Konzept auf?
Das optimale Konzept gibt es mehr oder weniger schon. Das ergibt sich meiner Meinung nach auch durch aktuelle Best Practises im Bereich Security und hat erstmal nichts direkt mit Exchange Server zu tun.
Nachstehend meiner Ansicht dafür notwendiger Struktur:
Firewall -> WAF -> WAP -> Firewall -> ADFS/Exchange
Somit IDS/IPS, Content Filter durch die WAF, Pre-Auth durch WAFP und AFS und der Exchange im SecLAN. Natürlich müssen die Komponenten noch entsprechend konfiguriert werden. Weil wie bei Windows Server erstmal die Konfiguration seh offen ist, damit es funktioniert.
Sag das mal einem (auch wenn etwas grösserem) KMU! Grundsätzlich teile ich sämtliche Vorschläge, aber irgendwo gibts Grenzen. Ich vermisse hier (ok, nicht nur hier) einen gangbaren Weg von Microsoft, welcher auch für nicht-Enterprise-Kunden gangbar ist.
Ich versteh dich. Aus meiner warte ist das kein Microsoft Problem. Die Herausforderung hast du mit jeder Application, die im Internet verfügbar ist. Egal ob darunter ein IIS oder Apache, ob ein Windows Server oder ein Linux läuft.
Es gibt genug Security Advisor in anderen Applikationen, die teilweise gar nicht öffentlich sind. Fairerweise muss man sagen, dass natürlich verbreitete Anwendungen immer im Rampenlicht stehen.
Das hört für mich zu dem Prozess, wenn es um die Abwägung zwischen Cloud & On-Premise geht. Hier muss man eben nicht nur den Server für die Application sondern auch die notwendigen vor -und nachgelagerten Geräte berücksichtigen. Hierbei kann man gerne noch überlegen, ob ein Teil oder alles als ManagedService betriebe wird oder ob mit eigenem Personal. Wer das nicht tut, nicht will oder nicht beurteilen kann, muss mit den möglichen Auswirkungen klar kommen.
Es ist eben nicht mehr so einfach wie vor 15 Jahren. Die Komplextität, die Abhängigkeiten, die Angriffsvektoren sind eben um vielfaches gestiegen. Leider sind viele Admins irgendwann stehen geblieben. :-(
das ist mir durchaus bewusst wie man es einrichten sollte, auch der Aufwand ist mittlerweile überschaubar um die meisten Sicherheitslücken / Schwachstellen zu überbrücken durch die von dir genannten Techniken und somit die Schwachstellen der M$ Produkte abzuschwächen.
Mich wundert es immer wieder aufs neue, dass direkt bei Bekanntgabe von Sicherheitslücken alle betroffen sind außer M$ "online", egal um was es sich handelt und dann z.T. ewig lange für ein Sicherheitsupdate benötigen um die onPrem Welt abzusichern. Ich würde tippen die bekommen die Info, patchen das intern und sitzen es dann aus, bis es öffentlich gemacht wird um dann am Ende ein Patch zu liefern aber brav darauf hinweisen, dass es mit Exchange Online nicht passiert wäre.
Und btw. wenn in Azure nicht an der Sicherheit schraubt und das korrekt einrichtet, kann man sich dort leichter Daten ablutschen wie bei einer onPrem Lösung :-) – und einfach mit ein paar Klicks ist das auch nicht eingerichtet.
Am Ende ist es egal was man macht, wenn man nicht genug Personal hat, geht es nach hinten los, ein Team aus 2-3 Personen kann keine IT für hunderte oder gar tausende User betreuen.
Nein, bei Exchange Online ist das alles kein Problem, denn die Daten sind ja schon weg.
also die schreiben:
"If you cannot apply the KB5019758 patch immediately, you should disable OWA until the patch can be applied."
Grüße,
MG
Bei Exchange Online werden die Server schon gepatcht, sobald der Patch bei MS fertig ist.
Die On-Prem müssen bis zum nächsten Patchday warten.
Und wer jetzt noch nicht den Patch gegen ProxyNotShell installiert hat, verdient es nicht anders!
Das Erscheinen des Patches ist jetzt 6 Wochen her!